Serveur cPanel lent : diagnostiquer CPU, disque, PHP et MySQL avant de modifier

Un serveur peut disposer de CPU et de RAM libres tout en répondant lentement. Le bilan réseau publié par Cloudflare rappelle que la performance doit être mesurée ; côté origine, il faut surtout identifier où une requête attend avant d’augmenter les limites.

Intention de recherche : expliquer une lenteur cPanel/WHM et sélectionner une correction fondée sur des mesures. Ce guide concerne un administrateur root ; les commandes d’observation ne modifient pas les services.

1. Capturer la lenteur avant toute correction

Problème et causes possibles

Une moyenne CPU basse peut masquer un cœur saturé, une attente disque, un verrou SQL ou un pool PHP occupé. Une RAM « utilisée » élevée peut simplement correspondre au cache Linux. Notez l’heure, le domaine, l’URL, le statut HTTP et la durée constatée ; comparez une page statique et une page dynamique depuis le même client.

Exécutez pendant l’incident, en arrêtant les vues interactives avec q :

htop est facultatif ; sar et iostat nécessitent sysstat. Si l’outil manque, préparez son installation via la gestion de paquets de votre OS, sans lancer de mise à jour globale pendant l’incident. Ignorez les premières lignes cumulées de vmstat/iostat pour juger l’intervalle courant.

Dans top, affichez les cœurs séparément. Une file runnable persistante dans vmstat r oriente vers le CPU ; b, l’attente I/O et la latence await orientent vers le stockage. Des échanges si/so répétés associés à une mémoire disponible faible indiquent une pression mémoire. Aucun pourcentage unique ne prouve à lui seul la cause.

Sauvegarder l’état de départ

Conservez les mesures dans un répertoire root privé et relevez les valeurs WHM actuelles. Avant une modification, vérifiez une sauvegarde restaurable du compte et exportez la configuration concernée. Par exemple, avant de toucher MySQL :

Incluez aussi les fichiers chargés par les directives d’inclusion de ce fichier. Cette copie ne constitue pas une sauvegarde des bases.

2. Relier chaque signal à un service

1. Disque ou swap : rapprochez les pics des sauvegardes, imports et tâches cron. Comparez les intervalles iostat ; %util seul ne décrit pas correctement toutes les baies et tous les NVMe. Un disque plein ou des inodes épuisés se traitent avant tout réglage de concurrence.
2. MySQL/MariaDB : avec une authentification administrateur déjà configurée, ouvrez mysql, puis exécutez :

Cherchez des requêtes répétées et des verrous, puis associez utilisateur SQL, base et compte cPanel. Une connexion inactive n’est pas une preuve de saturation. Protégez ces résultats : ils peuvent contenir des données applicatives. 3. Apache ou LiteSpeed : consultez WHM, Server Status, Apache Status si Apache est actif. Corrélez les requêtes aux journaux du domaine sous /usr/local/apache/domlogs/ et aux erreurs sous /usr/local/apache/logs/error_log. Sous LiteSpeed, utilisez son état temps réel et les chemins de logs réellement configurés ; ne transposez pas les limites Apache/FPM à lsphp. 4. PHP et utilisateurs : dans WHM, System Health, Process Manager, relevez PID et propriétaire. Sous Apache PHP-FPM, consultez le journal de la version utilisée, par exemple /opt/cpanel/ea-php83/root/usr/var/log/php-fpm/error.log. Remplacez ea-php83 par la version installée. Une limite de workers atteinte peut résulter d’attentes SQL plutôt que d’un manque de workers.

Correction et rollback

Décalez une sauvegarde concurrente, corrigez une requête lente ou limitez le seul pool concerné, selon les preuves. Changez un paramètre à la fois par l’interface WHM correspondante. Si la latence ou les erreurs augmentent, rétablissez la valeur relevée, validez la configuration et rechargez uniquement le service affecté selon sa procédure.

3. Vérification finale

Rejouez les mêmes URL et mesures pendant une charge comparable. Vérifiez latence, erreurs HTTP, mémoire disponible, swap, disque et comptes voisins. Gardez une observation couvrant aussi la prochaine tâche planifiée responsable.

Erreurs courantes

Redémarrer avant la capture efface des indices. Augmenter simultanément les workers PHP et les connexions SQL peut déplacer le problème vers la RAM. Ne tuez pas tous les processus d’un compte pour « tester ».

Recommandations en production

Conservez un relevé avant/après et une hypothèse vérifiable par changement. Si le problème concerne un compte, poursuivez l’attribution locale plutôt qu’une optimisation globale. Si seule la mesure externe est lente, examinez DNS, réseau et proxy avant d’accuser le serveur.

Sources : Cloudflare, bilan de performance réseau, cPanel, analyse des charges élevées.