De combien de RAM a besoin un serveur de jeu ? Minecraft, Palworld, Rust, Valheim et les autres
« De combien de RAM ai-je besoin ? » est la première question que tout le monde se pose avant de louer un serveur de jeu, et les réponses qu’on trouve en ligne vont de « 2 Go suffisent largement » à « jamais moins de 16 ». Les deux peuvent être justes, pour des jeux différents, des nombres de joueurs différents et des mods différents. Cet article rassemble ce que disent les éditeurs eux-mêmes, signale clairement où personne d’officiel ne dit rien, et montre comment mesurer ton propre serveur au lieu de deviner.
Un avertissement sur les chiffres que tu vas trouver
La plupart des guides sur la RAM sont écrits par des hébergeurs, et un hébergeur a une raison de te suggérer une offre plus grosse. Ça ne les rend pas faux, mais ça veut dire qu’un chiffre ne vaut que ce que vaut sa source. Dans cet article, chaque chiffre est attribué au projet qui le publie, et quand il n’existe pas de chiffre officiel, nous le disons au lieu de faire la moyenne d’articles de blog et de l’appeler un fait.
Ce que publient les éditeurs
| Jeu | Ce que dit la documentation officielle | Source |
|---|---|---|
| Palworld | 16 Go recommandés, avec 32 Go ou plus évoqués pour de plus gros serveurs ; 8 Go « is also bootable » (démarre aussi), mais augmentent le risque de plantages par manque de mémoire. 4 cœurs recommandés. | Documentation du serveur Palworld |
| Rust | 12 Go de RAM libre, et « 6k map will use more » (une carte 6k en utilisera plus). 15 Go d’espace disque libre, SSD ou NVMe fortement préféré. | Wiki Rust de Facepunch |
| Minecraft Java (Paper) | Pas de minimum pour un petit serveur. Pour les flags JVM documentés, PaperMC recommande « at least 6-10GB, no matter how few players » (au moins 6 à 10 Go, quel que soit le petit nombre de joueurs), et dit de laisser 1 000 à 1 500 Mo d’un hôte de 8 Go non alloués. | Flags d’Aikar dans la doc de Paper |
| Valheim | Le guide officiel du serveur dédié ne donne aucune exigence matérielle. | Guide du serveur dédié Valheim |
| Garry’s Mod | La page du wiki Facepunch sur l’installation d’un serveur dédié n’en donne pas non plus. | Wiki Facepunch |
Lis ce tableau comme « ce à quoi s’attendre en haut de la fourchette ». Deux jeux publient un gros chiffre, l’un d’eux avec une réserve claire, et deux ne publient rien. Quand il n’y a pas de chiffre officiel, la bonne méthode est de mesurer, ce que nous voyons plus bas.
Quelques détails à noter :
- La formulation de Palworld compte. « Bootable » à 8 Go ne veut pas dire « confortable » : les gens qui ont écrit le serveur disent que ça marche, avec un risque plus élevé de plantage par manque de mémoire. Prévois le chiffre recommandé si le monde doit grandir.
- Le chiffre de Rust dépend de la carte. Les 12 Go valent pour une carte normale ; le wiki dit qu’une carte de taille 6000 en utilise plus. Une petite carte pour quelques amis peut descendre plus bas, mais l’éditeur ne le promet pas : vérifie donc la consommation après quelques jours de jeu.
- Le conseil pour Minecraft porte sur le tas (heap), pas sur le besoin. La page de Paper est un guide pour régler le ramasse-miettes de Java sur des serveurs qui ont de la mémoire à revendre. Elle dit aussi que les gains s’arrêtent au-delà de la bonne taille de tas : plus n’est donc pas toujours mieux.
Minecraft : ce qui fait vraiment bouger le chiffre
Minecraft Java est le cas où tu contrôles le plus de choses, parce que la charge vient d’éléments que tu peux choisir.
La distance de rendu. Chaque joueur reçoit tous les chunks situés dans view-distance autour de lui, un carré de (2 x distance + 1) chunks de côté. Avec la valeur par défaut de 10, ça fait 441 chunks par joueur ; à 16, ça en fait 1 089, soit environ 2,5 fois plus. Notre guide de création d’un serveur Minecraft contient le graphique et les réglages. Descendre la distance de rendu à 8 est l’économie de mémoire et de CPU la moins chère que tu trouveras, et elle est à peine visible pour la plupart des joueurs.
Les joueurs qui s’éparpillent. Dix joueurs au même endroit chargent à peu près les mêmes chunks qu’un seul ; dix joueurs qui explorent dans dix directions chargent dix mondes. C’est pourquoi un serveur semble correct le soir, puis s’écroule quand tout le monde quitte le spawn en même temps.
Les plugins et les mods. Une poignée de plugins bien écrits coûte peu. Un modpack de centaines de mods peut être lourd à lui seul avant que quiconque se connecte ; l’auteur du modpack donne en général un chiffre, et celui-là bat n’importe quel guide général.
Les entités. Les fermes, les enclos d’animaux et les cadres sont mis à jour à chaque tick dans la distance de simulation. Beaucoup d’entités coûtent du CPU d’abord, de la mémoire ensuite.
Un point de départ sobre pour un petit serveur Paper privé est un tas de quelques gigaoctets, surveillé et ajusté. Si tu vas au-delà, règle le tas en dessous de la mémoire que tu as réellement, comme sur l’image ci-dessous, parce que le processus Java utilise plus que son tas et que le système en a besoin aussi.
Pourquoi la RAM n’est pas toujours le problème
Quand un serveur rame, la tentation est d’acheter plus de mémoire. Ça ne change souvent rien, parce que ce qui manque, c’est le processeur. Les serveurs de jeu font l’essentiel de leur travail sur un seul thread principal : pour Minecraft, 20 ticks par seconde, ce qui donne 50 ms pour tout faire dans un tick. Si un tick prend 80 ms, les joueurs sentent le lag quelle que soit la mémoire libre.
Les signes que la mémoire est en cause :
- La console du serveur signale des erreurs de manque de mémoire, ou le processus est tué et redémarre.
- Le ramasse-miettes tourne en permanence (le serveur saccade sur un rythme régulier).
- L’utilisation de la mémoire monte régulièrement et ne redescend jamais.
Les signes que c’est le processeur, ou le monde :
- Beaucoup de mémoire libre, mais des ticks de plus de 50 ms (la commande
/tpsde Paper l’indique). - Du lag qui apparaît quand beaucoup de joueurs chargent de nouvelles zones, ou quand une ferme tourne.
- Du lag qui suit un plugin ou un mod précis après son ajout.
Trouver lequel tu as prend dix minutes et peut t’éviter le prix d’une montée en gamme.
Mesurer ton propre serveur
Tu n’as pas besoin d’outils spéciaux. Cinq minutes après que le serveur a été occupé, regarde ce qu’il utilise réellement.
Sur une machine Linux :
free -h # total, used and available memory
ps -o pid,rss,cmd -C java # resident memory (RSS, in kilobytes) of Java processes
top -o %MEM # the heaviest processes right now
C’est la colonne available de free qui compte, pas free : Linux utilise la mémoire libre comme cache et la rend quand il le faut. Le RSS du processus du serveur est son empreinte réelle ; pour Java, il sera au-dessus de la valeur -Xmx que tu as fixée, parce que Java utilise de la mémoire en dehors du tas.
Sur un serveur hébergé, les graphiques de ressources du panel montrent la même chose dans le temps. Regarde-les après une soirée chargée, pas un lundi matin tranquille, et note deux chiffres : le niveau habituel, et le pic. Ton offre doit tenir le pic avec une marge. Si le graphique touche la limite régulièrement, tu es près du plantage ; s’il reste au tiers de la limite pendant des semaines, tu paies une mémoire que tu n’utilises pas.
Quelques règles pratiques :
- Pars du chiffre de l’éditeur quand il y en a un (Palworld, Rust), et vérifie-le avec la réalité au bout d’une semaine.
- Pars petit quand il n’y en a pas (Valheim, Garry’s Mod), puis surveille le graphique. Ajoute de la mémoire par paliers, pas en doublant.
- Re-mesure quand quelque chose change : un nouveau plugin, une carte plus grande, une mise à jour de modpack, plus de joueurs.
- Ne donne pas tout à Java. Garde de la marge, comme le recommande la documentation de Paper.
- La mémoire n’est pas la seule dimension. Regarde aussi le processeur et le disque : la documentation de Rust, par exemple, demande un disque SSD ou NVMe.
Et l’offre gratuite ?
Un serveur gratuit ne tiendra pas un gros modpack, une grande carte Rust ou un monde Palworld avec un groupe complet. Ce n’est pas un défaut, c’est ce que veut dire gratuit. Pour un petit monde Minecraft entre amis, c’est un bon endroit pour essayer Paper, quelques plugins et une distance de rendu plus basse, et pour apprendre quels sont tes propres chiffres avant de payer quoi que ce soit. Le serveur Minecraft gratuit d’Alama est fait pour ça ; quand tu l’auras dépassé, les serveurs de jeu payants partent du jeu que tu choisis, et la question à poser est celle que cet article t’a donnée : qu’utilise vraiment mon serveur à son pic ?
En résumé
- Il existe des chiffres officiels pour Palworld (16 Go recommandés, 8 Go « bootable ») et Rust (12 Go de RAM libre, plus sur les grandes cartes). Valheim et Garry’s Mod n’en publient pas.
- Minecraft dépend de la distance de rendu, de la dispersion des joueurs, des plugins et des mods. Le tas doit rester en dessous de ce que la machine a.
- Plus de RAM ne règle que les problèmes de mémoire. Regarde le temps de tick avant de monter en gamme.
- Mesure au moment le plus chargé de ta semaine, et redimensionne à partir de la mesure.