Optimiser les performances serveur d'un FiveM

Sept articles différents, sur cinq ans, promettent la recette magique contre le lag d'un serveur FiveM. Le point commun à tous les vrais cas résolus : ce n'est jamais un seul réglage, mais une base solide (l'hébergement), sur laquelle reposent des scripts propres et une configuration cohérente. Ce guide couvre les trois dans l'ordre où ils comptent réellement.

Le CPU, pas la RAM, est le vrai goulot d'étranglement

FiveM (et RedM, qui tourne sur le même moteur FXServer) dépend énormément de la performance mono-cœur du processeur : chaque ressource s'exécute dans une logique largement séquentielle, ce qui veut dire qu'un processeur avec une fréquence élevée par cœur (plutôt qu'un simple grand nombre de cœurs) fait une différence directement sensible en jeu. C'est la raison pour laquelle deux serveurs avec le même nombre de vCPU peuvent se comporter très différemment selon le processeur physique qui les fait tourner. Un objectif raisonnable : garder l'utilisation CPU sous 60 % même lors des pics d'activité, pour conserver de la marge quand plusieurs scripts lourds se déclenchent en même temps.

Profiler les scripts avant de les soupçonner au hasard

Un script mal codé peut consommer à lui seul autant de ressources qu'une dizaine de scripts bien optimisés, ce qui rend le diagnostic à l'aveugle inefficace. FiveM fournit un outil intégré pour trancher : la commande resmon 1, tapée dans la console client (touche F8), affiche en temps réel la consommation de chaque ressource active. Côté serveur, txAdmin donne la même visibilité pour l'administrateur, avec l'historique CPU/RAM par ressource.

1. Ouvrez resmon 1 en jeu ou le tableau de bord txAdmin côté serveur.
2. Repérez les ressources qui consomment le plus en continu, pas seulement au pic (un script qui monte brièvement à l'activation d'un événement est normal, un script qui reste élevé en permanence ne l'est pas).
3. Vérifiez si la ressource est maintenue activement par son auteur : un script abandonné accumule les inefficacités au fil des mises à jour du jeu sans jamais être corrigé.
4. Remplacez ou retirez les scripts identifiés comme durablement gourmands plutôt que d'ajouter des ressources supplémentaires par-dessus pour compenser.

OneSync et sv_maxclients : la configuration qui gère la capacité de joueurs

Deux réglages du server.cfg ont un impact direct sur la capacité et la fluidité, bien au-delà de leur simplicité apparente :

• OneSync (set onesync on) répartit la synchronisation des entités (joueurs, véhicules, objets) entre les joueurs de façon plus intelligente que l'ancien mode par défaut. Sans OneSync activé, un serveur dépasse difficilement une trentaine de joueurs simultanés sans dégradation visible.
• sv_maxclients doit correspondre à ce que votre hébergement peut réellement supporter, pas à un chiffre ambitieux fixé à l'avance. Un slot ouvert au-delà de la capacité réelle du serveur dégrade l'expérience de tous les joueurs connectés, pas seulement du dernier arrivé.

Stockage et base de données : le goulot qu'on oublie

Un disque NVMe réduit nettement les temps d'accès par rapport à un SSD classique, un écart qui se ressent directement sur le chargement des ressources et sur chaque requête vers la base de données (inventaire, comptes, économie RP). Avec le temps, une base de données accumule des données qui ne servent plus (anciens logs, comptes inactifs, inventaires abandonnés) et ralentit ses propres requêtes : une purge régulière des tables inutiles, associée à des index corrects sur les colonnes les plus sollicitées, évite que cette dette ne s'accumule silencieusement.

Assets et textures : la cause de crash la plus sous-estimée

Un pack de véhicules ou de vêtements importés avec des textures 4K non compressées surcharge la mémoire des joueurs (source fréquente de crashs côté client) et ralentit le chargement des ressources côté serveur. Une résolution de 1024x1024 à 2048x2048 suffit largement pour l'écrasante majorité des usages en jeu ; réserver la 4K aux quelques éléments réellement mis en avant (véhicule vedette, tenue signature) plutôt que de l'appliquer par défaut à tout un pack.

Réseau et hébergement : la base sur laquelle tout repose

Le port par défaut de FiveM est le 30120 (UDP et TCP), à vérifier en priorité si des joueurs n'arrivent pas à se connecter malgré un serveur qui tourne normalement. Au-delà du port, deux critères d'hébergement pèsent plus que tout réglage logiciel :

• La localisation du serveur : plus il est proche géographiquement de votre communauté, plus la latence réseau de base est faible, avant même d'optimiser quoi que ce soit côté scripts.
• La protection anti-DDoS : une attaque, même de faible intensité, peut mettre à genoux un serveur par ailleurs parfaitement optimisé. C'est une protection d'infrastructure, pas un réglage qu'un administrateur peut ajouter après coup depuis son server.cfg.

Redémarrages planifiés et surveillance continue

Un redémarrage automatique toutes les 12 à 24 heures, programmé hors des heures de forte affluence, libère la mémoire accumulée par des scripts qui ne se referment pas toujours proprement, un phénomène courant sur les sessions longues. Pour suivre l'évolution dans la durée plutôt que réagir seulement aux incidents, des outils comme Grafana et Prometheus, couplés à txAdmin, donnent une visibilité CPU/RAM/latence dans le temps, utile pour repérer une dérive progressive avant qu'elle ne devienne un problème visible en jeu.

Checklist de performance

• Utilisation CPU sous 60 % même aux heures de pointe.
• Scripts gourmands identifiés via resmon 1 et txAdmin, pas au hasard.
• OneSync activé, sv_maxclients aligné sur la capacité réelle de l'hébergement.
• Base de données purgée régulièrement, disque NVMe pour les accès fréquents.
• Textures de véhicules et tenues compressées (1024x1024 à 2048x2048).
• Redémarrage automatique planifié, monitoring en place pour suivre la tendance.

Ces réglages supposent un serveur déjà installé correctement : si vous partez de zéro, notre guide de mise en place d'un serveur FiveM couvre les bases, et notre guide d'installation de Pterodactyl aide à garder une vue d'ensemble sur les ressources consommées si vous gérez plusieurs serveurs. Les principes d'architecture décrits dans notre guide de sécurisation côté serveur vont souvent de pair avec la performance : un script qui valide tout côté serveur est aussi un script plus facile à profiler. Si malgré tous ces réglages votre hébergement actuel reste le facteur limitant, notre page sur changer d'hébergeur FiveM explique comment migrer sans tout casser. Toutes nos offres d'hébergement FiveM sont dimensionnées pour ce cahier des charges, protection anti-DDoS incluse.