Comment corriger le lag de mon serveur FiveM et la 'server thread hitch warning' ?

Vous voyez sans cesse server thread hitch warning: timer interval of XXX milliseconds dans la console de votre serveur FiveM, pendant que les joueurs se plaignent de lag ou de rubber banding ? Cela signifie que le thread serveur n'arrive plus à suivre. Voici ce que veut dire ce message, comment repérer les ressources lourdes avec resmon et comment corriger les quatre principaux coupables.

Que signifie 'server thread hitch warning' ?

FXServer exécute le cœur de votre serveur — la synchronisation des joueurs, les events et la majeure partie de la logique de vos scripts — sur un seul thread principal (svMain). Ce thread travaille en ticks courts. Si un tick dure bien plus longtemps que prévu, par exemple 250 millisecondes au lieu de quelques-unes, le serveur enregistre une hitch warning avec le temps mesuré. Pendant un tel blocage, tout se fige en même temps : les joueurs sont renvoyés à leur position précédente, les véhicules restent immobiles et les events arrivent en retard.

Comme tout ce travail s'effectue sur un seul thread, c'est la vitesse single-thread du CPU qui est déterminante — pas le nombre de cœurs ni la quantité de RAM. En pratique, la cause n'est pourtant presque jamais une machine lente, mais une ressource qui monopolise le thread. Cet article concerne spécifiquement FiveM ; le lag sur un serveur Minecraft fonctionne très différemment et dispose de son propre article d'optimisation.

Étape 1 : repérez les ressources lourdes avec resmon

1. Connectez-vous à votre serveur, ouvrez la console client avec F8 et tapez resmon 1. La fenêtre du moniteur de ressources apparaît.
2. Observez la colonne CPU msec : elle indique combien de millisecondes une ressource coûte par frame. Laissez la fenêtre ouverte un moment pendant que vous jouez.
3. Interprétez les valeurs : une ressource saine reste sous 0,10 ms. Un script constamment au-dessus de 1,00 ms est lourd ; des pics de plusieurs millisecondes désignent directement le coupable.
4. Resmon mesure votre client. Pour profiler le thread serveur lui-même, utilisez l'onglet Console du panel MC-Node : tapez profiler record 500, attendez la fin de l'enregistrement, puis tapez profiler view. Le lien affiché montre, ressource par ressource, quelles fonctions retardent le tick ; dans txAdmin, les graphiques du dashboard affichent aussi les temps de tick.
5. Pas de pic évident ? Arrêtez temporairement les ressources suspectes avec stop nomressource dans la console et vérifiez si les warnings disparaissent. En écartant la moitié des ressources à chaque essai, vous trouverez le coupable même sans profiler.

Étape 2 : corrigez les quatre principaux coupables

1. Scripts avec des boucles trop serrées — Une boucle comme while true do ... Citizen.Wait(0) end s'exécute à chaque tick, même quand il n'y a rien à faire. Augmentez le temps d'attente, par exemple Citizen.Wait(1000), pour les vérifications qui n'ont pas besoin de tourner en continu, et faites réagir votre code aux events plutôt que de faire du polling. Si un script chiffré (escrow) ou abandonné reste lourd, le remplacer par une alternative maintenue est presque toujours le meilleur choix.
2. Textures de véhicules trop lourdes (YTD) — Les voitures addon avec des textures 4K ou 8K dévorent la mémoire de streaming : les joueurs subissent des saccades, du texture loss et de longs temps de téléchargement. Réduisez les textures à 2K maximum, supprimez les variantes de livery inutilisées et méfiez-vous des packs de plusieurs centaines de mégaoctets. Pour installer des véhicules proprement et sans les alourdir, consultez le guide des voitures addon.
3. Requêtes de base de données bloquantes — Une requête synchrone fige le thread serveur jusqu'à la réponse de la base de données. Utilisez un wrapper asynchrone à jour comme oxmysql, remplacez les vieux scripts mysql-async et ajoutez des index sur les tables très sollicitées comme users et owned_vehicles. Enregistrez les données des joueurs par lots plutôt qu'à chaque petite modification. Vous trouverez les identifiants de votre base de données sous l'onglet Databases.
4. Trop d'entités — Chaque véhicule, prop et ped spawné doit être synchronisé à chaque tick ; des milliers de véhicules abandonnés rendent cela nettement plus coûteux. Utilisez un script de cleanup qui supprime les véhicules vides après quelques minutes, limitez les scripts de spawn et méfiez-vous des maps qui placent énormément de props — voir aussi le guide des MLO et maps custom.

Quand le matériel est-il vraiment le goulot d'étranglement ?

Le piège classique consiste à tout mettre sur le dos de l'hébergement alors qu'un seul script dévore 90 % du temps de frame — le profiler le montre sans pitié. Mais l'inverse existe aussi. Resmon est propre, le profiler répartit le temps de tick équitablement entre de nombreuses petites tâches sans pic évident, et les warnings n'apparaissent qu'avec beaucoup de joueurs ? Vous atteignez alors la limite single-thread du CPU. Plus de RAM ou des slots supplémentaires n'y changeront rien ; seul un matériel avec une fréquence par cœur plus élevée peut encore aider.

Messages et situations fréquents

• Hitch warnings au démarrage — Lors d'un (re)démarrage, le serveur charge toutes les ressources en même temps ; quelques warnings sont alors normaux. Seuls les messages qui reviennent pendant le jeu posent problème.
• sync thread hitch warning ou network thread hitch warning — Ces variantes pointent généralement vers la couche de synchronisation : trop d'entités ou de joueurs. Nettoyez les entités (étape 2, point 4) et vérifiez que OneSync Infinity est activé.
• Hitches à intervalles fixes — Si la saccade revient exactement toutes les cinq ou dix minutes, une tâche périodique est presque toujours en cause : une boucle de sauvegarde qui écrit tous les joueurs en même temps, ou un backup aux heures de pointe. Étalez les sauvegardes dans vos scripts et programmez les backups la nuit via les onglets Schedules et Backups.
• Rubber banding sans hitch warnings dans la console — Le problème vient alors probablement du côté client ou du réseau du joueur. Demandez aux joueurs concernés de vérifier leurs propres fps et resmon ; des YTD trop lourds en sont souvent la cause.
• Les warnings persistent après toutes les étapes — Lancez un enregistrement du profiler avec profiler record 500 juste après une saccade et conservez le résultat ; cela permet de remonter à la cause beaucoup plus vite.

Besoin d'aide ?

Avec resmon et le profiler, vous trouverez presque toujours la cause du lag serveur en quelques minutes. Si vous bloquez, ouvrez un ticket via notre page de support en indiquant le message exact de l'onglet Console ainsi que vos observations resmon ou profiler.