Loadaverage : La charge d'une machine sous Ubuntu...

Une question fréquente que l'on se pose lorsqu'on a un ensemble de serveurs à gérer est l'état de charge des serveurs. La charge sur un serveur est classiquement évaluée de plusieurs manières :

• l'usage du CPU
• mémoire vive disponible
• espace disque disponible
• mémoire swap utilisée
• et bien d'autres encore…

Personnellement, je pense que ces éléments de mesures sont difficiles à mettre en relation avec la charge réelle de la machine. Explications…

Le pourcentage d'usage du CPU est l'exemple type d'une information difficile à traiter. Lorsque vous lancez un top, vous avez dans le haut de votre écran des informations de ce type :

Cpu(s):  0.3% us,  0.3% sy,  0.0% ni, 95.9% id,  3.4% wa,  0.0% hi,  0.2% si

Est-ce que cela signifie pour autant que votre serveur est chargé à 0,3% ???

Le taux d'usage du CPU donne une information extrêmement volatile ; notre petit utilitaire top se rafraîchit toutes les deux secondes… or, le taux d'usage du CPU change quasi toutes les milli-secondes.

Pour moi, c'est une bonne indication pour déterminer si un processus consomme du CPU de manière inattendue mais pas assez pour évaluer la charge d'une machine.

La quantité de mémoire vive disponible peut également donner une information. Voyons un petit top sur un autre serveur :

Mem:   1036100k total,  1022588k used,    13512k free,   376616k buffers

Cette information est-elle significative ? Est-ce que mon serveur est chargé à 99% ?

Le noyau Linux utilise un système de libération des zones mémoires dit paresseuse. C'est-à-dire qu'il va utiliser un maximum de mémoire disponible et qu'il va en libérer uniquement au besoin.

L'espace disque utilisé est une indication de charge lorsque le serveur est essentiellement un serveur de fichier mais ça nous indique uniquement qu'il faut ajouter des disques. Cette information obtenue par df -h ne nous est pas utile dans ce contexte :

Sys. de fich.            Tail. Occ. Disp. %Occ. Monté sur
/dev/cciss/c0d0p1      56G  4,1G   49G   8% /
tmpfs                 506M     0  506M   0% /dev/shm
192.168.254.40:/srv/archive
                      661G  368G  259G  59% /srv/archive
/dev/drbd0            138G   26G  105G  20% /srv/fotpad
/dev/drbd1            138G   60G   72G  46% /srv/files

Reprenons notre outil top pour examiner la mémoire swap utilisée :

Swap:  4104596k total,        0k used,  4104596k free,   425472k cached

Encore une fois, ça ne nous donne aucune information sur la charge du serveur. Cette donnée nous indique néanmoins quelque chose d'important ; la mémoire vive est suffisante car le noyau ne ressent pas la nécessité de swapper.

Pour moi, la mémoire swap utilisée m'indique surtout un manque de mémoire vive ; rien de plus.

Après avoir passé en revue les quelques indicateurs de l'introduction, qui ont leurs avantages et leurs inconvénients ; je vais vous parler des load average, disponible avec l'utilitaire uptime.

Les load average existent depuis longtemps sur les systèmes Unix et Linux a hérité de cette notion. Vous trouverez cette information de plusieurs manières (locales ou distantes) et est généralement représentée comme 3 chiffres à 2 décimales.

load average: 0.26, 0.28, 0.35

load average: 0.26, 0.28, 0.35, 0.46

Les load average représentent le nombre moyen de processus dans la file d'attente des processus ready for running pour, respectivement, la dernière minute, les 5 dernières minutes et les 15 dernières minutes.

Donc, en clair, si vous avez un 1.00 dans le deuxième nombre, cela signifie que durant les 5 dernières minutes, il y avait 1 processus prêt à être exécuté (c'est-à-dire que les I/O sont satisfaits, qu'il a toutes ses ressources…) mais qui est en attente.

: Dans le kernel linux, le load-average contient également les processus en attente d'I/O, ce n'est pas uniquement la charge processeur ( https://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html )

L'usine (qui fait le travail) est le serveur. La matière première est en entrée de cette usine (les processus en attente). Les produits finis sont en sortie de l'usine (les processus terminés).

Si vous avez beaucoup de matière première en attente, c'est que l'usine est sous-dimensionnée. Si vous avez peu ou pas de matière première en attente, c'est que l'usine est bien dimensionnée.

En clair, si votre serveur est bien dimensionné ; vous aurez un load average relativement faible.

Les load average permettent d'évaluer si le processeur est suffisamment puissant, mais également tout ce qui touche au travail devant être réalisé (la mémoire, la vitesse des contrôleurs, la vitesse des entrées/sorties sur disques…)

Pour moi (et pour beaucoup d'administrateurs systèmes), les load average sont une solution efficace et éprouvée pour évaluer la charge d'un serveur.

Maintenant que je vous ai vanté les mérites des load averages, vous allez vous empressez de faire un uptime et d'observer les trois chiffres indicateurs en vous demandant si ces chiffres sont bons ou mauvais.

La bonne valeur de load average n'existe pas. Tout dépend de votre environnement de travail et des tâches assignées au serveur.

Dans mon parc, j'ai un serveur de mail qui ne dépasse jamais les 0.20. J'ai un serveur de production qui oscille entre 0.20 et 1.50 et j'ai un serveur de centralisation de sauvegardes et de mise sur bandes qui oscille entre 6.00 et 8.30 lors de la mise sur bande et qui est à 0.00 en heures creuses.

En fait, tout est relatif !

Que les tâches soient un peu plus lentes sur le serveur de centralisation des sauvegarde m'importe peu. Par contre, je ne veux pas que la production devienne insupportable pour les clients.

En règle générale (d'après la littérature et quelques expériences personnelles), un taux supérieur à 3.00 est un assez mauvais signe. Quand le taux de load average atteint trois sur le serveur de production, on attend plusieurs secondes avant d'obtenir la console en SSH (pour vous donner une petite idée).

Il y a deux manières essentielles pour obtenir les load averages ; soit localement sur la machine ; soit de manière distante à des fins de supervisions.

Pour obtenir les informations de load average localement ; vous pouvez utiliser les programmes suivants :

• indicator-applications : Graphiquement dans la barre de notification :

Pour se faire il suffit d'installer le paquet Indicator-multiload

— ratm54 Le 28/05/2015, 20:57 la partie suivante, relative à systray-whitelist est dépreciée depuis ubuntu 14.04 ensuite pour unity exécuter en ligne de commande :

  gsettings set com.canonical.Unity.Panel systray-whitelist "['all']"

• top : un classique…

top - 13:19:57 up 19 days,  1:15,  1 user,  load average: 0.02, 0.03, 0.00
Tasks:  61 total,   1 running,  60 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.2% us,  0.3% sy,  0.0% ni, 96.8% id,  2.5% wa,  0.0% hi,  0.1% si
Mem:   1036100k total,  1015272k used,    20828k free,   141812k buffers
Swap:  4104596k total,        0k used,  4104596k free,   791624k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
32750 root      15   0     0    0    0 S  2.0  0.0   8:21.60 drbd1_receiver
    1 root      00   0  0000  000  000 S  0.0  0.1   0:02.58 init
    2 root      RT   0     0    0    0 S  0.0  0.0   0:00.04 migration/0
[...]

• uptime : la version "light"…

 13:20:44 up 19 days,  1:16,  1 user,  load average: 0.09, 0.05, 0.01

• cat /proc/loadavg : la version parfaite pour les scripts…

0.05 0.04 0.00 1/67 32139

Sinon il est possible d'ajouter dans la barre supérieur (droite) de unity le programme indicator-multiload :

  sudo apt-get install indicator-multiload

puis relancer la session (ou dans une console lancer la commande indicator-multiload &) Ce programme permet de visualiser directement différents paramètres issus de l'application "moniteur système".

Pour le paramétrage cliquer droit sur l’icône et sélectionner préférences. Dans l'écran sélectionner la case à cocher "charge" qui de loin est l'indicateur le plus pertinent. Basiquement un load supérieur aux nombres de processeurs indique un système chargé.

Pour obtenir les load average à distance (ce qui est pratique pour la supervision ou plus simplement pour éviter de devoir ouvrir de nombreuses consoles SSH), nous allons utiliser la RPC rstatd (un standard provenant de chez Sun).

Pour installer rstatd sur les serveurs à superviser, il vous suffit de suivre la procédure suivante :

• Activez les dépôts Universe.
• Installer le paquet rstatd (avec sudo apt-get install rstatd).
• Créer un petit script pour qu'il démarre tout seul au démarrage du serveur (sudo vi /etc/init.d/rstatd) :

#!/bin/sh

/usr/sbin/rpc.rstatd

• Activez ce script comme exécutable (sudo chmod +x /etc/init.d/rstatd).
• Liez le script avec les niveaux de démarrage :

update-rc.d rstatd defaults

• Lancez le démon rstatd (sudo /etc/init.d/rstatd).

Voilà, la machine est prête à recevoir les requêtes distantes.

Sur la machine devant interroger les serveurs :

• Activez les dépôts Universe.
• Installer le paquet rstat-client (avec sudo apt-get install rstat-client).

Vous avez maintenant deux commandes supplémentaires vous permettant d'obtenir des informations distantes sur les serveurs équipés de rstatd :

• rup : qui permet d'obtenir la commande uptime à distance.
• rsysinfo : qui permet d'obtenir diverses informations systèmes en plus du uptime.

En introduisant uniquement rup dans une console, vous envoyez une requête broadcast sur votre réseau vous permettant d'obtenir tous les load average des serveurs possèdant rstatd :

mail                  13:31 up  43 days, 56 mins, load 0.11 0.06 0.01
ns                    13:31 up  43 days, 56 mins, load 0.11 0.06 0.01
nodeprod1             13:31 up  19 days,    1:28, load 0.37 0.15 0.05
backup                13:31 up  43 days, 45 mins, load 3.09 1.96 2.17
nodeprod2             13:31 up  10 days,  6 mins, load 1.28 0.63 0.34
nodearch2             13:31 up  10 days, 19 mins, load 1.00 1.00 1.00
nodearch1             13:31 up  43 days, 49 mins, load 0.00 0.00 0.00
clusterprod           13:31 up  10 days,  6 mins, load 1.28 0.63 0.34

En faisant suivre rup du nom d'hôte ou de l'IP de la machine, vous n'obtiendrez que les informations concernant la machine en paramètres.

Concernant la commande rsysinfo, il faut toujours la faire suivre d'un nom d'hôte/IP et elle fournit les informations suivantes :

System Information for: mail
uptime:  43 days, 57 mins, load average: 0.14 0.08 0.02
cpu usage (jiffies): user 8937954  nice 551364  system 840299  idle 728313726
page in: 0  page out: 0   swap in: 0  swap out: 0
intr: -1     context switches: 158521092
disks: 0 0 0 0
ethernet:  rx: 1586681326   rx-err: 1064754
           tx: 1583182307   tx-err: 2081    collisions: 36153189

• Pour la surveillance des load averages avec Nagios, j'utilise ce script comme vérificateur :

#!/bin/sh

# Usage : check_rup $HOSTNAME $WARNING $CRITICAL
# (remarque : les valeurs limites s'expriment en 1/100e
#
# Exemple : check_rup 192.168.254.30 100 320
# (warning vaut 1.00, critical vaut 3.20)

STATE_OK=0
STATE_WARNING=1
STATE_CRITICAL=2
STATE_UNKNOWN=3

HOSTNAME=$1
WARNING=$2
CRITICAL=$3

VALUE=`rup $1 | awk '{print $10}' | awk -F "." '{print $1$2}'`
REAL_VALUE=`echo $VALUE | awk '{print $1/100}'`

if test -z $VALUE
then
        echo "Error during execute of 'rup' command."
        exit $STATE_UNKNOWN
fi

if test $VALUE -ge $CRITICAL
then
        echo "Load average 1 minute is CRITICAL ($REAL_VALUE)"
        exit $STATE_CRITICAL
fi

if test $VALUE -ge $WARNING
then
        echo "Load average 1 minute is WARNING ($REAL_VALUE)"
        exit $STATE_WARNING
fi

echo "Load average 1 minute is OK ($REAL_VALUE)"
exit $STATE_OK

• et ces informations comme "misccommand" :

define command{
        command_name    check_ruptime
        command_line    /usr/lib/nagios/plugins/check_rup $HOSTADDRESS$ $ARG1$ $ARG2$
        }

Contributeurs : ostaquet