Un serveur surchargé se diagnostique en trois lectures : uptime pour la charge, top ou htop pour le processus qui consomme, free -h et vmstat 1 pour la mémoire et le swap. Les causes courantes sont PHP-FPM mal dimensionné, une requête SQL lente, des robots qui aspirent le site ou un processus inconnu à examiner.
Un serveur lent n’est pas forcément un serveur trop petit. La cause est souvent un seul processus qui s’emballe : un pool PHP-FPM qui sature la mémoire, une requête MySQL sans index, un robot d’indexation qui parcourt chaque URL, une tâche planifiée qui se lance en double. Plus rarement, la machine travaille pour quelqu’un d’autre (minage, envoi de spam, attaque).
La méthode est toujours la même : mesurer, identifier le processus, comprendre pourquoi il consomme, puis corriger la cause plutôt que de redémarrer en boucle. Connectez-vous en SSH avec un compte autorisé à utiliser sudo ; si la machine ne répond plus du tout, commencez par le guide sur un serveur qui ne répond plus.
Lire la charge avec uptime
uptime affiche trois moyennes de charge, sur 1, 5 et 15 minutes. Comparez-les au nombre de cœurs donné par nproc : une charge durablement supérieure à ce nombre signifie que des processus attendent leur tour. Une charge de 1 minute plus haute que celle de 15 minutes indique une montée récente ; l’inverse, une charge qui retombe. Notez ces valeurs avant de modifier quoi que ce soit.
Repérer le processus avec top ou htop
Lancez top puis appuyez sur P pour trier par processeur ou M pour trier par mémoire (htop, s’il est installé, est plus lisible). Relevez le nom, l’utilisateur et le PID des premières lignes. Dans l’en-tête, la valeur wa indique le temps passé à attendre le disque : élevée, elle oriente vers un disque saturé ou lent plutôt que vers le processeur. Hors top, ps aux --sort=-%cpu | head et ps aux --sort=-%mem | head donnent la même information en une capture copiable. Si le processus ne vous dit rien, tourne sous un utilisateur inattendu ou occupe tout le processeur sans raison, ne le relancez pas : suivez le guide sur un cryptomineur sur un serveur.
Examiner la mémoire et le swap
free -h montre la mémoire totale, utilisée et surtout available, qui est la valeur à surveiller (la mémoire « cache » est récupérable). swapon --show indique si un swap existe. Avec vmstat 1 5, regardez les colonnes si et so : des valeurs non nulles en continu signifient que le système échange entre mémoire et disque, ce qui ralentit tout. Si le noyau a déjà tué des processus, journalctl -k | grep -i "out of memory" en garde la trace.
Régler PHP-FPM et pm.max_children
Sur un site PHP, le fichier de pool se trouve dans /etc/php/X.Y/fpm/pool.d/www.conf (X.Y est votre version de PHP). Si le journal de PHP-FPM contient « server reached pm.max_children setting », les visiteurs font la queue : le site ralentit, sans que le serveur soit saturé. À l’inverse, un pm.max_children trop haut épuise la mémoire. Estimez la taille d’un processus avec ps -eo rss,cmd | grep php-fpm, puis divisez la mémoire que vous pouvez lui consacrer par cette taille. Rechargez avec systemctl reload php8.3-fpm en adaptant le nom du service à votre version. Les paramètres sont décrits dans la documentation PHP citée plus bas.
Chercher les requêtes MySQL lentes
Une base qui travaille trop fait monter la charge et le temps d’attente. Dans mysql, SHOW FULL PROCESSLIST; liste les requêtes en cours et leur durée. Pour garder une trace, activez le journal des requêtes lentes (slow_query_log et long_query_time dans la configuration de MySQL ou MariaDB), puis cherchez les requêtes qui reviennent : un index manquant ou une table énorme de sessions ou de journaux sont des causes classiques.
Détecter les robots et les accès abusifs
Dans le journal d’accès, awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head classe les adresses IP par nombre de requêtes. La même idée sur l’agent utilisateur (awk -F'"' '{print $6}') montre les robots les plus actifs. Un seul visiteur à des milliers de requêtes, ou un robot d’indexation sur des pages de filtres, explique bien des pics. Limitez les excès avec limit_req dans nginx, ou bloquez une adresse au pare-feu ; robots.txt n’oblige personne et reste un simple conseil.
Distinguer pic légitime et attaque
Comptez les connexions par adresse avec ss -tn state established | awk '{print $4}' | sort | uniq -c | sort -rn | head. Un afflux depuis des milliers d’adresses différentes vers la même page évoque une attaque par déni de service, qui se traite plutôt en amont, chez l’hébergeur ou le CDN. Un pic de visiteurs réels après une campagne se règle avec du cache. Si des connexions SSH ou des essais de mot de passe se multiplient, voyez la page sur les attaques par force brute en SSH.
Corriger durablement la cause
Selon le diagnostic : activer un cache de page ou d’objets, ajouter un index, planifier les tâches lourdes la nuit avec un verrou contre les doublons, limiter les robots, redimensionner PHP-FPM, ajouter de la mémoire ou un swap raisonnable. Relancez uptime, free -h et vmstat 1 5 pour confirmer l’amélioration, et mettez une supervision en place pour être alerté avant la prochaine saturation.
Questions fréquentes
Quelle charge serveur est trop élevée ?
Cela dépend du nombre de cœurs. Sur une machine à quatre cœurs, une charge de 4 signifie que tous les cœurs sont occupés ; au-delà, des processus attendent. Regardez la tendance sur 1, 5 et 15 minutes et la valeur wa de top, qui révèle une attente disque.
Pourquoi la RAM de mon serveur est à 100 % sans que le site soit lent ?
Linux utilise la mémoire libre comme cache de fichiers, ce qui paraît « plein » dans free -h. Seule la colonne available compte : tant qu’elle reste confortable et que si et so de vmstat restent proches de zéro, il n’y a aucun problème.
Comment trouver le processus qui ralentit mon serveur ?
Lancez top, triez par processeur avec P ou par mémoire avec M, puis notez le PID et l’utilisateur. ps aux --sort=-%cpu | head donne la même information dans un format copiable. Pour un processus inconnu, vérifiez son chemin avec ls -l /proc/PID/exe.
Faut-il augmenter pm.max_children quand le site ralentit ?
Pas systématiquement. Augmentez-le seulement si le journal signale que la limite est atteinte et que la mémoire disponible le permet. Un nombre trop élevé fait basculer le serveur en swap, ce qui est pire. Cherchez d’abord pourquoi les requêtes PHP sont longues.
Un robot peut-il vraiment faire tomber mon site ?
Oui, un robot qui explore des milliers de pages dynamiques sans pause sollicite PHP et la base au point de saturer un petit serveur. Repérez-le dans le journal d’accès, limitez son débit avec limit_req ou bloquez son adresse, puis mettez des pages en cache.
Sources
- top(1) — man7.org
- vmstat(8) — man7.org
- Configuration de PHP-FPM — php.net
- ngx_http_limit_req_module — nginx.org