Le CPU est à 100 %

Un plateau sur le graphique CPU de l’onglet « Vue d’ensemble » n’est pas une urgence en soi : compiler un projet ou créer une archive utilisera honnêtement tous les cœurs, puis les libérera. C’est alarmant lorsque le plateau dure des heures et que la machine cesse de répondre. Voyons ce qui est en cause.

Étape 1. Identifier ce qui consomme des ressources

L’onglet « Écran » (VNC) est pratique pour travailler avec des programmes plein écran :

btop
htop

La console série ne transmet pas la taille de la fenêtre ; elle est toujours en 80×24, l’interface sera donc tronquée. Pour une console texte, utilisez les commandes standard :

top -b -n1 | head -20
ps aux --sort=-%cpu | head -10

Gardez l’arithmétique en tête : %CPU est calculé par cœur. 400 % sur VDS-3 signifie les quatre cœurs, tandis que 100 % sur VDS-4 ne représente qu’un cœur sur six.

Étape 2. Distinguer le CPU du disque

La charge moyenne (load average) augmente aussi à cause de l’attente d’E/S, pas seulement du calcul :

uptime
vmstat 1 5

Dans la sortie de vmstat, observez les colonnes us (code utilisateur), sy (noyau), wa (attente disque) et st (temps volé). Un wa élevé signifie que le CPU est inactif en attente du disque — le goulot d’étranglement est la vitesse d’écriture, pas le calcul. Le plateau disque de nos offres est fixé par une règle : 60 Mo/s d’écriture par cœur, pas moins de 60 et pas plus de 400 Mo/s, la lecture est deux fois plus élevée, et un burst trois fois supérieur au plateau dure 30 secondes. Si une tâche écrit en continu, le burst prendra fin et vous atteindrez le plateau.

Étape 3. Analyser un processus précis

pidstat -p <pid> 1 5
cat /proc/<pid>/status
journalctl -u <service> -n 100 --no-pager

Constats fréquents :

• une application web tourne en boucle infinie après une requête échouée ;
• la base de données exécute une requête sans index — consultez son propre journal des requêtes lentes ;
• une tâche cron démarre plus souvent qu’elle ne peut se terminer, et les instances s’accumulent : ps aux | grep <name> en affichera une dizaine de copies ;
• un mineur qui s’est introduit sur la machine via un mot de passe root faible. Le signe est un processus au nom dénué de sens exécuté sous un utilisateur non standard, avec une bande passante sortante élevée. Dans ce cas, il est plus simple de réinstaller la machine depuis l’onglet « Accès » que de la nettoyer.

Étape 4. Limiter, ne pas tuer

Si le processus est nécessaire mais ne doit pas gêner le reste :

renice -n 15 -p <pid>
systemctl set-property myapp.service CPUQuota=200%

CPUQuota=200% correspond à deux cœurs complets. Une limite systemd survit au redémarrage d’un service ; renice non.

Avant de tuer un processus avec kill -9, essayez un systemctl stop classique. Tuer une base de données de force vous coûte des fichiers corrompus et une longue récupération au démarrage suivant.

Quand ce n’est pas le code

Si la charge est légitime et constante, le CPU Ryzen 9 7950X fait son travail — il n’y a simplement pas assez de cœurs pour la tâche. L’offre ne peut être changée qu’à la hausse, avec un paiement supplémentaire pour les jours restants de la période payée : consultez l’article Upgrading your plan and paying the difference. Le retour à une offre inférieure n’est pas disponible, alors assurez-vous d’abord, à l’aide des graphiques sur une semaine et un mois, que le plateau n’est pas un événement isolé.