Comment faire tourner un serveur Hytale stable pour sa communauté

Un serveur Hytale communauté ne s'écroule presque jamais à cause du nombre de joueurs connectés : il s'écroule à cause d'une mémoire mal calibrée, d'un script qui boucle, d'une distance de vue trop généreuse et d'une sauvegarde que personne n'a jamais restaurée. Les réglages ci-dessous sont ceux qui font tenir une instance publique sur la durée, semaine après semaine.

Ce qui casse une instance Hytale quand la population monte

La charge d'un monde persistant ne dépend pas seulement du nombre de connexions simultanées. Elle dépend surtout du volume de chunks chargés en même temps, du nombre d'entités actives, des scripts exécutés à chaque tick et des écritures disque déclenchées par la sauvegarde automatique. Vingt joueurs regroupés sur une même base coûtent bien moins cher que vingt joueurs dispersés aux quatre coins de la carte.

Les symptômes se ressemblent toujours : blocs qui reviennent en arrière, coups qui ne s'enregistrent pas, mobs qui téléportent, déconnexions en série pendant les pics de fréquentation. Avant de toucher au matériel, il faut savoir lequel des trois goulots est en cause : le processeur (tick saturé), la mémoire (pauses du ramasse-miettes) ou le réseau (latence et pertes).

• Tick saturé : le temps de traitement d'un tick dépasse sa durée cible, tout ralentit uniformément.
• Pauses mémoire : le jeu se fige une à deux secondes, régulièrement, puis repart normalement.
• Problème réseau : seuls certains joueurs sont affectés, le tick reste sain côté console.
• Disque saturé : les ralentissements coïncident avec l'autosave ou une sauvegarde planifiée.

Le diagnostic conditionne le réglage. Ajouter de la mémoire à une instance dont le tick est mangé par un script d'événements ne changera strictement rien. Pour une communauté qui grandit vite, la trajectoire matérielle se prépare en amont, et une plateforme adaptée à hébergement Hytale évite de migrer dans l'urgence un monde de plusieurs gigaoctets un soir d'affluence.

Dimensionner la mémoire et le processeur sans gaspiller

Quelle quantité de RAM prévoir selon la charge

Hytale s'appuie sur une base Java côté serveur, avec la même logique de dimensionnement que les autres mondes voxel persistants. Surallouer la mémoire n'est pas neutre : un tas trop grand allonge les cycles de collecte et produit des micro-freezes plus longs. Le bon réglage vise un tas confortable mais borné, avec de la marge système en dehors.

Profil de communauté	Ordre de grandeur mémoire	Point de vigilance
Groupe privé, 5 à 10 joueurs, contenu de base	3 à 4 Go	Distance de vue et autosave
Communauté ouverte, 20 à 40 joueurs	6 à 8 Go	Entités et chunks chargés simultanément
Serveur modé avec scripts personnalisés	8 à 12 Go	Fuites mémoire des add-ons
Réseau multi-mondes ou minijeux	12 Go et plus, réparti par instance	Isolation des processus

Régler le tas Java et le ramasse-miettes

Fixer -Xms et -Xmx à la même valeur évite les redimensionnements du tas en pleine partie. G1GC avec une pause cible courte reste le réglage le plus prévisible pour un monde persistant. Adapte le nom du binaire à celui livré avec ta version.

java -Xms6G -Xmx6G \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=50 \
  -XX:G1HeapRegionSize=8M \
  -XX:+ParallelRefProcEnabled \
  -XX:+AlwaysPreTouch \
  -jar hytale-server.jar nogui

Le processeur compte plus que le nombre de cœurs

La boucle de simulation d'un monde voxel reste dominée par un thread principal. Une fréquence élevée et un cache large font davantage pour la fluidité que douze cœurs mutualisés entre plusieurs clients. Un Ryzen 9 7950X3D associé à de la DDR5 ECC et à du stockage NVMe donne exactement ce profil : tick régulier, chargement de chunks rapide, autosave qui ne bloque pas la partie.

Mods et scripts : la première cause d'instabilité

Une procédure d'ajout en trois temps

La règle qui évite 90 % des incidents : jamais deux ajouts en même temps, jamais un ajout sans sauvegarde préalable. Le modding annoncé pour le jeu repose sur des paquets de contenu et des scripts côté serveur, ce qui rend la moindre erreur de version bloquante au démarrage. Le calendrier et les outils officiels sont détaillés sur le site du studio (Source).

1. Sauvegarde manuelle du monde et de la configuration avant toute manipulation.
2. Installation d'un seul add-on, redémarrage, lecture complète du log de démarrage.
3. Observation sur une session réelle, puis validation avant le suivant.

Repérer le script qui mange le tick

Un script mal écrit qui parcourt toutes les entités chargées à chaque tick suffit à faire chuter les performances d'un monde entier. Les journaux sont le premier réflexe : cherche les avertissements de tick long et les exceptions répétées avant d'incriminer la machine.

cd /home/container/logs
grep -iE "can't keep up|tick took|OutOfMemory|Exception" latest.log | tail -n 40

Les administrateurs venus de Serveur Minecraft retrouveront la même discipline : versionner les fichiers de configuration, garder une copie du dossier de mods qui fonctionnait, et ne jamais mettre à jour un add-on la veille d'un événement communautaire.

Garder une trace des versions

Un simple fichier texte à la racine, mis à jour à chaque modification, fait gagner des heures lors d'un retour en arrière. Note la date, le nom de l'add-on, sa version et l'effet constaté. Sans cet historique, la restauration devient un jeu de devinettes.

Latence, tick rate et qualité du réseau

La latence perçue par un joueur combine trois éléments distincts : son trajet réseau jusqu'à la machine, la stabilité du tick côté simulation, et le volume de données envoyé à son client. Agir sur le troisième est souvent le plus rentable, parce que c'est le seul entièrement sous contrôle de l'administrateur.

La distance de vue est le curseur le plus efficace. Chaque unité supplémentaire augmente de façon quadratique le nombre de chunks chargés et diffusés. Sur une communauté de trente joueurs, réduire cette valeur d'un ou deux crans transforme la fluidité sans que personne ne s'en plaigne réellement en jeu.

# exemple de fichier de configuration serveur (format YAML)
view-distance: 8
simulation-distance: 6
entity-activation-range: 24
autosave-interval-seconds: 600
max-players: 40
network-compression-threshold: 256

Côté réseau, un lien à 1 Gbit/s couvre très largement les besoins d'un monde voxel : le débit n'est jamais le facteur limitant, la régularité l'est. Pour distinguer un problème de trajet d'un problème de simulation, un test de route depuis le poste du joueur concerné donne la réponse en quelques secondes.

mtr -rwzc 100 ton-ip-de-serveur
# ou sous Windows
tracert ton-ip-de-serveur

Une protection anti-DDoS active en permanence évite l'autre scénario classique : une attaque volumétrique qui fait sauter tout le monde en pleine soirée. Elle est prise en charge côté infrastructure, il n'y a rien à configurer dans le jeu pour en bénéficier.

Serveur Hytale communauté : modération, rôles et règles d'administration

Hiérarchiser les permissions dès le premier jour

La stabilité technique ne survit pas à une administration floue. Donner les droits complets à trois amis parce qu'ils sont là depuis le début est la cause la plus fréquente de mondes perdus. Un serveur Hytale communauté sain repose sur des rôles limités, chacun avec le strict nécessaire.

Rôle	Droits accordés	Droits refusés
Joueur	Jeu, chat, signalement	Commandes de gestion
Modérateur	Mute, kick, téléportation, consultation des logs	Fichiers, redémarrage, bannissement définitif
Administrateur	Bannissement, réglages en jeu, gestion des add-ons	Accès racine à la machine
Propriétaire	Accès complet, panel, sauvegardes

Whitelist, journalisation et accès au panel

Une whitelist n'est pas réservée aux mondes privés : elle sert aussi de sas pendant les phases sensibles, migration, mise à jour majeure, retour après incident. Active-la le temps de valider que tout tourne, puis rouvre. Les journaux de connexion et de commandes doivent être conservés assez longtemps pour remonter à l'origine d'un griefing signalé plusieurs jours après.

Côté panel, les sous-utilisateurs du NexusPanel permettent de déléguer la console live ou le WebFTP sans partager les identifiants principaux. Un modérateur peut ainsi relancer une instance figée sans pouvoir supprimer le monde. Les mots de passe et l'accès RCON méritent le même traitement qu'un accès administrateur classique : uniques, longs, jamais partagés dans un salon public.

Automatiser ce qui est répétitif

Les annonces de redémarrage, les rappels de règles et les signalements gagnent à passer par un canal externe. Relier le serveur à des bots Discord hébergés séparément évite que la modération dépende de la disponibilité d'une personne, et garde une trace écrite des sanctions.

Sauvegardes automatiques et plan de restauration

Une sauvegarde jamais testée n'est pas une sauvegarde. La question n'est pas de savoir si un monde sera corrompu un jour, mais combien d'heures de jeu seront perdues quand cela arrivera. Fixe d'abord une perte maximale acceptable, puis déduis-en la fréquence : trente minutes de progression perdue sur un serveur de construction, ce n'est pas la même chose que sur un monde survie.

Les sauvegardes automatiques planifiées côté panel couvrent le quotidien. Elles ne remplacent pas une copie hors de la machine, indispensable en cas de corruption silencieuse répliquée sur plusieurs points de restauration. La règle des trois copies sur deux supports, dont une à l'écart, reste la référence.

#!/bin/bash
DATE=$(date +%Y%m%d-%H%M)
SRC="/home/container/worlds"
DEST="/backups/hytale"

tar -czf "$DEST/world-$DATE.tar.gz" "$SRC"
find "$DEST" -name "world-*.tar.gz" -mtime +7 -delete

# exécution toutes les six heures
0 */6 * * * /usr/local/bin/backup-hytale.sh >> /var/log/backup-hytale.log 2>&1

Avant une archive, coupe l'écriture du monde ou arrête proprement l'instance : une copie prise en pleine sauvegarde interne produit des fichiers incohérents. Et une fois par mois, restaure une archive sur une instance secondaire pour vérifier qu'elle s'ouvre réellement. D'autres procédures d'administration sont détaillées sur le Blog Nexus Games.

Conclusion

Commence par la distance de vue et le tas Java, pas par la fiche technique de la machine : la majorité des ralentissements viennent d'une simulation trop large et de pauses mémoire, pas d'un manque de puissance brute. Ensuite, impose un add-on à la fois avec sauvegarde préalable. L'erreur à ne surtout pas commettre reste la même partout : découvrir le jour de l'incident que la dernière archive exploitable date d'il y a trois semaines.

FAQ

Comment tester des mods Hytale sans risquer le monde principal ?

Monte une seconde instance sur un port différent, avec une copie récente du monde et la même liste d'add-ons. Tu y installes la nouveauté, tu joues une session complète dessus, tu relis les journaux à la recherche d'exceptions et de ticks longs. Seulement après cette validation, tu appliques le changement sur l'instance publique, sauvegarde faite juste avant. Cette instance de test peut rester éteinte entre deux campagnes de vérification.

À quelle fréquence faut-il redémarrer un monde Hytale persistant ?

Un redémarrage planifié toutes les douze à vingt-quatre heures suffit dans la plupart des cas. Il libère la mémoire fragmentée, purge les entités orphelines et remet le tick à plat. Programme-le pendant les heures creuses de ta communauté, avec des annonces automatiques à quinze minutes, cinq minutes et une minute. Si tu dois redémarrer toutes les deux heures pour rester fluide, le problème vient d'une fuite mémoire dans un add-on, pas du jeu.

Peut-on faire tourner plusieurs mondes Hytale sur la même machine ?

Oui, à condition d'isoler chaque instance dans son propre processus, avec un port et un tas mémoire dédiés, et de ne pas additionner les allocations au-delà de la mémoire physique disponible. Laisse toujours une réserve pour le système et le cache disque. Surveille surtout le thread principal de chaque monde : deux instances chargées peuvent se disputer les mêmes cœurs et dégrader le tick des deux en même temps.