La méthode de diagnostic proposée par cPanel commence par séparer les ressources en cause. Voici une fiche de triage pour un administrateur disposant de WHM et de SSH root : l’objectif est de choisir la bonne enquête avant de redémarrer un service.
1. Capturer la surcharge pendant qu’elle existe
Notez l’heure, les sites touchés et les opérations en cours. Relevez plusieurs observations espacées plutôt qu’une seule capture après l’incident.
date -Isuptimenprocfree -mtopLe Load Average représente une activité en cours ou en attente ; ce n’est pas un pourcentage CPU. Comparez sa tendance au nombre de processeurs disponibles, sans utiliser un seuil universel. Dans top, regardez ensemble CPU, mémoire, swap et attente disque. Une valeur de swap occupée, isolément, ne prouve pas une saturation actuelle.
Si htop est installé, utilisez sa vue des processus pour suivre une famille PHP. Ne perdez pas la fenêtre d’observation à installer tous les outils : top et ps permettent déjà une première orientation.
2. Relier la ressource au service
Exécutez les outils disponibles pendant le ralentissement :
ps -eo user,pid,ppid,pcpu,pmem,comm \ --sort=-pcpu | head -20iostat -xz 1 5iotop -oUne domination PHP invite à relever le propriétaire du processus, le pool et l’URL sollicitée. Pour Apache, consultez l’état du serveur dans WHM et rapprochez les workers occupés des journaux HTTP. Avec LiteSpeed, partez de ses statistiques et journaux propres : un processus web occupé ne désigne pas automatiquement un script coupable.
Si MySQL ou MariaDB ressort, ouvrez les processus de base de données dans WHM et recherchez les requêtes actives ou en attente. Pour le disque, confrontez les processus vus par iotop aux mesures de iostat ; une sauvegarde peut ralentir les sites sans pic CPU PHP. Une pointe à heure fixe justifie aussi l’examen des cron et des sauvegardes.
3. Tester une seule hypothèse
Rédigez une phrase vérifiable : « Le ralentissement commence pendant l’export du compte X et cesse à sa fin. » Puis décalez cet export lors d’un essai contrôlé. Pour une URL coûteuse, testez une correction applicative ou un cache adapté ; pour une attente SQL, poursuivez l’analyse des requêtes.
Évitez de tuer tous les processus ou de relever tous les plafonds : vous effaceriez des indices et déplaceriez la saturation. Gardez les mêmes mesures avant et après, avec le volume de requêtes et le temps de réponse. Le succès se juge sur le service rendu et la disparition de la pression identifiée, pas seulement sur un chiffre de charge devenu plus petit.
Sources : cPanel — high server loads, cPanel — disk I/O.