Un serveur Rust peut démarrer à 7 Go de RAM, puis finir à 14 Go après deux jours de wipe sans changer de version. La taille de carte fixe le socle, les joueurs remplissent ce socle avec des bases, des coffres, des sleepers et des entités. Le bon réglage se choisit avant le wipe, car réduire une carte après coup revient presque toujours à effacer le terrain.
Relier RAM, taille de carte et joueurs avant le wipe
Rust charge une carte complète dès le démarrage. Ensuite, les joueurs ajoutent ce qui reste dans le monde : constructions, coffres, fours, pièges, véhicules et sleepers. Une carte 4000 n'est pas 33 % plus lourde qu'une 3000. Elle fait 16 km² au lieu de 9 km², soit 78 % de surface en plus. Cette surface apporte plus de monuments, plus de routes, plus de spawns de ressources et plus d'entités persistantes.
Fixez d'abord server.worldsize. 3000 convient à une petite communauté de 20 à 40 joueurs connectés. 3500 tient bien pour 50 à 80 joueurs. 4000 devient le format courant autour de 100 joueurs. Au-delà de 4500, la surface se paie en RAM et en sauvegardes plus lourdes. Réglez ensuite server.maxplayers. Ce nombre ne remplit pas la mémoire à lui seul, mais il autorise plus de bases, plus de coffres et plus de sleepers au fil du wipe.
Gardez 25 à 30 % de marge mémoire après le boot. Un serveur qui démarre à 10,5 Go sur une machine de 12 Go part déjà trop haut. À 85 % de RAM utilisée, le système garde peu de place pour les pics de sauvegarde. À 92 %, le swap ou le tueur OOM Linux finit par entrer dans l'histoire. Le message "Out of memory: Killed process" tombe souvent au pire moment, jamais quand Discord est calme.
Choisir une taille de carte Rust selon votre population
La bonne taille de carte n'est pas celle qui aligne le plus de monuments. C'est celle qui garde les joueurs assez proches pour se croiser, sans entasser 200 bases dans le même carré de 1 km². Une carte trop grande consomme plus et donne une impression de serveur vide. Une carte trop petite transforme chaque soirée en raid permanent, puis les départs arrivent au bout de 48 heures.
| Taille | Surface | Population visée | RAM à prévoir | Seuil qui se dégrade |
|---|---|---|---|---|
| 3000 | 9 km² | 20 à 40 joueurs | 6 à 8 Go | Plus de 70 actifs, monuments serrés |
| 3500 | 12,25 km² | 40 à 80 joueurs | 8 à 10 Go | Plus de 110 actifs, beaucoup de bases |
| 4000 | 16 km² | 80 à 130 joueurs | 10 à 14 Go | Plus de 170 actifs, saves longues |
| 4500 | 20,25 km² | 130 à 180 joueurs | 14 à 18 Go | Plus de 220 actifs, entités élevées |
| 5000 | 25 km² | 180 à 250 joueurs | 18 à 24 Go | Au-delà de 280 actifs, CPU et RAM suivent mal |
Ces chiffres visent un serveur vanilla ou proche vanilla, avec decay actif et sans 80 plugins uMod. Un serveur x10 avec stacks géants, kits, recyclage modifié et loot accéléré génère plus d'objets et pousse les joueurs à construire plus gros. À population égale, il dépasse souvent de 20 à 40 % la mémoire d'un serveur vanilla après une semaine de wipe.
Ne choisissez pas 6000 pour 60 joueurs. La carte fait 36 km², quatre fois une 3000. Les joueurs voyagent plus qu'ils ne se rencontrent, et la machine garde en mémoire une surface que personne n'utilise vraiment.
Dimensionner la RAM pour 20, 50, 100 et 200 joueurs
La RAM minimale sert à lancer le serveur. La RAM utile encaisse le wipe, les sauvegardes, les pics du samedi soir et les plugins. Sur Rust, le nombre de joueurs connectés pèse moins que ce qu'ils laissent derrière eux. 50 joueurs actifs pendant deux jours construisent moins qu'une communauté de 50 joueurs qui se relaient à 180 comptes uniques.
| Cas réel | Carte cohérente | RAM minimale | RAM à viser | Mauvais signe |
|---|---|---|---|---|
| 20 joueurs entre amis | 3000 | 6 Go | 8 Go | Plus de 6,8 Go utilisés sur 8 Go |
| 50 joueurs communautaires | 3500 | 8 Go | 10 à 12 Go | Save au-dessus de 2 secondes |
| 100 joueurs wipe régulier | 4000 | 12 Go | 16 Go | FPS serveur sous 20 en soirée |
| 200 joueurs public | 4500 à 5000 | 18 Go | 24 à 32 Go | RAM au-dessus de 90 % avant minuit |
Une marge de 4 Go semble large sur un petit serveur. Elle évite pourtant les redémarrages sales quand Unity charge une grosse sauvegarde, quand Linux garde du cache disque, ou quand un plugin fuit pendant six heures. À partir de 100 joueurs, raisonnez en plafond, pas en moyenne. Si votre serveur tourne à 11 Go en après-midi sur 12 Go disponibles, le pic de 21 h peut couper la soirée.
Les slots vides mangent presque rien. Les sleepers, eux, restent dans la sauvegarde. Une limite à 150 joueurs avec 40 connectés peut rester légère le premier jour, puis devenir lourde le troisième si 300 comptes uniques ont construit et dormi sur la carte.
Tester la charge Rust avant d'annoncer les slots
Annoncez vos slots après un test, pas avant. Un serveur qui boote vite sur une carte neuve ne prouve rien. Vérifiez le démarrage, la génération de carte, les ports, la sauvegarde et la mémoire après au moins 30 minutes avec vos plugins chargés.
- Fixez la carte et les ports dans la commande de lancement. Le port jeu par défaut est 28015 en UDP. Le RCON utilise souvent 28016 en TCP. Ouvrir seulement 28015 laisse le serveur visible, mais l'administration distante échoue.
- Lancez une carte propre avec une taille réaliste. Pour 80 joueurs, partez sur 3500 ou 4000, pas 5000. Un grand monde cache les problèmes pendant les premières heures, puis les affiche quand les bases apparaissent.
- Gardez la même seed pendant vos essais. Changer server.seed change les monuments et la répartition des ressources, donc la charge de départ.
- Contrôlez la sauvegarde avec server.saveinterval à 300 secondes. Cinq minutes limitent la perte en cas de crash sans écrire en boucle sur disque.
./RustDedicated -batchmode +server.port 28015 +rcon.port 28016 +server.worldsize 3500 +server.maxplayers 80
Sur le panel Starmine, vous changez la taille de carte, la seed, les slots et les ports sans réécrire la commande de lancement à chaque wipe. Les valeurs restent visibles au même endroit. Cela évite le classique 4000 annoncé sur Discord et 4500 réellement lancé. Voir le panel.
Repérer les performances Rust qui se dégradent en jeu
Les joueurs ne voient pas d'abord une RAM pleine. Ils voient des portes qui s'ouvrent en retard, une récolte qui revient en arrière, des tirs qui touchent mal. Côté serveur, regardez trois seuils ensemble : mémoire, FPS serveur et durée de save. Un serveur Rust sain reste proche de 30 FPS serveur. Sous 20 FPS en heure pleine, les actions commencent à se décaler. Sous 10 FPS, le combat devient mauvais, même avec un ping joueur à 35 ms.
La durée de sauvegarde décrit l'état réel de la carte. Une save sous 500 ms ne se sent pas. Entre 1 et 2 secondes, les joueurs attentifs voient parfois un micro-freeze. Au-dessus de 3 secondes toutes les 300 secondes, la carte a trop d'entités pour la machine ou le disque suit mal. Une base usine avec convoyeurs, tourelles, coffres et éclairage coûte du temps serveur. Multipliez-la par 80 clans et vous voyez où partent les millisecondes.
La mémoire devient dangereuse avant 100 %. À 85 %, surveillez. À 90 %, planifiez un redémarrage propre ou réduisez la charge. À 95 %, vous attendez un crash. Sur Linux, le journal peut contenir "Out of memory: Killed process". Ce n'est pas un crash Rust mystérieux. C'est le système qui abat le processus pour rester vivant.
tail -n 200 output_log.txt
Les plugins aggravent ces seuils quand ils stockent trop de données en JSON, scannent les conteneurs trop souvent ou déclenchent des timers toutes les secondes. Un plugin de statistiques mal écrit peut coûter plus cher qu'un passage de 3500 à 4000.
Réduire une carte Rust trop grande après un mauvais wipe
Réduire la taille de carte, changer la seed ou supprimer le dossier de monde force une nouvelle carte. Vous perdez le terrain, les bases, les coffres, les véhicules, les sleepers et les monuments générés. Les blueprints ne disparaissent que si vous effacez aussi la base de données des joueurs.
Quand une carte 5000 tombe sous 15 FPS serveur avec 90 joueurs, ajouter 4 Go de RAM peut sauver une soirée. Cela ne règle pas la cause. Passer de 5000 à 4000 coupe la surface de 25 km² à 16 km², soit 36 % de terrain en moins. La baisse de RAM varie selon la seed, mais 4 à 8 Go de différence sur un serveur chargé n'a rien d'anormal.
- Annoncez un wipe carte. Ne promettez pas de déplacer les bases. Rust ne sait pas réduire proprement un monde en gardant les constructions aux nouvelles coordonnées.
- Copiez le dossier lié à server.identity avant toute manipulation. Gardez au moins le dossier complet jusqu'au wipe suivant. Une sauvegarde de 2 à 8 Go se transfère vite, une communauté perdue ne revient pas vite.
- Gardez les blueprints si votre rythme de wipe les conserve. Supprimer uniquement la carte évite de punir les joueurs deux fois.
- Relancez avec une taille plus basse et une seed testée. Pour 70 joueurs, 3500 suffit. Pour 120 joueurs, 4000 reste le meilleur compromis. Pour 200 joueurs, 4500 passe mieux que 5000 si votre priorité va au combat et aux temps de save.
La mauvaise idée, c'est de baisser les slots sans toucher la carte. Vous limitez les entrées, mais vous gardez la même surface, les mêmes entités et les mêmes saves. Si le problème vient d'un monde trop grand, les slots ne libèrent presque rien avant le prochain wipe.
Guides
Est-ce que 16 Go de RAM suffit pour 100 joueurs sur Rust ?
Oui, avec une carte 4000 et un serveur vanilla ou peu moddé, 16 Go laisse une marge correcte. Si la RAM dépasse 14 Go avant le pic du soir, la carte ou les plugins sont déjà trop lourds pour tenir le wipe proprement.
Une carte Rust 5000 est-elle trop grande pour 60 joueurs ?
Oui, dans la plupart des cas. Une carte 5000 fait 25 km², alors qu'une 3500 fait 12,25 km². Pour 60 joueurs, vous payez presque deux fois plus de surface sans créer plus d'activité.
Les plugins Rust demandent combien de RAM en plus ?
Un petit lot de plugins propres ajoute souvent 500 Mo à 2 Go. Un serveur très moddé avec kits, économie, statistiques, stacks, loot modifié et logs détaillés peut ajouter 4 Go ou plus après quelques jours.
Changer le nombre de slots réduit-il la RAM utilisée ?
Très peu si la carte existe déjà. Les slots vides ne consomment presque rien. La RAM vient surtout de la taille de carte, des entités sauvegardées, des sleepers et des plugins chargés.