Processes, memory and performance

1. Les processus #

Ce qui tourne et comment le piloter.

Lister #

ps aux --sort=-%cpu | head       # plus gros consommateurs CPU
ps aux --sort=-%mem | head
ps -ef --forest                 # arbre parent/enfant
pgrep -a nginx ; pidof sshd
top   # P : tri CPU, M : tri mémoire, 1 : par cœur, k : tuer
htop  # version interactive et colorée

États #

Signaux #

kill -15 1234     # SIGTERM : demande d'arrêt propre (défaut)
kill -9 1234      # SIGKILL : arrêt immédiat, sans nettoyage
kill -HUP 1234    # SIGHUP : souvent « relire la configuration »
pkill -u bob      # tous les processus de bob
killall -s TERM python3

Bonne Pratique : Envoyez toujours SIGTERM d'abord et laissez quelques secondes : SIGKILL empêche l'application de fermer ses fichiers et connexions proprement.

Priorités et arrière-plan #

nice -n 10 tar -czf backup.tgz /srv   # lancer avec une priorité basse
renice +5 -p 1234
ionice -c3 rsync -a /src /dst          # E/S seulement quand le disque est libre
commande &   ; jobs ; fg %1 ; bg %1     # tâches du shell
nohup ./long.sh > long.log 2>&1 &      # survivre à la déconnexion
tmux new -s maintenance                # session détachable (Ctrl+B D, puis tmux attach)

2. CPU, mémoire et disques #

Lire les bons indicateurs.

Charge #

uptime    # load average 1, 5 et 15 min
nproc     # nombre de cœurs

La charge compte les processus en exécution ou en attente (y compris en état D). Elle s'interprète par rapport au nombre de cœurs : 4 sur 4 cœurs = plein ; 12 sur 4 cœurs = saturation. Une charge élevée avec un CPU peu utilisé indique souvent des attentes disque.

Mémoire #

free -h

Regardez la colonne available, pas free : Linux utilise la mémoire libre comme cache disque (buff/cache), récupérable immédiatement. Un serveur avec peu de « free » mais beaucoup d'« available » va bien.

Quand la mémoire manque vraiment, le noyau active l'OOM killer qui tue le processus le plus gourmand :

journalctl -k | grep -i 'out of memory'
dmesg -T | grep -i oom
cat /proc/1234/status | grep VmRSS

vmstat et iostat #

vmstat 1                 # r, b, si/so, wa
iostat -xz 1             # %util et await par disque (paquet sysstat)
mpstat -P ALL 1          # CPU par cœur
pidstat 1                # consommation par processus
sar -u -f /var/log/sysstat/sa26   # historique (sysstat)

3. Diagnostiquer un processus #

Voir ce qu'il fait vraiment.

lsof, strace et /proc #

sudo lsof -p 1234             # fichiers et sockets ouverts
sudo lsof -i :8080            # qui utilise ce port ?
sudo lsof /var/log/app.log
sudo strace -p 1234 -f -e trace=network,file   # appels système en direct
sudo strace -c -p 1234        # statistiques des appels (Ctrl+C)
cat /proc/1234/cmdline | tr '\0' ' '
ls -l /proc/1234/cwd /proc/1234/exe
cat /proc/1234/limits         # limites (fichiers ouverts...)
ulimit -n

Limiter les ressources #

systemd place chaque service dans un cgroup : on peut le limiter sans toucher à l'application.

sudo systemctl set-property app.service MemoryMax=1G CPUQuota=150%
systemd-cgtop                  # consommation par service

4. Une méthode #

Ne pas chercher au hasard.

USE #

1. uptime : la charge monte-t-elle ?
2. dmesg -T | tail : erreurs noyau, OOM, disque ?
3. vmstat 1 : file d'exécution, swap, attente E/S
4. mpstat -P ALL 1 : un cœur saturé ?
5. iostat -xz 1 : disque saturé ?
6. free -h : mémoire disponible
7. ss -s, ip -s link : connexions, erreurs réseau
8. top / pidstat : quel processus ?

À savoir : Cette liste des « 60 premières secondes » vient de l'équipe performance de Netflix : elle suffit à orienter la plupart des diagnostics.