Diagnostiquer une surcharge CPU sur un serveur de jeu Linux

Une utilisation CPU élevée peut provoquer des ralentissements, des déconnexions et des temps de réponse irréguliers sur un serveur de jeu Linux. Sur un serveur VPS, une machine virtuelle ou un serveur dédié, le diagnostic doit distinguer le processeur, la mémoire, le stockage SSD, le réseau et les services d'hébergement. Avant de redémarrer ou de changer d'offre VPS chez un hébergeur cloud, identifiez le processus responsable et mesurez l'effet de chaque correction.

Vérifier la charge réelle

Connectez-vous en SSH avec un compte root ou un compte d'administration, puis observez la charge pendant plusieurs minutes. La commande uptime affiche la durée de fonctionnement et les load averages. Ces valeurs représentent une moyenne de tâches en attente de temps processeur ou d'accès aux ressources. Elles doivent être rapprochées du nombre de vCPU et de l'état réel des serveurs virtuels, plutôt que lues comme un pourcentage isolé.

uptime
nproc
mpstat -P ALL 1 5
free -h

Avec mpstat, regardez le temps passé en mode utilisateur, en mode système et en attente d'entrée-sortie. Une charge élevée avec beaucoup de temps d'attente n'est pas traitée comme une boucle CPU pure. Vérifiez aussi la mémoire disponible, le swap et l'espace disque. Cette distinction évite de modifier la configuration du jeu alors que le problème vient du stockage, d'un backup ou d'un service réseau.

Identifier le processus responsable

Utilisez top ou htop pour classer les processus par consommation CPU. Notez le nom, le PID, l'utilisateur et l'évolution de la consommation pendant plusieurs rafraîchissements. Un pic unique pendant une sauvegarde n'a pas la même cause qu'un processus qui reste en tête pendant toute la session.

top -o %CPU
ps -eo pid,ppid,user,%cpu,%mem,etime,cmd --sort=-%cpu | head -n 15

Dans un environnement Pterodactyl ou avec plusieurs serveurs de jeu, rattachez le PID au service ou au conteneur concerné avant toute action. Si vous utilisez un panneau de contrôle, comparez ses métriques avec la mesure SSH et votre outil de monitoring. Ne tuez pas un processus au hasard : exportez d'abord sa commande complète et vérifiez le propriétaire du service.

Distinguer le jeu, un plugin et un service

Si le processus du serveur de jeu consomme le CPU, comparez l'heure du pic avec les redémarrages, les connexions de joueurs, une génération de monde, une sauvegarde ou une tâche planifiée. Si un plugin ou un script apparaît séparément, désactivez une seule modification à la fois dans un environnement contrôlé afin de pouvoir revenir en arrière.

Pour un service géré par systemd sur Ubuntu, Debian ou une autre distribution Linux, vérifiez son état et ses journaux. journalctl aide à rapprocher une hausse de charge d'une erreur répétée, d'un redémarrage ou d'une tâche périodique :

systemctl --type=service --state=running
journalctl --since "30 min ago" -p warning..alert
journalctl -u nom-du-service --since "30 min ago"
systemctl list-timers

Mesurer avant de corriger

Conservez les observations : heure, load average, processus en tête, nombre de joueurs, événement en cours, mémoire disponible, activité disque et durée du pic. Cette trace permet de comparer deux essais et d'éviter une correction fondée sur une impression. Vérifiez aussi les limites du VPS, du serveur virtuel ou du serveur physique et les ressources disponibles dans votre espace d'hébergement avant de modifier les configurations du jeu ou du système d'exploitation.

Les actions prudentes consistent à arrêter une tâche planifiée non indispensable, réduire une opération connue pour être coûteuse, mettre à jour un composant après sauvegarde et limiter les processus concurrents. Contrôlez également les règles du firewall, l'adresse IP et les erreurs réseau, sans confondre un problème de bande passante avec une saturation CPU. Après chaque action, répétez la mesure. Une hausse de la fréquence des redémarrages ne corrige pas une cause racine et peut masquer les journaux utiles.

Éviter les fausses corrections

N'ajoutez pas de swap pour résoudre une saturation CPU : le swap concerne principalement la mémoire et peut augmenter les temps d'attente si le serveur manque de RAM. Ne modifiez pas le nombre de threads sans connaître le logiciel concerné. Ne changez pas plusieurs paramètres simultanément, car vous ne saurez plus lequel a eu un effet.

Si la charge réapparaît à intervalles réguliers, cherchez une tâche planifiée avec systemctl list-timers et la crontab du compte concerné. Si elle apparaît avec une action de joueur, examinez le plugin, le script ou la génération de contenu déclenchée par cette action. Si elle reste constante malgré l'arrêt du serveur de jeu, contrôlez les autres services, le panel d'administration et les processus système.

Savoir quand redimensionner

Un redimensionnement se justifie lorsque la charge reste élevée après identification des processus, réduction des tâches inutiles et vérification de la configuration. Comparez alors le profil des processeurs, la mémoire disponible, les entrées-sorties, la fréquentation, l'espace de stockage et les sauvegardes. La virtualisation permet de faire évoluer un serveur VPS ou une machine virtuelle, tandis que des serveurs physiques dédiés fournissent une machine à analyser séparément. Pour une migration, sauvegardez les données et la configuration avant de changer d'offre. Un VPS SSD peut réduire les attentes liées au stockage, mais il ne corrige pas à lui seul un processus qui monopolise le CPU.

Les machines virtuelles et l'hébergement VPS facilitent l'évolution progressive d'un serveur de jeu. Le monitoring doit toutefois rester actif après un changement de ressources. Comparez les métriques avant et après migration, notamment le CPU, la mémoire, le disque et le réseau. Pour une configuration complexe ou un incident persistant, rassemblez les journaux et sollicitez le support technique de votre hébergeur. Une stratégie de haute disponibilité et de redondance se conçoit séparément du diagnostic CPU. Consultez nos informations sur le VPS Linux, les serveurs dédiés et l'arbitrage entre serveur dédié et VPS.

Pour poursuivre votre diagnostic, consultez aussi notre guide sur Docker sur un VPS, les premiers réglages de sécurité d'un serveur dédié et la méthode de diagnostic d'un VPS inaccessible. Ces contrôles couvrent des causes différentes et doivent rester séparés dans votre analyse.