Un processus MySQL très actif ne désigne pas directement le client responsable, et un nom de processus PHP ne suffit pas à identifier le script. Process Manager donne une première piste ; il faut ensuite relier propriétaire, activité mesurée et requêtes au même instant.
Intention de recherche : trouver le compte à l’origine d’une consommation anormale et corriger uniquement sa cause. Cette procédure suppose un accès administrateur root et protège les données de diagnostic, qui peuvent contenir des chemins privés ou des requêtes.
1. Attribuer les ressources avant d’intervenir
Problème et causes possibles
Distinguez pic bref, charge durable et tâche périodique. Une campagne commerciale, un cron qui se chevauche, un plugin WordPress coûteux, une boucle PHP, des bots ou un logiciel compromis peuvent produire des profils différents. Une forte consommation ne prouve pas une compromission.
Dans WHM, System Health, Process Manager, relevez Owner, PID, CPU et mémoire. Comparez avec Daily Process Log si des données historiques sont disponibles. Un processus qui utilise 100 % CPU peut occuper un seul cœur, pas tout le serveur.
ps -eo user,pid,ppid,pcpu,rss,etime,args --sort=-pcpu | head -n 25pidstat -u -r -d -U -p ALL 1 10ps -e -o user= | sort | uniq -c | sort -nrps donne un instantané ; son CPU n’est pas une mesure précise du dernier intervalle. pidstat, fourni par sysstat, mesure CPU, mémoire et I/O par tâche sur plusieurs intervalles. Des processus très courts peuvent disparaître entre deux échantillons. Les compteurs I/O ne représentent pas toutes les attentes d’une application.
Le dernier pipeline compte les processus par propriétaire. Une hausse sans travail utile peut indiquer des jobs qui s’accumulent. RSS est en KiB et inclut des pages partagées : ne confondez pas sa somme avec une consommation privée exacte.
Sauvegarder preuves et configuration
Avant toute correction, conservez captures, extraits de logs et configuration du compte dans un dossier privé. Exportez le cron :
account=cpuserumask 077save=$(mktemp -d /root/account-incident.XXXXXX)crontab -u "$account" -l > "$save/crontab.txt"Si aucune crontab n’existe, notez-le ; ne réimportez pas automatiquement un fichier vide. Vérifiez aussi une sauvegarde restaurable des fichiers et bases avant une modification applicative. Une sauvegarde prise pendant un incident n’est pas nécessairement saine.
2. Relier le compte à la cause concrète
- Confirmer le propriétaire :
ps -u "$account" -o pid,ppid,rss,etime,argspid=12345ps -p "$pid" -o user,pid,ppid,lstart,argsreadlink "/proc/$pid/cwd"readlink "/proc/$pid/exe"Remplacez 12345 par un PID observé. Le répertoire courant et l’exécutable donnent des indices, pas une preuve du fichier PHP demandé. Un worker partagé nécessite une corrélation avec le domaine et ses requêtes.
2. Corréler les heures : lisez les journaux du domaine sous /usr/local/apache/domlogs/ et les erreurs applicatives, notamment /home/cpuser/logs/. Comparez URI, fréquence et durées lorsqu’elles sont journalisées. Une adresse de proxy ou un User-Agent déclaré ne permet pas, seul, d’identifier un bot.
3. Examiner cron et PHP : comparez horaires cron, PID parents et temps écoulé. Reproduisez prudemment le problème sur une copie de test. Pour WordPress, désactivez ou corrigez le composant identifié avec sauvegarde et accord opérationnel ; ne supprimez pas tous les plugins pour tester en production.
4. Attribuer SQL : dans une session SQL administrateur, SHOW FULL PROCESSLIST; relie requêtes, utilisateurs et bases. Vérifiez leur correspondance dans la gestion des bases cPanel. Le processus système mysqld ne permet pas cette attribution à lui seul.
5. Choisir une action locale : décalez ou rendez exclusif un cron concurrent, corrigez une boucle, optimisez la requête ou filtrez la route abusive. Pour un trafic légitime, envisagez cache et capacité. Si CloudLinux/LVE est installé, ses limites par compte peuvent servir de protection après mesure ; cPanel seul ne fournit pas automatiquement le même isolement CPU/RAM/I/O.
6. Processus à arrêter : confirmez à nouveau PID, propriétaire et rôle juste avant l’action. Pour un job identifié, tentez un arrêt gracieux :
kill -TERM "$pid"Ne l’appliquez pas à un service partagé ou une transaction inconnue. Un processus relancé par cron ou un superviseur exige de corriger son déclencheur.
Rollback et suspicion de compromission
Rétablissez le réglage ou la version applicative sauvegardée si le changement aggrave le problème. Réactivez un cron seulement après vérification de ses effets. En cas de compromission présumée, préservez les preuves, isolez le compte selon la procédure d’incident et remplacez les secrets affectés ; ne restaurez pas des fichiers suspects pour réduire la charge.
3. Vérification finale
Refaites les mesures pendant une période comparable et le prochain passage cron. Confirmez baisse de consommation, fonctionnement métier et absence de dégradation chez les comptes voisins. Vérifiez que la charge ne s’est pas simplement déplacée vers SQL ou le disque.
Erreurs courantes
Kill all processes by user peut interrompre plusieurs applications du client. Tuer mysqld pénalise tous les comptes. Limiter brutalement un compte sans surveiller les erreurs peut transformer une lenteur en indisponibilité.
Recommandations en production
Conservez une chronologie avec compte, PID, domaine, action, ancienne valeur et résultat. Définissez des seuils à partir de l’activité habituelle de chaque client et prévoyez une révision des limites après tout changement important.
Sources : cPanel, Process Manager, manuel pidstat.
Retrouvez-le dans nos publications
Les étapes clés de cet article, en carrousel. Suivez-nous pour découvrir les prochaines. Nos publications sont rédigées en anglais.