2026 Pterodactyl : comment répartir le CPU et la mémoire entre plusieurs serveurs de jeu ?

La documentation officielle de Pterodactyl distingue les limites de CPU, de mémoire et de disque par serveur ; elle ne fournit pas de quota universel adapté à tous les jeux (fonctionnement des nœuds et des conteneurs). Décision : mesurez le pic de chaque instance, fixez des limites révisables, puis conservez une marge pour l’hôte. Ne répartissez pas toutes les ressources d’emblée et ne prenez pas un plafond de conteneur pour une garantie de performance.

Adapté : vous administrez plusieurs jeux et voulez éviter qu’une instance dégrade les autres.
Moins adapté : vous cherchez un chiffre fixe de serveurs par machine, indépendamment des jeux, des versions et des usages.

Cette méthode concerne les administrateurs qui regroupent plusieurs serveurs auparavant hébergés sur des VPS, les responsables de communautés de jeu et les petites équipes qui ont besoin d’une politique de ressources vérifiable.

Dernière vérification : 25 octobre 2026. La documentation officielle consultée présente Pterodactyl 2.0 en bêta ouverte et 1.x comme branche stable ; vérifiez le statut correspondant à votre déploiement avant d’appliquer les réglages (documentation officielle de Pterodactyl).

Le nombre d’instances dépend des mesures, pas du nombre de nœuds

Dans Pterodactyl, le nœud fournit une base commune à plusieurs serveurs, tandis que les limites configurées encadrent les ressources attribuées à chaque instance. Cette organisation permet de gérer plusieurs services depuis un même environnement, mais le nombre affiché dans le panneau ne dit rien, à lui seul, de la capacité réelle de l’hôte. La documentation décrit le fonctionnement des nœuds et des conteneurs, sans publier de quota d’instances valable pour tous les jeux.

La première étape consiste donc à établir une référence par instance. Pour chaque serveur, consignez :

• le jeu, sa version, son type de serveur et les extensions chargées ;
• le niveau d’activité au moment de l’observation, par exemple une période calme ou une session chargée ;
• l’usage CPU, la mémoire résidente et l’espace disque consommé ;
• les signes perceptibles côté joueur, comme des ralentissements ou des interruptions ;
• les autres services actifs sur la machine au même moment.

Ces observations ne produisent pas une capacité garantie : elles décrivent votre installation, dans les conditions effectivement testées. Une mise à jour, un monde plus vaste, une extension supplémentaire ou un changement d’habitudes des joueurs peut modifier le profil. Reprenez donc les mesures après toute modification significative, plutôt que de reconduire sans contrôle les quotas d’une ancienne configuration.

Dans le panneau, examinez les paramètres de ressources associés à chaque serveur et notez leur état initial. L’API d’administration documente également les champs relatifs aux ressources d’un serveur ; utilisez la référence correspondant à la version de votre installation avant d’automatiser des changements (champs de ressources de l’API Pterodactyl).

Le plafond CPU encadre l’instance sans lui réserver un cœur

Attribuer le même plafond à toutes les instances peut sembler équitable, mais cette règle ignore la manière dont les services utilisent le processeur. Certains processus de jeu sont surtout sensibles aux performances d’un fil principal ; d’autres charges peuvent mieux profiter de plusieurs fils. Le type de jeu, sa version, les extensions et l’activité réelle déterminent le comportement que vous devez vérifier.

Un plafond CPU de conteneur n’équivaut pas à un cœur physique dédié. Il définit une contrainte de consommation, mais ne garantit ni un niveau de fréquence ni une latence donnée. Les mécanismes de contrôle décrits par la documentation Docker et par celle du noyau Linux dépendent de la configuration des groupes de contrôle et des ressources disponibles sur l’hôte (contraintes de ressources Docker, documentation du noyau Linux sur cgroup v2).

Pour régler un plafond de façon défendable, comparez plusieurs signaux au lieu d’agir sur une seule moyenne :

• Relevez l’utilisation CPU de chaque conteneur pendant une activité représentative.
• Consultez les journaux du jeu et les retours observés lors des ralentissements.
• Vérifiez si les autres instances consomment davantage au même moment.
• Modifiez le plafond de l’instance concernée, puis répétez un scénario comparable.
• Notez le réglage, le résultat et toute variation du reste de la machine.

Les statistiques Docker permettent d’afficher les mesures d’un conteneur en direct ou à un instant donné ; elles aident à comparer les instances, mais ne remplacent pas l’observation du comportement du jeu (commande Docker de statistiques des conteneurs).

docker stats --no-stream

Un relevé peut être consigné sous forme de champs plutôt que transformé en promesse de capacité :

instance : <nom_du_serveur>
CPU observé : <mesure pendant le scénario testé>
ralentissements : <observés / non observés>
autres charges actives : <description>
décision : <conserver / ajuster / retester>

Si le serveur reste fluide alors qu’il dispose d’une marge CPU, il n’y a pas de raison de lui donner automatiquement davantage. À l’inverse, si une instance plafonne en même temps que les autres restent peu sollicitées, examinez son comportement et les réglages de ses voisines avant d’augmenter toutes les limites. Cette démarche évite à la fois le partage aveugle et l’interprétation erronée d’un plafond comme une réservation matérielle.

La mémoire doit être plafonnée sans vider la réserve de l’hôte

La mémoire configurée pour un jeu doit tenir compte de son usage réel, de ses paramètres de démarrage et de ses périodes de forte activité. Une valeur choisie uniquement d’après la taille d’un fichier de configuration peut être trop faible lorsque la charge augmente ; un quota généreux n’est pas automatiquement préférable si plusieurs services en reçoivent un sans réserve globale.

Ne répartissez pas toute la mémoire physique entre les conteneurs. L’hôte, le panneau et les autres services ont eux aussi besoin de ressources. Une activité d’échange, une instance qui approche continuellement sa limite ou un processus arrêté sont des indices à analyser, pas des raisons de relever mécaniquement chaque plafond. Vérifiez d’abord si le problème provient d’un paramètre de démarrage, d’une extension, d’une évolution du monde ou d’une hausse de charge propre au serveur.

Le panneau et le moteur de conteneurs appliquent des contraintes qui doivent être interprétées avec la documentation de votre version. Docker explique le comportement des limites mémoire et les conséquences possibles d’une pression excessive sur la mémoire (gestion des limites mémoire par Docker). En complément, consultez le guide de configuration du nœud Pterodactyl afin de vérifier que l’environnement est configuré comme vous le pensez (configuration d’un nœud Pterodactyl).

Pour attribuer une limite, comparez l’usage habituel et le pic observé, puis contrôlez le résultat après une période chargée. Gardez une trace du réglage initial et de la nouvelle valeur : si le serveur est ensuite interrompu ou ralentit, vous pourrez relier l’incident à une modification précise, plutôt que de tâtonner sur l’ensemble des instances.

Le disque et le réseau complètent le diagnostic CPU-mémoire

Une répartition qui ne suit que le CPU et la mémoire peut manquer un autre goulot. Les sauvegardes, cartes, journaux et fichiers de mise à jour occupent de l’espace qui évolue avec le temps. Plusieurs serveurs qui écrivent ou chargent des données au même moment peuvent également dégrader les temps d’accès, même si leurs plafonds CPU semblent raisonnables.

Pour chaque instance, suivez l’évolution de l’espace utilisé et identifiez les répertoires qui grossissent. Distinguez les données nécessaires au fonctionnement des fichiers temporaires ou des journaux anciens, puis définissez une politique de conservation adaptée à votre jeu. Si vous gérez des cartes ou des fichiers importants, la méthode de contrôle du stockage est aussi une question de sauvegarde : le guide sur la gestion de la mémoire et des disques peut compléter votre planification.

Le réseau doit être mesuré dans les conditions de vos propres services. Relevez les transferts pendant une session représentative, puis comparez les périodes calmes et chargées. Une estimation fondée sur un nombre supposé de joueurs ne remplace pas ces mesures. Pour la même raison, ne déduisez pas une capacité de joueurs d’un débit théorique sans vérifier le protocole, les échanges réels, les autres services et les caractéristiques de votre liaison.

Enfin, organisez les ports et les adresses de manière à pouvoir identifier chaque instance sans ambiguïté. Notez le port, le jeu concerné et le point d’accès associé ; vérifiez ensuite les règles du pare-feu et la configuration du serveur. La présentation des limites de service peut vous aider à distinguer les ressources administrables sur la machine des caractéristiques qui doivent être vérifiées dans l’offre.

Une matrice compare les options de répartition

La matrice ci-dessous sert à choisir une méthode, pas à prédire un nombre d’instances. Inscrivez-y vos propres mesures : elles sont pertinentes uniquement pour les versions, extensions et scénarios que vous avez réellement testés.

Pour rendre cette comparaison opérationnelle, créez une fiche par instance avec les champs suivants : nom du serveur, version et configuration, scénario testé, pic CPU, pic mémoire, espace occupé, port, observation, limites appliquées et date de la prochaine vérification. Ajoutez une note indiquant si d’autres services tournaient simultanément. Cette dernière information est essentielle : une mesure faite avec un seul serveur actif ne décrit pas nécessairement le comportement du groupe complet.

Un test progressif sépare le problème local de la contention

Commencez par relever l’état de chaque serveur lorsqu’il fonctionne seul ou avec sa charge habituelle. Réalisez ensuite les essais dans les conditions que vous considérez représentatives : activation des extensions, chargement d’une carte, activité des joueurs ou autre travail normal du service. Évitez de transformer un test non représentatif en promesse de capacité, et n’utilisez pas de charge non autorisée contre des systèmes tiers.

Après les mesures individuelles, lancez progressivement les services qui doivent cohabiter. Observez les statistiques des conteneurs et celles de l’hôte pendant les mêmes périodes ; comparez les journaux du jeu avec les moments de ralentissement. Un relevé utile distingue les causes possibles :

• si un seul serveur ralentit alors que les ressources globales restent disponibles, vérifiez d’abord ses paramètres, ses extensions et ses limites ;
• si plusieurs serveurs se dégradent au même moment, comparez leurs pics et recherchez une concurrence sur le CPU, la mémoire ou le disque ;
• si la machine approche durablement ses limites, réduisez ou réorganisez la charge avant de poursuivre l’ajout d’instances.

Après chaque modification, répétez le scénario comparable et consignez l’avant et l’après. Si le résultat ne s’améliore pas, revenez au réglage précédent et examinez une autre cause. Ce suivi rend les ajustements réversibles et empêche de confondre corrélation et effet du nouveau quota.

Réallouer les limites ou changer de machine selon le goulot

Une instance qui manque de ressources n’implique pas automatiquement que l’hôte est trop petit. Si le problème reste local, corrigez d’abord la configuration de cette instance, puis vérifiez le résultat. Si plusieurs services souffrent au même moment, cherchez un conflit entre leurs périodes de pointe et ajustez leur organisation ou leurs plafonds avec prudence. Si la consommation totale reste proche des limites de la machine pendant les périodes normales, comparez la charge observée aux configurations disponibles avant de migrer.

Pterodactyl 2.0 étant présenté comme une bêta ouverte tandis que 1.x reste la branche stable dans la documentation consultée, notez la version du panneau avec vos mesures. Une modification de version ou de configuration du nœud peut changer le contexte de vos observations. Pour une installation en production, vérifiez la documentation correspondant à la version effectivement déployée, plutôt que d’appliquer aveuglément des consignes prévues pour une autre branche.

Combien d’instances peuvent partager un même nœud ?

Il n’y a pas de nombre fixe valable pour tous les jeux. La capacité dépend des profils CPU et mémoire, des données à lire et écrire, des périodes de pointe et des ressources que vous gardez pour l’hôte. Faites des mesures séparées, puis vérifiez la charge combinée. Si vous ne disposez pas de mesures représentatives, présentez le résultat comme une hypothèse à tester, jamais comme une capacité garantie.

Comment éviter qu’un serveur monopolise le processeur ?

Définissez une limite par instance à partir de relevés réalisés pendant des scénarios comparables, puis observez les ralentissements et les journaux du jeu après chaque ajustement. Un plafond peut empêcher un conteneur d’utiliser sans limite les ressources disponibles, mais il ne lui réserve pas un cœur physique. Si les instances se dégradent ensemble, cherchez une contention sur l’hôte plutôt que d’augmenter uniquement le quota d’un serveur.

Faut-il allouer toute la mémoire disponible aux jeux ?

Non. Conservez une réserve pour l’hôte et les services qui assurent le fonctionnement du nœud. Ajustez les limites d’après les pics réellement observés, en tenant compte des paramètres de démarrage. Si un processus est arrêté ou si une instance approche régulièrement son plafond, examinez d’abord sa configuration et la charge globale ; une hausse générale des quotas peut aggraver la pression mémoire.

Comment vérifier si plusieurs serveurs se disputent le CPU ou la mémoire ?

Comparez les mesures des conteneurs à celles de la machine pendant le même intervalle où surviennent les ralentissements. Contrôlez également les journaux, l’activité d’échange et les écritures disque. Si une seule instance est touchée sans pression générale, investigatez ses réglages propres ; si plusieurs services se dégradent simultanément, testez leur fonctionnement combiné et révisez la répartition selon les preuves recueillies.

Si vos mesures montrent que plusieurs instances ont besoin, de manière durable, de ressources stables sur une même machine, comparez votre charge à l’offre actuelle d’OSFP Cloud : serveur physique AMD en usage exclusif, processeur EPYC à 32 cœurs et 64 threads, mémoire ECC de 128 ou 256 Go, stockage NVMe direct et options de bande passante de 250 Mbit/s, 1 Gbit/s ou 2 Gbit/s sans limite de trafic, selon la configuration disponible. Ces caractéristiques ne déterminent pas à elles seules le nombre de jeux hébergeables ; confrontez-les à vos relevés et vérifiez les options dans la présentation des serveurs OSFP Cloud. Si vos serveurs sont légers, temporaires ou très irréguliers, un VPS ou une plateforme mutualisée peut rester plus approprié ; si la contention entre voisins, les limites de ressources ou la facturation du trafic compliquent l’exploitation de charges durables, l’indépendance d’une machine physique mérite d’être évaluée.

Questions

Combien de serveurs de jeu pouvez-vous faire tourner sur une seule machine Pterodactyl ?

Il n’existe pas de nombre universel : le résultat dépend du jeu, de sa version, des extensions, des périodes de forte activité et des limites configurées pour chaque conteneur. Mesurez les instances séparément, puis réunissez-les progressivement et observez la machine entière. Sans ces essais, un nombre fixe de serveurs serait une promesse non vérifiée.

Comment choisir une limite CPU pour chaque serveur de jeu ?

Commencez par relever l’utilisation CPU pendant une période calme et une période chargée, en notant également les ralentissements visibles et les journaux du serveur. Ajustez ensuite le plafond de l’instance qui présente un goulot identifié, puis recommencez le même test. Une limite de conteneur encadre la consommation ; elle ne réserve pas un cœur physique et ne garantit pas un niveau de performance.

Faut-il attribuer toute la mémoire à des quotas fixes ou conserver une réserve commune ?

Ne distribuez pas toute la mémoire physique aux serveurs de jeu. Gardez une marge pour le système, les services du panneau, les agents et les variations de charge. Les plafonds des instances doivent correspondre aux courbes réellement observées et à leurs paramètres de démarrage. Si une instance approche durablement sa limite, vérifiez son besoin propre avant d’augmenter tous les quotas.

Quels signes montrent que plusieurs serveurs se disputent les ressources ?

Comparez les mesures individuelles avec celles de l’hôte pendant les mêmes périodes. Une hausse des ralentissements accompagnée d’une saturation CPU, d’une mémoire presque entièrement consommée ou d’activité d’échange mérite une investigation. Vérifiez aussi les journaux, les écritures disque et la charge des autres instances. Une seule mesure isolée ne suffit pas à prouver une concurrence entre services.