Serveur FiveM : combien de joueurs selon la RAM et le processeur ?

« Il me faut combien de RAM pour 64 joueurs ? » C'est la question qu'on nous pose le plus souvent sur FiveM. La bonne réponse est : ça dépend surtout de vos ressources, pas du nombre de joueurs. Un serveur roleplay chargé de scripts mal optimisés peut ramer à 30 joueurs, quand un serveur bien tenu en accueille 128 sur la même machine. Ce guide donne des repères chiffrés, explique ce qui consomme vraiment, et montre comment mesurer avant d'agrandir.

1. Ce qui consomme vraiment sur un serveur FiveM

Le serveur FXServer simule le monde, synchronise les entités et exécute vos ressources Lua, JavaScript ou C#. Trois choses déterminent la charge :

• Le thread principal : une grande partie du travail des scripts passe par un seul cœur. Un processeur rapide par cœur compte plus que le nombre de cœurs.
• Les ressources : chaque script qui tourne en boucle, interroge la base de données ou crée des entités ajoute de la charge, multipliée par le nombre de joueurs.
• La base de données : inventaires, véhicules, logements ; une base lente bloque les scripts qui l'attendent.

La RAM sert surtout à charger les ressources, les cartes personnalisées et le cache. Elle se remplit au fil des heures, notamment avec les véhicules et les MLO ajoutés.

2. Les repères chiffrés

Ces fourchettes viennent des serveurs que nous hébergeons. Elles supposent un framework moderne (ESX Legacy, QBCore ou Qbox) et des ressources correctement optimisées.

3. OneSync : la clé au-delà de 32 joueurs

Sans OneSync, un serveur FiveM est limité à 32 joueurs. OneSync fait passer la synchronisation des entités par le serveur, ce qui permet de monter bien au-delà. Il est activé par défaut dans txAdmin pour les nouveaux serveurs. Vérifiez votre server.cfg :

set onesync on
sv_maxclients 64

Au-delà de 48 joueurs, votre clé de licence Cfx.re doit correspondre à un abonnement qui autorise ce nombre d'emplacements : le nombre maximal de joueurs dépend aussi de votre abonnement Patreon Cfx.re, pas seulement du serveur.

4. L'impact du framework et des ressources

Le choix du framework est détaillé dans ESX ou QBCore : quel framework choisir.

5. Mesurer avant d'agrandir

Avant de passer à une offre supérieure, identifiez ce qui consomme. Dans la console du serveur ou txAdmin :

resmon 1            # côté client, dans la console F8 : temps CPU par ressource
profiler record 500 # côté serveur : enregistre 500 images
profiler view       # affiche le profil dans le navigateur

Repères à surveiller :

• Temps serveur par tick : il doit rester nettement sous 16 ms pour tenir 60 ticks par seconde. Les avertissements server thread hitch dans la console signalent un tick trop long.
• Ressources gourmandes : une ressource au-dessus de 1 à 2 ms en permanence côté serveur mérite d'être optimisée ou remplacée.
• RAM utilisée après plusieurs heures, pas au démarrage : c'est elle qui indique votre vrai besoin.

Le diagnostic complet est dans serveur FiveM qui lag : trouver la cause avec resmon.

6. La base de données, souvent oubliée

Un serveur RP fait des milliers de requêtes par minute. Une base mal réglée crée des ralentissements que l'on attribue à tort au processeur :

• hébergez la base sur le même serveur ou dans le même datacenter, jamais à distance ;
• ajoutez des index sur les colonnes recherchées (identifiant du joueur, plaque du véhicule) ;
• réservez à MariaDB une mémoire suffisante (innodb_buffer_pool_size), voir sécuriser et régler MariaDB.

7. Serveur FiveM clé en main ou VPS ?

Les offres serveur FiveM incluent la protection Anti-DDoS adaptée au trafic de jeu et txAdmin préinstallé. Pour gérer plusieurs serveurs sur une machine, voir le VPS Pterodactyl.

8. Gagner des joueurs sans changer de serveur

Avant d'augmenter les ressources, ces réglages font souvent gagner autant qu'une offre supérieure :

• Remplacer les ressources gourmandes repérées avec le profiler par des versions maintenues ou plus légères. Une seule ressource mal écrite peut coûter plus que cinquante bien écrites.
• Allonger les boucles : côté serveur, un script qui vérifie quelque chose toutes les 100 ms au lieu de chaque image divise sa charge d'autant.
• Nettoyer les entités : véhicules abandonnés, objets créés et jamais supprimés. Un nettoyage automatique régulier allège la synchronisation OneSync.
• Optimiser les véhicules et cartes ajoutés : textures en résolution raisonnable, modèles légers. Le streaming de fichiers énormes ralentit aussi le chargement des joueurs.
• Planifier un redémarrage quotidien dans txAdmin, aux heures creuses, pour repartir d'une mémoire propre.
• Mettre à jour les artefacts du serveur vers une version recommandée récente. Voir quel build d'artefacts choisir.

9. Prévoir la croissance de votre communauté

Une communauté RP grandit par paliers : ouverture, événements, arrivée de créateurs de contenu. Quelques réflexes évitent d'être pris de court :

1. Dimensionnez pour vos heures de pointe, pas pour la moyenne : le samedi soir compte plus que le mardi après-midi.
2. Gardez 30 % de marge en mémoire et en temps de calcul : une ressource ajoutée ou un événement imprévu ne doivent pas suffire à faire saturer le serveur.
3. Surveillez la tendance chaque semaine dans txAdmin : nombre de joueurs maximal, mémoire utilisée, avertissements dans la console.
4. Passez à l'offre supérieure avant l'événement, pas pendant : le changement d'offre se fait sans réinstaller, mais mieux vaut le faire à froid.

La protection Anti-DDoS compte aussi davantage à mesure que la communauté grandit : un serveur visible attire les attaques. La nôtre est incluse et adaptée au trafic de jeu, voir Anti-DDoS FiveM.

Questions fréquentes