Discussion :

[sebaaas]

Bonjour à tous,

J'ai du mal à comprendre le "load average: 0,66" de la commande top alors que lors que j'additionne les différents %CPU des processus, je suis loin d'arrive à 66%


Bien à vous,

[xdelatour]

Bonsoir,

Il ne s'agit pas de la moyenne à l'instant t, mais d'une moyenne sur une durée déterminée.

En l'occurrence, il y a les valeurs 0,66, 0,64 et 0,43 qui correspondent à la charge moyenne en cours de la minute précédente, au cours des 5 dernières minutes et enfin de la charge moyenne sur les 15 dernières minutes. Cela est indiqué dans la page de manuel de la commande que vous pouvez obtenir en tapant "man top".

[sebaaas]

Bonjour,

Merci pour cette réponse.

Par rapport à ma capture, la consommation CPU des différents programme était stable depuis un certain temps, ce qui confirme la "load" de 0.66 et 0.64. Mon étonnement provient de la différence entre l'addition des consommations CPU (8.3+1.3+1.+1+0.7 = 12,3%) et le Load average de la minute et 5minutes précédentes .

Mon étonnement provient du pourcentage de WA "en attente E/S (« iowait »)"

[sebaaas]

Pour plus d'info, le serveur debian tourne sous vitualbox avec un seul preocesseur alloué.

Voici les données ce matin :


Comment le serveur arrive-t-il à gérer un load average de +/- 2.4? Ou plus généralement, comment fait-il pour faire plus de 100% (avec un seul CPU, un seul core, un seul thread)?
L'addition des différents % cpu me donne moins de 25% et dans le haut du tableau, j'ai un %cpu de 64,2 us => comment arrive-t-il à ce chiffre?

Merci de vos réponses?

[Escapetiger]

Bonjour,

Excellentes questions dont les réponses sont complexes. Ci-dessous, un extrait de wikipedia et d'un article d' un blog particulièrement documenté (en anglais) - la charge système sous Linux englobe le CPU, les attentes d' entrées/sorties (I/O), etc.

Bonne lecture,

Comment interpréter la charge ?
Cas d'un seul processeur, et d'optimisations systèmes (par opposition aux optimisations applicatives, à ne jamais négliger)

La charge est < 1
Une charge < 1 indique qu'il n'y a pas assez de processus pour occuper complètement la machine. La « compétition » pour le processeur est donc inexistante ; ce dernier exécute les instructions rapidement et est libéré. Un problème de performance proviendra donc certainement des demandes de traitement qui ne parviennent pas assez rapidement à la machine.

→ Pour améliorer les performances : effectuer plus de tâches simultanées, augmenter le débit des requêtes…

La charge est constamment à 1
Une charge de 1 constante signifie qu'il y avait à tout moment un et un seul processus en état de travail. Aucun processus n'a donc « attendu son tour » pour être traité par le processeur.
Cependant, s'il y a un processus unique qui occupe constamment le processeur, il pourrait éventuellement s'exécuter plus rapidement sur un processeur plus puissant. En effet, même si la file d'attente est vide, le processus « en cours » peut avoir besoin de plus de rapidité.

→ Pour améliorer les performances : s'il y a un seul processus, en ajouter et observer la charge. Sinon, l'équilibre est atteint, et plus de tâches à effectuer impliqueront une amélioration au niveau processeur, mémoire et/ou entrées-sorties.

La charge est supérieure à 1
Ceci ne signifie pas forcément qu'un processeur plus rapide résoudrait le problème. En effet, la charge inclut généralement les processus en attente d'entrées-sorties. Un processus dans ce cas sera donc comptabilisé, mais il est « bloqué » car il « attend » un périphérique d'I/O, et non pas le processeur.
Il faut donc prêter attention aux autres affichages des commandes comme top ; où l'utilisation processeur globale est également indiquée. Si le processeur est inactif (idle) à 90 % mais que la charge est élevée, un processeur plus véloce n'y changera rien. S'il reste « collé » à 100 % d'utilisation, alors il est certainement en cause.
(Autrement dit : un load > 1 n'indique une contention sur le processeur que si, et seulement si, le idle = 0.0.)

→ Pour améliorer les performances : examiner le taux d'utilisation global du processeur. Minimiser si possible les I/O (la quantité de mémoire vive est elle suffisante ?). Agir ensuite en conséquence sur les points faibles identifiés.

Source: Load average — Wikipédia

.../...

Linux Load Averages: Solving the Mystery
08 Aug 2017

Load averages are an industry-critical metric – my company spends millions auto-scaling cloud instances based on them and other metrics – but on Linux there's some mystery around them. Linux load averages track not just runnable tasks, but also tasks in the uninterruptible sleep state. Why? I've never seen an explanation. In this post I'll solve this mystery, and summarize load averages as a reference for everyone trying to interpret them.

Linux load averages are "system load averages" that show the running thread (task) demand on the system as an average number of running plus waiting threads. This measures demand, which can be greater than what the system is currently processing. Most tools show three averages, for 1, 5, and 15 minutes:
.../...

• History
• The Three Numbers
• Linux Uninterruptible Tasks
• Searching for an ancient Linux patch
• The origin of uninterruptible
• Uninterruptible today
• Measuring uninterruptible tasks
• Decomposing Linux load averages
  Can the Linux load average value be fully decomposed into components? Here's an example: on an idle 8 CPU system, I launched tar to archive some uncached files. It spends several minutes mostly blocked on disk reads. Here are the stats, collected from three different terminal windows:
  .../...

• Making sense of Linux load averages

I grew up with OSes where load averages meant CPU load averages, so the Linux version has always bothered me. Perhaps the real problem all along is that the words "load averages" are about as ambiguous as "I/O". Which type of I/O? Disk I/O? File system I/O? Network I/O? ... Likewise, which load averages? CPU load averages? System load averages? Clarifying it this way lets me make sense of it like this:

=> On Linux, load averages are (or try to be) "system load averages", for the system as a whole, measuring the number of threads that are working and waiting to work (CPU, disk, uninterruptible locks). Put differently, it measures the number of threads that aren't completely idle. Advantage: includes demand for different resources.
=> On other OSes, load averages are "CPU load averages", measuring the number of CPU running + CPU runnable threads. Advantage: can be easier to understand and reason about (for CPUs only).

Note that there's another possible type: "physical resource load averages", which would include load for physical resources only (CPU + disk).

Perhaps one day we'll add additional load averages to Linux, and let the user choose what they want to use: a separate "CPU load averages", "disk load averages", "network load averages", etc. Or just use different metrics altogether.

• What is a "good" or "bad" load average?
• Better Metrics
• Conclusion
• References

Source: Linux Load Averages: Solving the Mystery - Brendan Gregg's Blog

[sebaaas]

Merci pour ce complément d'information