Augmenter la limite de processus d’un serveur de jeu Linux

Un serveur de jeu Linux peut afficher des erreurs de type Too many open files, refuser de lancer un processus ou interrompre un service lorsque la limite de processus est atteinte. Cette limite protège le système, mais une valeur trop basse peut gêner un serveur FiveM, Minecraft, Rust ou une application gérée par Pterodactyl sur un serveur VPS, une machine virtuelle ou un serveur dédié.

Ce guide explique comment mesurer la limite actuelle, choisir un réglage raisonnable et l’appliquer au bon niveau. L’objectif n’est pas de mettre une valeur illimitée partout, mais d’augmenter uniquement la capacité nécessaire et de vérifier le résultat après redémarrage. Les commandes supposent une administration en SSH avec un compte autorisé, parfois root ou doté de sudo.

Distinguer processus et fichiers ouverts

Deux limites Linux sont souvent confondues. La limite de processus concerne le nombre de processus qu’un utilisateur peut créer. La limite de fichiers ouverts concerne les descripteurs utilisés par les sockets, les journaux, les fichiers de configuration et les sauvegardes. Un serveur de jeu peut rencontrer l’une ou l’autre.

Commencez par identifier l’utilisateur qui exécute le service. Avec une session administrateur, observez ensuite les limites de votre shell :

whoami
ulimit -u
ulimit -n
ps -u utilisateur-du-serveur --no-headers | wc -l

Remplacez utilisateur-du-serveur par le compte réellement utilisé. La commande ulimit -u indique la limite de processus et ulimit -n celle des fichiers ouverts. Le compteur fourni par ps permet de comparer la consommation actuelle à la limite, sans modifier le VPS.

La mémoire RAM, l’espace disque, le stockage SSD, les processeurs, le CPU et la bande passante sont d’autres ressources à suivre. Ils ne sont pas augmentés par une modification de nproc. Une panne attribuée trop vite à la limite de processus peut en réalité venir d’une saturation de RAM ou d’un disque plein.

Vérifier le service et son gestionnaire

La valeur de votre terminal n’est pas forcément celle du serveur de jeu. Un service lancé par systemd, un conteneur Docker ou un panneau de contrôle comme Pterodactyl peut recevoir ses propres limites. Vérifiez d’abord le processus principal :

ps -eo user,pid,ppid,cmd | grep -E 'java|FXServer|RustDedicated' | grep -v grep

Pour un service systemd, remplacez mon-serveur.service par son nom :

systemctl status mon-serveur.service
systemctl show mon-serveur.service -p LimitNPROC -p TasksMax -p LimitNOFILE

LimitNPROC et TasksMax ne sont pas interchangeables. Le premier concerne la limite de processus du service, tandis que le second contrôle le nombre de tâches autorisées par le groupe systemd. Une valeur peut donc sembler correcte dans le shell alors que le service reste plafonné.

Consultez aussi les journaux du service :

journalctl -u mon-serveur.service -b --no-pager

Recherchez les messages liés à fork, resource temporarily unavailable, Too many open files et aux permissions. Les logs donnent le contexte nécessaire avant de toucher à la configuration.

Choisir une valeur raisonnable

Mesurez d’abord le besoin réel pendant une période de charge. Notez le nombre de processus du compte, les erreurs dans les journaux et les éventuels pics liés aux scripts, aux workers, aux extensions ou aux tâches de sauvegarde. Ajouter une marge évite les coupures lors d’un pic, mais une valeur démesurée réduit l’intérêt de la protection.

Sur une machine mutualisée, ne modifiez pas la limite globale uniquement pour un serveur. Préférez un réglage ciblé sur son compte ou son unité systemd. Sur un VPS Linux dédié à un seul usage, le réglage peut être plus souple, tout en conservant une surveillance de la mémoire, du CPU et du nombre de tâches. La virtualisation du serveur virtuel ne supprime pas les limites du système invité ni celles du gestionnaire de services.

Un hébergeur peut fournir un accès root, un panneau de contrôle ou une infogérance partielle. Identifiez ce qui est administré par votre équipe avant de modifier le noyau, systemd ou le conteneur. Pour héberger un jeu, privilégiez une configuration documentée et réversible plutôt qu’un réglage global appliqué à tous les serveurs virtuels.

Dans une offre cloud ou un hébergement dédié virtuel, la limite de processus reste une limite du système d’exploitation Linux et du service lancé. Elle n’est pas un indicateur direct du nombre de processeurs disponibles ni de la haute disponibilité. Pour administrer plusieurs serveurs, centralisez le monitoring, les sauvegardes et les alertes au lieu d’augmenter indistinctement chaque plafond.

Si l’erreur parle de fichiers ouverts et non de processus, travaillez sur LimitNOFILE ou ulimit -n. Augmenter uniquement le nombre de processus ne corrigera pas cette autre cause. Si le serveur ne répond plus sur son adresse IP, vérifiez aussi le service, le firewall et le réseau avant de modifier nproc.

Régler une unité systemd

Pour un serveur lancé par systemd, créez un remplacement local plutôt que de modifier directement le fichier fourni par le paquet :

sudo systemctl edit mon-serveur.service

Ajoutez seulement les directives nécessaires dans la section du service :

[Service]
LimitNPROC=4096
TasksMax=4096
LimitNOFILE=65535

Les nombres ci-dessus sont un exemple de configuration à adapter après mesure. Enregistrez, puis rechargez systemd et redémarrez le service :

sudo systemctl daemon-reload
sudo systemctl restart mon-serveur.service
systemctl show mon-serveur.service -p LimitNPROC -p TasksMax -p LimitNOFILE

Contrôlez ensuite les journaux et l’état du service. Un redémarrage réussi ne suffit pas : vérifiez que le processus utilise bien la nouvelle valeur et que le serveur de jeu accepte les connexions sur son port. Testez depuis une machine cliente et non uniquement depuis le VPS.

Régler une limite pour un utilisateur

Pour un service lancé par un compte dédié, les limites PAM peuvent convenir lorsque le programme est démarré dans une session compatible. Éditez le fichier de limites avec prudence et ajoutez une règle ciblée :

serveurJeu soft nproc 4096
serveurJeu hard nproc 4096

Les limites soft et hard s’appliquent aux sessions qui chargent ce mécanisme. Elles ne remplacent pas automatiquement les restrictions d’unité systemd, d’un conteneur ou du panneau d’administration. Après modification, ouvrez une nouvelle session SSH pour tester avec ulimit -u.

Ne mettez pas la limite dure à unlimited sans raison opérationnelle. Une limite bornée facilite le diagnostic et réduit le risque qu’un script défectueux crée un grand nombre de processus. Conservez une copie de la configuration et prévoyez un retour arrière documenté.

Cas de Pterodactyl et Docker

Si le serveur est géré par Pterodactyl, le processus peut être isolé dans un conteneur. La limite effective dépend alors du démarrage du conteneur et des réglages appliqués par le nœud. Vérifiez la configuration du serveur et du nœud avant de modifier le système hôte. Le panneau peut également appliquer une limite de mémoire ou de CPU indépendante.

Pour Docker, contrôlez la limite réellement visible dans le conteneur :

docker exec -it nom-du-conteneur sh -lc 'ulimit -u; ulimit -n; cat /proc/1/limits'

Une correction appliquée uniquement sur l’hôte peut ne pas être transmise au conteneur. Après tout changement, recréez ou redémarrez le conteneur selon votre méthode d’exploitation, puis relisez /proc/1/limits. Vérifiez aussi les volumes, les journaux et l’espace disque utilisés par le serveur.

Valider après la modification

Réalisez une vérification en quatre étapes : confirmez la valeur effective, démarrez le serveur, observez les journaux pendant une montée en charge et contrôlez la consommation de ressources. Gardez une copie du réglage et documentez la date, le service concerné, l’adresse IP ou le nœud concerné et la raison du changement.

Si l’erreur persiste, cherchez la cause exacte dans les logs. Il peut s’agir d’une fuite de processus, d’une boucle de script, d’un manque de mémoire, d’un disque saturé ou d’une limite de fichiers ouverts. Une limite plus haute masque parfois le symptôme sans corriger le problème.

Pour une exploitation durable, automatisez une alerte sur le nombre de tâches et surveillez les métriques du VPS. Testez également la restauration des sauvegardes et la procédure de redémarrage. Un réglage de limite est utile seulement s’il s’intègre dans une administration complète du serveur.

Pour aller plus loin, consultez aussi notre guide Docker sur un VPS, les conseils pour sécuriser un serveur dédié, la méthode de diagnostic des performances FiveM, le guide pour tester une restauration Pterodactyl et les informations sur les VPS Ubuntu.