Stabilité d'un serveur FiveM : les indicateurs qui comptent vraiment

La stabilité serveur FiveM se mesure avec six indicateurs concrets : le temps de fonctionnement continu, la latence et la perte de paquets, la filtration réseau, le temps de frame du thread principal, la consommation des ressources et la fiabilité des sauvegardes. Surveillés ensemble, ils expliquent presque tous les crashs et les déconnexions en jeu. Voici comment les lire, quels seuils retenir et quoi corriger.

Les six indicateurs qui définissent la stabilité serveur FiveM

Un serveur qui « tourne » n'est pas forcément stable. Un processus peut rester actif pendant des jours tout en produisant des micro-freezes, des désynchronisations de véhicules et des timeouts de connexion. La stabilité se juge sur des mesures continues, pas sur l'absence de plainte dans le Discord de la communauté.

Indicateur	Où le lire	Seuil à viser
Uptime continu	txAdmin, console live du panel	Pas d'arrêt non planifié sur 7 jours
Latence joueur	Liste des joueurs, F8 côté client	Sous 60 ms en national
Perte de paquets	Netgraph client, logs de timeout	Sous 1 %
Temps de frame svMain	Graphique de performance txAdmin	Sous 5 ms en pic
Charge des ressources	Commande resmon	Aucun script au-dessus de 1 ms au repos
Sauvegarde valide	Dump SQL + archive des ressources	Restauration testée chaque mois

Ces six lignes forment un tableau de bord minimal. Si l'un des voyants passe au rouge, les cinq autres donnent le contexte : une latence qui grimpe pendant que svMain explose ne se traite pas comme une latence isolée, la cause est côté CPU et non côté réseau.

Uptime et disponibilité : mesurer le temps de fonctionnement réel

L'uptime brut ne suffit pas, il faut distinguer les redémarrages planifiés des arrêts subis. Un roleplay avec economy persistante redémarre souvent une à deux fois par jour pour purger la mémoire et appliquer les mises à jour de scripts. Ces coupures sont saines, à condition qu'elles soient annoncées et programmées hors des heures de pointe. Pour la configuration côté machine, la page hébergement FiveM détaille les environnements adaptés à ce type d'usage.

Programmer les redémarrages plutôt que les subir

txAdmin embarque un planificateur et un détecteur de crash. Configure les créneaux dans l'onglet Settings puis Restarter, avec un préavis in-game. Les joueurs voient le compte à rebours et les scripts de sauvegarde ont le temps d'écrire en base avant l'arrêt.

# server.cfg : messages d'avertissement avant coupure
setr txAdmin-restartWarnings "30,15,10,5,4,3,2,1"
set txAdminAutoRestart true

Différencier un crash d'un arrêt propre

Ouvre le dernier fichier de log et cherche la ligne finale. Un arrêt propre se termine par une séquence d'extinction des ressources. Un crash laisse une trace brutale : dump du moteur, erreur de segmentation ou message Server unexpectedly stopped. Note l'heure, puis croise avec l'activité du serveur (nombre de joueurs, événement RP en cours, script déployé la veille).

• Crash récurrent à heure fixe : tâche planifiée, sauvegarde ou cron qui sature la machine.
• Crash au pic de fréquentation : limite CPU ou script qui ne supporte pas la charge.
• Crash après un déploiement : ressource fautive, retour arrière immédiat sur la version précédente.

Latence, perte de paquets et filtrage des attaques

La latence perçue par les joueurs mélange trois choses : la distance réseau, la qualité du routage et le temps que met le serveur à traiter un tick. Avant d'accuser la connexion, compare le ping affiché dans la liste des joueurs avec un simple test ICMP vers l'IP du serveur. Un écart important signale une surcharge applicative, pas un problème de transit.

Lire la perte de paquets côté client

Demande à un joueur d'ouvrir la console F8 et de taper netgraph. Le graphe affiche le ping, la gigue et les paquets perdus. Une perte supérieure à 1 % provoque des téléportations de véhicules et des tirs qui n'enregistrent pas. Au-delà de 5 %, le client déclenche un timeout.

# Diagnostic réseau depuis une machine cliente
ping -c 20 ip.du.serveur
mtr -rwc 50 ip.du.serveur

Ce que l'anti-DDoS change concrètement

Une attaque volumétrique ne se voit pas toujours comme une coupure. Elle se manifeste d'abord par une montée de la perte de paquets et des déconnexions groupées, souvent pendant un événement annoncé publiquement. La filtration réseau est active en permanence chez Nexus Games et le port de jeu bénéficie d'un lien à 1 Gbit/s.

Pour les communautés visées de façon répétée, l'option Anti-DDoS Premium, disponible sur FiveM et RedM, place le serveur derrière un proxy, masque l'IP d'origine et porte la capacité de filtration à 10 Gbit/s. Masquer l'IP réelle règle la majorité des attaques ciblées, puisque l'attaquant ne dispose plus que de l'adresse du proxy. Le même dispositif protège un Serveur RedM.

# server.cfg : ne pas exposer les IP des joueurs aux scripts tiers
sv_endpointPrivacy true

OneSync, temps de frame et charge du thread principal

FiveM ne fonctionne pas avec un tickrate fixe comme un serveur source classique. Le moteur exécute une boucle dont le temps de frame varie selon la charge des ressources. C'est le thread svMain qu'il faut surveiller : tant qu'il reste sous 5 ms, la synchronisation est fluide.

Le hitch warning, premier signal d'alerte

Quand une frame dépasse le seuil, la console affiche un avertissement du type server thread hitch warning: timer interval of 250 milliseconds. Un hitch isolé au démarrage est normal. Des hitchs répétés en pleine partie provoquent des rubberbands et des PNJ figés. Chaque message pointe généralement la ressource responsable.

Choisir le bon mode de synchronisation

OneSync gère la synchronisation des entités côté serveur. Le mode standard couvre les configurations jusqu'à 32 joueurs simultanés. Au-delà, OneSync Infinity devient nécessaire : il s'active avec l'Element Club, l'abonnement Cfx.re. La licence FiveM elle-même reste gratuite, seuls les slots supplémentaires et Infinity dépendent de cet abonnement.

# server.cfg
sv_maxClients 48
set onesync on
set onesync_population true
set onesync_distanceCullVehicles true
set onesync_forceMigration true

Le culling de distance réduit fortement la charge : les véhicules et entités hors de portée cessent d'être synchronisés pour chaque client. Sur une map dense avec de nombreux véhicules stationnés, l'effet sur le temps de frame est immédiat.

Consommation des scripts, mémoire et base de données

La majorité des instabilités vient des ressources installées, pas du binaire du jeu. Un script mal écrit qui exécute une boucle while true do sans Wait suffisant consomme du temps CPU en continu, même serveur vide.

Auditer avec resmon et le profiler

La commande resmon classe les ressources par temps d'exécution. Lance-la côté client via F8 pour la charge client, et depuis la console serveur pour la charge serveur. Trie par CPU, note tout ce qui dépasse 1 ms au repos.

# Console serveur : enregistrer 500 frames puis analyser
profiler record 500
profiler save
profiler view

Mémoire et fuites

Une consommation RAM qui monte sans jamais redescendre sur plusieurs heures traduit une fuite mémoire. Note la valeur au démarrage, puis toutes les deux heures. Un framework RP complet type ESX ou QBCore avec une centaine de ressources demande couramment 6 à 8 Go pour respirer sur une population de 48 joueurs.

Requêtes SQL lentes

La base de données est le goulot d'étranglement classique des serveurs économie. Active l'avertissement de requête lente dans oxmysql : chaque requête au-delà du seuil apparaît en console avec son temps d'exécution et la ressource appelante.

# server.cfg
set mysql_slow_query_warning 150
set mysql_debug false

Une requête qui dépasse 150 ms bloque le thread qui l'attend. Ajouter un index sur la colonne identifier des tables joueurs règle souvent le problème en une seule commande SQL.

Sauvegardes, journaux et routine de surveillance quotidienne

Une sauvegarde qui n'a jamais été restaurée n'est pas une sauvegarde. Deux jeux de données comptent : le dossier resources avec le fichier server.cfg, et la base MySQL qui contient les personnages, les véhicules et l'inventaire. Les sauvegardes automatiques du NexusPanel couvrent le premier, le dump SQL reste à planifier.

# Dump quotidien avec horodatage
mysqldump -u fivem -p --single-transaction --quick fivem_db > /backups/fivem_$(date +%F).sql

# Planification via cron, chaque nuit à 4h
0 4 * * * /usr/local/bin/backup-fivem.sh >> /var/log/backup-fivem.log 2>&1

La routine en cinq minutes

1. Ouvrir le graphique de performance txAdmin et repérer les pics de temps de frame des dernières 24 heures.
2. Scanner les logs à la recherche de hitch warning, SCRIPT ERROR et connection timed out.
3. Comparer la RAM utilisée à la valeur relevée après le dernier redémarrage.
4. Vérifier la présence et la taille du dump SQL de la nuit.
5. Contrôler le nombre de kicks anti-cheat, un pic anormal précède souvent une instabilité.

Tester la restauration

Une fois par mois, restaure le dernier dump sur une base de test et lance le serveur sur un port secondaire. Si les personnages se chargent et que l'inventaire est intact, la chaîne de sauvegarde est validée. La documentation officielle Cfx.re détaille les paramètres de configuration à conserver dans ce jeu de fichiers : Source.

Documente chaque incident dans un fichier partagé avec ton équipe d'administration : date, symptôme, ressource suspectée, correction appliquée. Au bout de quelques semaines, les schémas se répètent et le diagnostic devient immédiat. D'autres guides d'administration sont regroupés sur le Blog Nexus Games, et les configurations types par jeu sur Tous nos serveurs de jeux.

Conclusion

Commence par le temps de frame du thread principal : c'est l'indicateur qui explique le plus grand nombre de plaintes, bien avant la latence réseau. Lance resmon, supprime ou remplace toute ressource au-dessus de 1 ms au repos, puis active le culling de distance OneSync. L'erreur à éviter en priorité : empiler des scripts sans jamais mesurer leur coût, puis conclure que la machine est trop faible. Mesure d'abord, ajoute ensuite.

FAQ

Quel build d'artifacts FiveM faut-il utiliser pour éviter les crashs ?

Reste sur la version marquée « recommended » plutôt que sur la dernière « latest ». Le build recommandé a passé plusieurs jours de tests en production sur de nombreux serveurs, alors que le build le plus récent peut contenir des régressions non détectées. Change de version uniquement quand un correctif dont tu as besoin y figure, teste toujours sur une instance secondaire avant, et conserve l'ancien dossier d'artifacts pour pouvoir revenir en arrière en quelques minutes.

Que signifie l'erreur « Server->client connection timed out » côté joueur ?

Le client n'a plus reçu de paquet du serveur pendant la durée définie par le timeout, généralement quinze secondes. Trois causes dominent : une perte de paquets sur le trajet réseau du joueur, un blocage prolongé du thread serveur causé par un script ou une requête SQL, ou une attaque en cours sur le port de jeu. Si plusieurs joueurs sont déconnectés au même instant, la cause est côté serveur ou réseau, pas côté client.

Une base de données MySQL lente peut-elle faire planter un serveur FiveM ?

Elle ne provoque pas un crash direct du processus, mais elle bloque le thread qui attend la réponse, ce qui fige la synchronisation pour tous les joueurs connectés. Les symptômes sont des gels de deux à dix secondes, des sauvegardes de personnages perdues et des inventaires désynchronisés. Active l'avertissement de requête lente d'oxmysql, ajoute des index sur les colonnes utilisées dans les clauses WHERE et limite les écritures répétées à intervalle court.