Trouver la source d’un load average élevé

Vous administrez un serveur en Linux ou vous avez tout simplement un PC avec Linux installé.
Votre PC se met à ralentir et vous avez remarqué que le load average est important.
Ainsi, la charge de travail du système est donc importante.

Comment trouver ce qui provoque un load average élevé ?

Dans ce tutoriel, je vous donne plusieurs conseils afin de déterminer ce qui peut provoquer un load average élevé.

Qu’est-ce qui peut provoquer un load average élevé

Pour comprendre cette mesure de charge système, lisez ce tutoriel complet :

Qu’est-ce que et comprendre le load average sur Linux

Voici quelques source d’un load average élevé :

• Soit trop de processus sont en cours de fonctionnement et donc le système est saturé
• Un processus qui effectue un travail trop important par rapport à la capacité matériel du serveur.
• Soit un goulot d’étranglement est présent. Par exemple, un disque dur trop lent par rapport à la demande de charge système ainsi les threads en sommeil “ininterruptible” s’accumulent

Ainsi dans ce dernier cas, il convient de vérifier les performances de vos disques et leurs santés.
De même, si vos stockages sont NFS, des baisses de performances du serveur NFS ou du réseau peuvent générer des processus en état uninterruptible et faire monter le load average.

Trouver la source du load average élevé

Pour suivre ces conseils, il faut connaître un minimum le fonctionnent des processus sur Linux.
Pour cela, suivez ce tutoriel :

Vérifier les activités des processus

Le charge système actuel n’est autre que le nombre de threads (appelées tâches) sous Linux qui sont soit dans l’état

• R (Runnable state) en cours d’exécution
• D (uninterruptible sleep state) attentent en général des E/S

Nous pouvons simplement exécuter PS pour énumérer le nombre actuel de threads dans ces états:

ps -eo s,pid,cmd,user | grep ^[RD] | sort | uniq -c | sort -nbr | head -20

Ici il s’agit de plusieurs processus yes qui utilisent fortement la CPU, ce qui n’est pas difficile à identifier avec des utilitaires tels que top.

La commande vmstat montre également les processus actuels “bloqués” ou en attente d’E/S dans la colonne id.

vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  1 190208 137480  39284 7665140    0    0     0    66    2    2  0  0 100  0  0
 0  1 190208 145236  39352 7657028    0    0     0 92352  433 3714  0  3 81 16  0
 0  1 190208 140276  39428 7662020    0    8     0 82148  352 3287  0  3 79 18  0
 0  1 190208 146196  39500 7655276    0    0     0 92376  556 3988  0  3 82 15  0
 0  1 190208 142836  39576 7658320    0    0     0 92380  424 4255  0  3 88  9  0

La colonne b indique le nombre de processus D, soit donc 1 dans cet exemple.

Au besoin, vous pouvez tenter de l’arrêter avec la commande kill dont voici la syntaxe :

kill -9 <numéro PID>

La première colonne donne le PID du processus dd, soit 23664, ce qui donne :

kill -9 23664

Vérifier l’activité système Linux

Pour établir la source d’une charge anormale du système, il faut vérifier tous les composants (CPU, mémoire, disque, réseau, IRQ, …).
Pour cela, on doit s’appuyer sur des outils de type gestionnaire de tâches.
Vous trouverez une liste complète dans ce lien :

A minima installer via yum/dnf ou apt :

• iftop pour les activités réseaux
• iotop pour les activités disques (I/O)
• nmon : NFS et vue d’ensemble

Première chose, vérifier si un processus sature le CPU ou la mémoire.
Pour cela, vous pouvez commencer par top pour une vue générale des activités du système d’exploitation.
Par exemple ci-dessous, le load est de 100 mais la CPU et la mémoire n’est pas saturée.
Cela ne vient donc pas de là.

Au contraire ci-dessous, on voit que le processus dd utilise pleinement le processeur.

Si un processus a tendance à utiliser trop la CPU, vous pouvez tenter de l’arrêter (s’il n’est pas important).
Pour cela, appuyez sur k puis saisissez le PID (première colonne).

Mais on peut aller plus loin avec atop, htop ou glances qui donnent plus d’informations.

Ensuite, vérifier l’utilisation disque avec iotop.
Dans cet exemple, on voit que l’écriture et la lecture disque total est basse (voir en haut à droite).
Il faut vérifier les colonnes DISK READ/WRITE pour vérifier le taux d’écriture et lecture du processus.
Enfin la colonne I/O est important pour vérifier les entrées et sorties du disque.

Dans cet autre exemple, le I/O est important à 100% à cause du processus dd.
En conséquence kworker est aussi important, car c’est le processus qui gère les fils de travail du noyau Linux est alors important.

Autre exemple avec nmon qui rapporte une saturation du disque.
iotop permet de déterminer les fichiers écrits et le processus qui en est la source.

Enfin iftop permet d’afficher l’utilisation réseau afin de s’assurer que votre interface réseau n’est pas saturée.

Vérifier la santé de vos disques

Un problème matériel sur le disque peut générer des baisses de performances I/O.
Cela entraine alors plus de processus en attente et donc être à l’origine de la montée du load average.
Vérifiez vos disques à l’aide de l’utilitaire smartctl :

De même, cas de corruption d’un RAID mdadm, cela peut générer des baisses de performances qui font monter le load average.
Vous pouvez vérifier l’état du RAID avec la commande mdadm :

Vérifier les températures

Enfin une mauvaise ventilation entraîne une surchauffe des composants et une baisse des performances.
Vérifier le températures afin de s’assurer que ce n’est pas la source des surcharges de travail du système.

Vous pouvez faire cela avec sensors ou glances.