CPU ou RAM : qu'est-ce qui rend un serveur de jeu rapide ?
La RAM décide de la quantité qu'un serveur peut garder en mémoire, le processeur décide de la vitesse à laquelle il réfléchit. Pourquoi la vitesse d'un seul cœur compte le plus et quand des cœurs en plus aident.
6 min de lecture · Mis à jour le 21 oct. 2026 · Par GuavaHost Team
La RAM décide de la quantité que ton serveur peut garder en mémoire, et le processeur décide de la vitesse à laquelle il réfléchit. La plupart des lags de serveur que l'on met sur le dos de la mémoire sont en réalité des problèmes de processeur : ce guide explique donc la différence, pourquoi la vitesse d'un seul cœur compte plus que le nombre de cœurs, et comment savoir lequel des deux te manque.
Deux rôles différents
- La RAM, c'est la capacité. Elle contient le monde, les joueurs et les mods. Si elle vient à manquer, le serveur saccade pendant qu'il libère de la mémoire, ou il plante.
- Le processeur, c'est la vitesse. C'est lui qui fait le travail : déplacer les monstres, exécuter l'IA, la physique, la redstone, les stations d'artisanat et chaque plugin. S'il vient à manquer, le serveur prend du retard, et tout le monde le ressent en même temps sous forme de délai et d'élastique.
Ajouter de la RAM à un serveur qui manque de processeur ne sert à rien, et un processeur rapide ne peut pas sauver un serveur qui n'a plus de mémoire. Il te faut assez des deux, mais ils lâchent de manières différentes.
Le budget par tick
Un serveur de jeu tourne en boucle. Chaque passage dans la boucle s'appelle un tick, et à chaque tick le serveur met tout le monde à jour. Le jeu attend un nombre de ticks par seconde donné, ce qui attribue à chaque tick un budget de temps :
| Jeu | Cadence visée | Temps par tick |
|---|---|---|
| Minecraft Java | 20 ticks par seconde | 50 ms |
| Terraria | 60 mises à jour par seconde | environ 16,7 ms |
| Counter-Strike 2 | 64 ticks par seconde | environ 15,6 ms |
Si un tick dépasse son budget, le serveur n'arrive plus à suivre. Dans Minecraft, cela se traduit par un TPS (ticks par seconde) qui tombe sous 20 et un MSPT (millisecondes par tick) qui grimpe au delà de 50. Notre guide sur lire le TPS et le MSPT montre comment le mesurer.
La RAM n'apparaît nulle part dans ce budget. Finir chaque tick à temps est purement une question de quantité de travail à faire et de vitesse à laquelle le processeur en vient à bout.
Pourquoi la vitesse d'un seul cœur compte le plus
La plupart des serveurs de jeu font leur simulation principale sur un seul thread. Un thread est une unique file de travail qu'un cœur de processeur peut exécuter, et un monde de jeu est difficile à répartir sur plusieurs d'entre eux, parce que chaque étape dépend de la précédente : un monstre ne peut pas avancer tant que le serveur ne sait pas où a fini le bloc sur lequel il marche.
Minecraft, Rust, ARK, Valheim, Project Zomboid et Terraria fonctionnent tous ainsi. La vitesse d'un seul cœur fixe donc le plafond du serveur entier. Un processeur avec 16 cœurs plus lents peut faire tourner un monde Minecraft moins bien qu'un processeur avec 8 cœurs plus rapides, parce que le monde n'utilisera jamais qu'un seul d'entre eux pour son travail principal.
La vitesse d'un seul cœur dépend de deux choses :
- La fréquence, mesurée en GHz : le nombre de cycles que le cœur exécute par seconde.
- Le travail par cycle, qui s'améliore à chaque génération de processeur. Un processeur plus récent à la même fréquence est souvent nettement plus rapide qu'un ancien.
Un grand cache processeur (un petit réservoir de mémoire très rapide situé sur la puce elle même) aide aussi, parce que les serveurs de jeu sautent sans arrêt entre une multitude de petits bouts de données.
Quand des cœurs en plus servent vraiment
Les cœurs supplémentaires ne sont pas inutiles. Ils prennent en charge tout ce qui n'est pas le tick principal :
- Le travail de fond. Sauvegarder le monde, charger et générer les chunks (des logiciels serveur comme Paper sortent une partie de ce travail du thread principal), compresser les données réseau et exécuter les tâches de plugins écrites pour tourner en arrière plan.
- Le ramasse miettes de Java. Minecraft Java nettoie la mémoire inutilisée avec plusieurs threads, donc des cœurs libres raccourcissent ces nettoyages.
- Plus d'un processus. Un serveur Don't Starve Together fait tourner la surface et les cavernes comme deux processus distincts, et chaque carte d'un cluster ARK est un serveur à part. Chacun peut utiliser son propre cœur.
- Les mises à jour et les sauvegardes. Télécharger une mise à jour du jeu ou compresser une sauvegarde se passe à côté du jeu plutôt qu'à l'intérieur d'un tick.
Certains moteurs plus récents, dont l'Unreal Engine derrière ARK et Palworld, répartissent une plus grande part de leur travail sur des threads supplémentaires. Même là, le thread de jeu principal continue de fixer le rythme.
Lequel des deux te manque ?
| Ce que tu observes | Cause probable |
|---|---|
| Graphique de mémoire collé à la limite | RAM |
| Erreurs de mémoire insuffisante, ou plantages pendant le chargement | RAM |
| La mémoire a de la marge, mais le TPS tombe et le MSPT grimpe | Processeur |
| Du lag seulement près d'une ferme géante, d'une méga base ou de nombreuses créatures | Processeur |
| Le lag s'installe au fil des heures et un redémarrage le corrige | Souvent une dérive mémoire, parfois une accumulation d'entités |
| Un seul joueur lague | Ni l'un ni l'autre : c'est son ping |
Un détail à connaître : la carte Usage (utilisation) de ton panneau de contrôle GuavaHost (dans les onglets Overview et Console) affiche le processeur par rapport à ton offre. Quand ton offre a une limite de processeur, le chiffre représente une part de tous les cœurs de l'offre, avec une mention du type « of 2 cores », donc 100 pour cent signifie qu'ils sont tous occupés. Le thread principal d'un jeu ne peut utiliser qu'un seul cœur : sur une offre à 2 cœurs, un serveur qui reste autour de 50 pour cent pendant qu'il lague peut donc saturer son thread principal alors qu'il reste de la capacité. Quand ton offre n'a pas de limite de processeur, le chiffre est un pourcentage d'un seul cœur, donc un serveur qui reste autour de 100 pour cent pendant qu'il lague raconte la même histoire. C'est le signe classique d'un goulot d'étranglement sur le thread principal.
Corriger un lag dû au processeur
Plus de RAM n'aidera pas ici. Ce qui aide, c'est de donner moins de travail au thread principal à chaque tick :
- Baisse d'abord la distance de simulation, puis la distance d'affichage. Voir distance d'affichage et de simulation.
- Plafonne les fermes à monstres et nettoie les objets au sol et les entités en excès.
- Prégénère ton monde pour que le nouveau terrain ne soit pas créé pendant que les gens jouent.
- Repère les plugins ou les mods lourds avec un profileur. Sur Minecraft, le plugin gratuit Spark nomme exactement ce qui dévore chaque tick.
- Programme un redémarrage quotidien pour évacuer les entités et la mémoire accumulées.
Notre liste de contrôle du lag les reprend dans l'ordre.
Comment cela se traduit chez GuavaHost
Chaque serveur GuavaHost tourne sur des processeurs AMD Ryzen et Intel, choisis pour leurs bonnes performances en mono thread parce que c'est ce dont dépendent les serveurs de jeu, avec du stockage NVMe SSD. Ce que tu choisis, c'est la RAM, dimensionnée pour ton jeu et ton groupe, et tu peux la changer à tout moment avec Manage plan (gérer l'offre) dans ton panneau de contrôle, avec une facturation au prorata. Si ton serveur a de la mémoire en réserve mais rame quand même, c'est un travail de réglage, et notre guide de la RAM explique pourquoi acheter plus de mémoire ne le corrigera pas.
Toujours bloqué ? Rejoins notre Discord sur discord.gg/GuavaHost et l'équipe t'aidera.
- cpu
- ram
- performance
- single-thread
- cores
- tick rate
- lag
Toujours besoin d'aide ? Notre équipe est en ligne 24h/24 et 7j/7 pour répondre à tes questions.