Serveur dédié : analyser les performances CPU, RAM, disque et réseau sous Linux

Quand on migre vers un nouveau serveur dédié, le premier réflexe consiste souvent à lancer top, regarder le load average, puis conclure que “ça va mieux”. C’est un bon début. Mais ce n’est qu’un début.

Un serveur peut sembler calme côté CPU tout en étant étranglé par le disque, la RAM, le swap, la base de données, nginx, PHP-FPM, le réseau, ou un service systemd qui redémarre en boucle. Bref, le serveur ne ment pas. Mais il faut lui poser les bonnes questions.

Voici une méthode moderne pour analyser les performances d’un serveur dédié Linux, identifier le vrai goulet d’étranglement, puis savoir quoi optimiser en priorité.

Commencer par une vue globale

Avant d’accuser MySQL, nginx ou PHP, commencez par une vue système rapide :

uptime
hostnamectl
nproc
free -h
df -h
df -i

Ces commandes répondent déjà à plusieurs questions essentielles :

• depuis combien de temps le serveur tourne ;
• quelle est la charge moyenne ;
• combien de cœurs CPU sont disponibles ;
• combien de RAM reste libre ;
• si le swap est utilisé ;
• si une partition est pleine ;
• si les inodes sont saturés.

Un serveur peut avoir beaucoup d’espace disque libre mais plus aucun inode disponible. Dans ce cas, il ne peut plus créer de nouveaux fichiers. Les caches WordPress, sessions PHP, fichiers temporaires et logs adorent ce genre de petite catastrophe discrète.

Comprendre le load average

La commande uptime affiche trois valeurs de charge moyenne :

uptime

Exemple :

16:42:10 up 32 days,  4:11,  1 user,  load average: 0.18, 0.22, 0.19Code language: CSS (css)

Ces trois valeurs représentent la charge moyenne sur 1, 5 et 15 minutes. Elles doivent être interprétées par rapport au nombre de cœurs CPU.

Pour connaître ce nombre :

nproc

Sur un serveur avec 4 cœurs, une charge de 1.00 reste souvent confortable. Une charge de 4.00 indique que le serveur utilise pleinement sa capacité. Au-dessus, des tâches commencent probablement à attendre.

Mais attention : le load average ne mesure pas uniquement le CPU. Il inclut aussi les processus en attente d’I/O disque. Un serveur peut donc afficher une charge élevée parce que le stockage est lent, même si le CPU se tourne les pouces avec dignité.

Analyser le CPU avec top et htop

La commande classique reste :

top

Pour une interface plus lisible :

htop

Installez htop si nécessaire :

sudo apt update
sudo apt install htop

Dans top ou htop, surveillez surtout :

• %us : CPU consommé par les processus utilisateur ;
• %sy : CPU consommé par le noyau ;
• %wa : attente I/O disque ;
• %id : CPU réellement inactif ;
• les processus qui consomment le plus ;
• les tâches zombies ;
• les redémarrages fréquents de services.

Si %wa est élevé, ne cherchez pas d’abord côté PHP. Cherchez côté disque. Le serveur attend probablement ses I/O comme un client attend son café dans une gare.

Voir le CPU par cœur avec mpstat

Pour analyser chaque cœur CPU, installez sysstat :

sudo apt install sysstat

Puis lancez :

mpstat -P ALL 1 5

Cette commande affiche l’utilisation CPU par cœur, toutes les secondes, pendant cinq mesures.

C’est utile pour distinguer un serveur globalement chargé d’un processus monothread qui sature un seul cœur. Certaines tâches PHP, scripts d’import, conversions d’images ou requêtes MySQL lourdes peuvent surtout bloquer un cœur, sans saturer toute la machine.

Analyser la RAM et le swap

Commencez par :

free -h

Sur Linux, une grande partie de la RAM peut être utilisée comme cache disque. Ce n’est pas un problème. Au contraire, Linux utilise la mémoire disponible pour accélérer les lectures.

Ce qui doit vous inquiéter :

• un swap utilisé massivement ;
• une mémoire disponible très basse ;
• des processus PHP-FPM trop nombreux ;
• MySQL ou MariaDB qui consomme plus que prévu ;
• des OOM kills dans les logs.

Pour vérifier si le noyau a tué des processus par manque de mémoire :

journalctl -k --since "24 hours ago" | grep -Ei "out of memory|oom|killed process"Code language: JavaScript (javascript)

Si vous voyez des processus PHP, MySQL ou Redis tués par OOM, votre problème n’est pas subtil : le serveur manque de mémoire, ou vos limites de services sont mal dimensionnées.

Diagnostiquer avec vmstat

vmstat donne une vue très utile sur CPU, RAM, swap et I/O :

vmstat 1 10

Regardez surtout :

• r : processus en attente de CPU ;
• b : processus bloqués en attente d’I/O ;
• si et so : swap in et swap out ;
• wa : attente I/O ;
• us et sy : CPU utilisateur et système.

Si si et so bougent souvent, le serveur swap réellement. Ce n’est pas juste du swap “historique”. Là, les performances peuvent s’effondrer rapidement.

Analyser les disques et les I/O

Le disque est souvent le vrai coupable des lenteurs serveur. Pour vérifier l’espace :

df -h
df -i

Pour analyser les I/O disque :

iostat -xz 1 10

Surveillez particulièrement :

• %util : saturation du périphérique ;
• await : temps moyen d’attente I/O ;
• r/s et w/s : lectures et écritures par seconde ;
• rkB/s et wkB/s : volume lu et écrit ;
• aqu-sz : taille moyenne de la file d’attente.

Si %util reste proche de 100 % et que await grimpe, le disque est un goulet d’étranglement. Sur un serveur WordPress, cela peut venir de MySQL, des logs, d’un backup, d’un cache mal configuré, d’un scan antivirus, ou d’un plugin qui écrit beaucoup trop.

Voir quels processus écrivent sur le disque

Installez iotop :

sudo apt install iotop

Puis lancez :

sudo iotop -oPa

Cette commande affiche les processus qui lisent ou écrivent réellement sur le disque. L’option -o masque les processus inactifs, -P regroupe par processus, et -a affiche les compteurs cumulés.

Si vous voyez MySQL écrire énormément, regardez les requêtes lentes. Si vous voyez PHP-FPM écrire beaucoup, cherchez des sessions, logs, exports, caches ou tâches cron trop bavardes.

Analyser les services systemd

Sur un serveur moderne, systemd donne une vue rapide de l’état des services :

systemctl --failed

Pour vérifier un service précis :

systemctl status nginx
systemctl status php8.3-fpm
systemctl status mariadb
systemctl status redis-serverCode language: CSS (css)

Adaptez les noms selon votre stack. Sur certains serveurs, vous aurez mysql au lieu de mariadb, ou une autre version de PHP-FPM.

Pour lire les logs d’un service :

journalctl -u nginx --since "1 hour ago"
journalctl -u php8.3-fpm --since "1 hour ago"
journalctl -u mariadb --since "1 hour ago"Code language: JavaScript (javascript)

journalctl interroge le journal systemd. C’est souvent plus rapide que fouiller manuellement dans plusieurs fichiers de logs.

Analyser nginx

Sur un serveur web, commencez par vérifier la configuration nginx :

sudo nginx -t

Puis regardez les connexions actives :

ss -Htan state established '( sport = :80 or sport = :443 )' | wc -lCode language: JavaScript (javascript)

Pour voir les IP les plus présentes dans les logs nginx :

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20Code language: JavaScript (javascript)

Pour repérer les URLs les plus demandées :

awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -30Code language: JavaScript (javascript)

Pour isoler les erreurs 5xx :

awk '$9 ~ /^5/ {print $0}' /var/log/nginx/access.log | tail -50Code language: JavaScript (javascript)

Si vous utilisez nginx avec WordPress, l’article sur The SEO Framework et les erreurs 404 de sitemap sous nginx complète bien cette approche : une règle nginx trop large peut casser des endpoints virtuels tout en semblant parfaitement logique.

Activer une page de statut nginx

nginx peut exposer une page de statut basique via le module stub_status. Ajoutez une location protégée, accessible uniquement localement :

location = /nginx_status {
	stub_status;
	allow 127.0.0.1;
	allow ::1;
	deny all;
}

Testez puis rechargez nginx :

sudo nginx -t
sudo systemctl reload nginx

Ensuite :

curl http://127.0.0.1/nginx_statusCode language: JavaScript (javascript)

Vous obtenez une vue rapide des connexions actives, acceptées, traitées et en attente. Ne laissez jamais cette URL ouverte publiquement. Elle donne des informations utiles sur le trafic du serveur.

Analyser PHP-FPM

Sur un site WordPress, PHP-FPM est souvent au cœur des performances. Vérifiez d’abord son état :

systemctl status php8.3-fpm
journalctl -u php8.3-fpm --since "1 hour ago"Code language: CSS (css)

Regardez ensuite les processus PHP actifs :

ps -ylC php-fpm8.3 --sort:rssCode language: CSS (css)

Selon votre distribution, le nom du processus peut être php-fpm, php8.3-fpm ou similaire. Vous pouvez chercher avec :

pgrep -a php-fpm

Si PHP-FPM consomme trop de RAM, vérifiez les paramètres du pool :

grep -R "^[[:space:]]*pm\." /etc/php/*/fpm/pool.d/*.confCode language: JavaScript (javascript)

Les paramètres à surveiller :

• pm.max_children ;
• pm.start_servers ;
• pm.min_spare_servers ;
• pm.max_spare_servers ;
• pm.max_requests.

Un pm.max_children trop haut peut saturer la RAM. Trop bas, il peut créer une file d’attente et ralentir les requêtes. Comme souvent, la bonne valeur dépend de la mémoire moyenne consommée par vos processus PHP.

Analyser MySQL ou MariaDB

Sur WordPress et WooCommerce, la base de données peut devenir le vrai point chaud. Commencez par vérifier le service :

systemctl status mariadb
journalctl -u mariadb --since "1 hour ago"Code language: JavaScript (javascript)

Ou, selon votre serveur :

systemctl status mysql
journalctl -u mysql --since "1 hour ago"Code language: JavaScript (javascript)

Pour voir les requêtes en cours :

mysqladmin processlist

Avec WP-CLI, vous pouvez aussi ouvrir un client SQL :

wp db cli

Pour vérifier rapidement les plus grosses tables WordPress :

wp db query "
SELECT
	table_name AS table_name,
	ROUND(((data_length + index_length) / 1024 / 1024), 2) AS size_mb
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
ORDER BY size_mb DESC
LIMIT 20;
"Code language: PHP (php)

Sur WooCommerce, surveillez notamment les tables liées aux commandes, sessions, actions planifiées, logs et métadonnées. Une table wp_options gonflée, une file Action Scheduler énorme, ou des transients mal nettoyés peuvent ralentir tout le site.

Pour les boutiques WooCommerce, le guide sur la mise à jour de la base WooCommerce avec WP-CLI complète naturellement cette analyse, surtout côté Action Scheduler et maintenance de base.

Surveiller les tâches cron

Un serveur peut ralentir à heures fixes à cause d’un backup, d’une synchronisation, d’un import, d’un scan ou d’un cron WordPress.

Listez les crons système :

ls -lah /etc/cron.*
crontab -l
sudo crontab -l

Pour les timers systemd :

systemctl list-timers --allCode language: PHP (php)

Pour WordPress :

wp cron event list --fields=hook,next_run_relative,recurrence --format=tableCode language: PHP (php)

Si plusieurs tâches lourdes tombent au même moment, espacez-les. Un backup, une génération de sitemap, une purge de cache et un import produit lancés ensemble peuvent transformer un serveur très correct en grille-pain solennel.

Analyser le réseau

Pour voir les sockets actives :

ss -tulpn

Pour compter les connexions par état :

ss -tan | awk 'NR>1 {print $1}' | sort | uniq -c | sort -nrCode language: JavaScript (javascript)

Pour voir les connexions établies vers nginx :

ss -Htan state established '( sport = :80 or sport = :443 )' | wc -lCode language: JavaScript (javascript)

Pour une vue de bande passante en temps réel, installez nload ou iftop :

sudo apt install nload iftop
sudo nload
sudo iftop

Si une seule IP consomme beaucoup, regardez les logs nginx. Si beaucoup d’IPs frappent les mêmes URLs, vous avez peut-être un bot, un scan, une attaque faible intensité, ou une ressource trop exposée.

Chercher les erreurs dans les logs

Les métriques indiquent où regarder. Les logs expliquent souvent pourquoi.

Pour les erreurs système récentes :

journalctl -p warning..alert --since "24 hours ago"Code language: JavaScript (javascript)

Pour nginx :

tail -n 100 /var/log/nginx/error.logCode language: JavaScript (javascript)

Pour PHP-FPM, selon votre configuration :

find /var/log -type f -iname '*php*fpm*log' -printCode language: PHP (php)

Pour WordPress, si le debug log est activé :

tail -n 100 wp-content/debug.log

Attention : un debug log WordPress qui grossit très vite peut lui-même devenir un problème de performance. Une erreur PHP répétée à chaque requête peut remplir le disque, ralentir les I/O, et masquer le vrai souci sous une avalanche de bruit.

Installer une boîte à outils minimale

Sur Ubuntu ou Debian, installez les outils utiles :

sudo apt update
sudo apt install htop iotop sysstat nload iftop ncdu lsof strace

Rôle rapide de chaque outil :

• htop : vue interactive CPU/RAM/processus ;
• iotop : processus qui lisent ou écrivent sur disque ;
• sysstat : sar, iostat, mpstat, pidstat ;
• nload : trafic réseau par interface ;
• iftop : bande passante par connexion ;
• ncdu : analyse rapide de l’espace disque ;
• lsof : fichiers ouverts ;
• strace : appels système d’un processus.

Activez aussi la collecte sysstat si elle ne l’est pas :

sudo sed -i 's/^ENABLED="false"/ENABLED="true"/' /etc/default/sysstat
sudo systemctl enable --now sysstat
sudo systemctl restart sysstatCode language: JavaScript (javascript)

Ensuite, vous pourrez consulter l’historique avec sar, ce qui change tout quand un client dit “le site était lent hier vers 14h”. Sans historique, on devine. Avec historique, on enquête.

Analyser l’historique avec sar

Afficher l’utilisation CPU du jour :

sar

Afficher la mémoire :

sar -r

Afficher le swap :

sar -S

Afficher les I/O disque :

sar -d

Afficher le réseau :

sar -n DEV

Pour lire les données d’hier :

sar -f /var/log/sysstat/sa$(date -d yesterday +%d)Code language: JavaScript (javascript)

Sur certains systèmes, le chemin peut être /var/log/sa/ au lieu de /var/log/sysstat/.

Méthode rapide : CPU, RAM, disque ou réseau ?

Quand un serveur ralentit, ne partez pas dans tous les sens. Classez le problème dans une famille.

CPU saturé

Symptômes fréquents :

• %us élevé dans top ;
• load average proche ou supérieur au nombre de cœurs ;
• processus PHP, MySQL ou compression d’images en tête ;
• site lent mais disque peu sollicité.

Commandes utiles :

top
htop
mpstat -P ALL 1 5
pidstat 1 10

RAM insuffisante

Symptômes fréquents :

• swap actif ;
• processus tués par OOM ;
• PHP-FPM ou MySQL très gourmands ;
• ralentissements progressifs puis brutaux.

Commandes utiles :

free -h
vmstat 1 10
journalctl -k --since "24 hours ago" | grep -Ei "oom|out of memory|killed process"Code language: JavaScript (javascript)

Disque ou I/O saturés

Symptômes fréquents :

• %wa élevé ;
• await élevé dans iostat ;
• backups ou logs actifs ;
• MySQL lent ;
• site lent malgré CPU disponible.

Commandes utiles :

iostat -xz 1 10
sudo iotop -oPa
df -h
df -i
ncdu /var/logCode language: JavaScript (javascript)

Réseau ou trafic anormal

Symptômes fréquents :

• beaucoup de connexions nginx ;
• trafic sortant inhabituel ;
• IPs répétées dans les logs ;
• pics sur endpoints WordPress ou WooCommerce ;
• bots sur xmlrpc.php, recherche interne ou endpoints AJAX.

Commandes utiles :

ss -tan | awk 'NR>1 {print $1}' | sort | uniq -c | sort -nr
sudo iftop
sudo nload
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20Code language: JavaScript (javascript)

Cas WordPress : ce qui ralentit souvent le serveur

Sur un serveur dédié qui héberge WordPress, les ralentissements viennent souvent de quelques familles très prévisibles :

• plugins lourds ou mal codés ;
• requêtes SQL non indexées ;
• autoloader wp_options trop gros ;
• cron WordPress déclenché par le trafic ;
• Action Scheduler saturé ;
• cache objet absent ou mal configuré ;
• cache page contourné par des cookies ;
• logs PHP trop bavards ;
• bots sur la recherche interne, REST API ou WooCommerce ;
• images générées ou converties à la volée.

Pour un audit éditorial ou technique côté WordPress, l’article sur les articles WordPress de moins de 300 mots montre aussi une logique utile : extraire les données avec WP-CLI, puis prioriser proprement au lieu de deviner.

Vérifier Redis ou le cache objet

Si Redis est installé, vérifiez son état :

systemctl status redis-server
redis-cli ping
redis-cli info memory | head -30

Dans WordPress, vérifiez aussi si le cache objet est bien actif :

wp cache type
wp cache flush

Redis peut beaucoup aider un site WordPress dynamique, mais il ne compensera pas un mauvais modèle de données, des requêtes absurdes ou un plugin qui invalide tout le cache à chaque page vue. Il a des superpouvoirs, pas une baguette magique.

Pour remettre ce point dans une stack WordPress complète, vous pouvez lire le guide sur l’installation de Redis pour accélérer WordPress sous Debian.

Créer un mini rapport de performance

Voici une commande simple pour créer un rapport texte rapide :

{
	echo "=== Date ==="
	date

	echo
	echo "=== Uptime ==="
	uptime

	echo
	echo "=== CPU cores ==="
	nproc

	echo
	echo "=== Memory ==="
	free -h

	echo
	echo "=== Disk usage ==="
	df -h

	echo
	echo "=== Inodes ==="
	df -i

	echo
	echo "=== Top processes by CPU ==="
	ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head -20

	echo
	echo "=== Top processes by RAM ==="
	ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%mem | head -20

	echo
	echo "=== Failed systemd services ==="
	systemctl --failed --no-pager
} > server-performance-report.txtCode language: PHP (php)

Vous pouvez ensuite consulter le rapport :

less server-performance-report.txtCode language: CSS (css)

Ce n’est pas un audit complet, mais c’est une base claire à envoyer à un client, un hébergeur, ou à garder avant/après optimisation.

Script Bash : audit serveur en 60 secondes

Voici un script plus pratique pour capturer l’état d’un serveur au moment d’un ralentissement.

#!/usr/bin/env bash
#
# Quick Linux server performance audit.
#
# Usage:
# bash server-audit.sh

set -euo pipefail

REPORT="server-audit-$(hostname)-$(date +%F-%H%M%S).txt"

{
	echo "=== Server audit ==="
	date
	hostnamectl || true

	echo
	echo "=== Uptime and load ==="
	uptime
	echo "CPU cores: $(nproc)"

	echo
	echo "=== Memory ==="
	free -h

	echo
	echo "=== Disk usage ==="
	df -h

	echo
	echo "=== Inodes ==="
	df -i

	echo
	echo "=== vmstat ==="
	vmstat 1 5

	echo
	echo "=== iostat ==="
	if command -v iostat >/dev/null 2>&1; then
		iostat -xz 1 5
	else
		echo "iostat not installed."
	fi

	echo
	echo "=== Top CPU processes ==="
	ps -eo pid,ppid,user,cmd,%mem,%cpu --sort=-%cpu | head -25

	echo
	echo "=== Top RAM processes ==="
	ps -eo pid,ppid,user,cmd,%mem,%cpu --sort=-%mem | head -25

	echo
	echo "=== Network states ==="
	ss -tan | awk 'NR>1 {print $1}' | sort | uniq -c | sort -nr

	echo
	echo "=== Failed systemd services ==="
	systemctl --failed --no-pager || true

	echo
	echo "=== Recent system warnings ==="
	journalctl -p warning..alert --since "2 hours ago" --no-pager | tail -100 || true
} > "${REPORT}"

echo "Report created: ${REPORT}"Code language: PHP (php)

Rendez-le exécutable :

chmod +x server-audit.shCode language: CSS (css)

Puis lancez-le :

./server-audit.sh

Gardez ce type de rapport avant et après une migration serveur. Cela permet de comparer les chiffres au lieu de se fier à une impression. Les impressions, c’est très bien pour les parfums. Moins pour l’infra.

Comparer avant et après une migration

Après une migration de serveur dédié, comparez au minimum :

• load average moyen ;
• utilisation CPU en période normale ;
• utilisation RAM et swap ;
• latence disque avec iostat ;
• temps de réponse nginx ;
• requêtes lentes MySQL ;
• temps de génération PHP ;
• nombre de connexions simultanées ;
• taille et croissance des logs ;
• résultats de tests applicatifs WordPress.

Si vous migrez aussi la base ou la pile logicielle, gardez un œil sur les versions. Par exemple, un changement de version MySQL peut modifier les plans d’exécution, la mémoire utilisée ou le comportement de certaines requêtes. L’article sur la migration vers MySQL 8.4 LTS sur Ubuntu Server complète bien cette partie.

Checklist d’analyse rapide

• Vérifier uptime et comparer le load au nombre de cœurs.
• Regarder CPU, RAM et processus avec top ou htop.
• Vérifier la mémoire et le swap avec free -h.
• Utiliser vmstat 1 10 pour voir CPU, swap et I/O.
• Utiliser iostat -xz 1 10 pour diagnostiquer le disque.
• Utiliser iotop pour trouver les processus qui écrivent.
• Vérifier l’espace disque avec df -h.
• Vérifier les inodes avec df -i.
• Contrôler les services avec systemctl --failed.
• Lire les logs récents avec journalctl.
• Analyser nginx, PHP-FPM et MySQL séparément.
• Vérifier les crons et timers systemd.
• Comparer les métriques avant/après optimisation.

Commandes utiles à garder

Vue générale :

uptime
nproc
free -h
df -h
df -i

CPU et processus :

top
htop
mpstat -P ALL 1 5
pidstat 1 10

RAM, swap et I/O :

vmstat 1 10
iostat -xz 1 10
sudo iotop -oPa

Services et logs :

systemctl --failed
journalctl -p warning..alert --since "24 hours ago"Code language: JavaScript (javascript)

Réseau :

ss -tulpn
ss -tan | awk 'NR>1 {print $1}' | sort | uniq -c | sort -nr
sudo iftopCode language: JavaScript (javascript)

nginx :

sudo nginx -t
tail -n 100 /var/log/nginx/error.log
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20Code language: JavaScript (javascript)

WordPress :

wp cron event list
wp db check
wp cache flushCode language: PHP (php)

Conclusion

Analyser les performances d’un serveur dédié ne consiste pas seulement à regarder si le CPU est calme. Le vrai diagnostic consiste à déterminer quelle ressource limite le système : CPU, RAM, swap, disque, I/O, réseau, nginx, PHP-FPM, MySQL ou tâches planifiées.

Le bon réflexe est simple : commencer large avec uptime, free, df, top et vmstat, puis descendre vers les outils spécialisés comme iostat, iotop, journalctl, systemctl et les logs applicatifs.

Une charge serveur basse après migration est une bonne nouvelle. Mais une analyse complète permet de savoir pourquoi le serveur va mieux, où se trouve encore la marge, et quel composant risque de devenir le prochain maillon faible.

En performance serveur, le but n’est pas de collectionner les commandes. Le but est d’arrêter de deviner. Et franchement, c’est reposant.

Sources

• Linux man-pages — proc_loadavg
• Linux man-pages — vmstat
• Ubuntu Manpages — iostat
• Sysstat — Performance monitoring tools for Linux
• Linux man-pages — journalctl
• nginx — ngx_http_stub_status_module

Report a typo