Ce qui consomme vraiment
Un serveur Minecraft garde en mémoire les morceaux de carte — les « chunks » — chargés autour de chaque joueur, plus les entités qui s’y trouvent. Un joueur immobile dans une base déjà construite coûte donc très peu. Un joueur qui explore à dos de cheval force le serveur à générer du terrain neuf en continu, et c’est là que la mémoire et le processeur montent.
La conséquence est contre-intuitive : dix joueurs qui partent chacun dans une direction coûtent plus cher que trente joueurs rassemblés sur une même base. Dimensionner « au nombre de slots » est la première erreur.
Ordres de grandeur
| Situation | Mémoire | Palier AERVIOX |
|---|---|---|
| Paper, jusqu’à 10 joueurs | 2 Go | MC-1 (2 vCore) |
| Paper avec vos plugins, 10 à 30 joueurs | 4 Go | MC-2 (2 vCore) |
| Plus de 30 joueurs, nombreux plugins ou plusieurs mondes | 8 Go | MC-3 (4 vCore) |
| Grande communauté, beaucoup de plugins, gros mondes | 24 Go | MC-4 (8 vCore) |
Les plugins Paper se chargent au démarrage : plus vous en installez, plus la mémoire prise avant le premier joueur augmente. Comptez un palier de plus si votre liste de plugins est longue.
Chez AERVIOX, les serveurs Minecraft Java tournent sous Paper, qui accepte les plugins Paper. Les modpacks (Forge, Fabric) et la version Vanilla ne sont pas proposés.
La fréquence avant le nombre de cœurs
Le cœur logique du serveur Minecraft — la boucle de simulation — tourne sur un seul fil d’exécution. Un processeur à huit cœurs lents fera donc moins bien qu’un quatre cœurs rapides. Les cœurs supplémentaires servent à la génération de terrain, à la sauvegarde et au réseau, pas à la simulation.
- Réduisez la distance de vue avant d’acheter de la mémoire : passer de 12 à 8 chunks divise presque par deux la charge.
- Pré-générez la carte : la génération à la volée est la première cause de saccades.
- Limitez les entités par chunk, surtout sur un serveur de fermes automatiques.