Commande “top” de Linux: Que sont nous, sy, ni, id, wa, hi, si et st (pour l’utilisation du processeur)?

Lorsque j'émets topsous Linux, j'obtiens un résultat similaire à celui-ci:

Une des lignes contient des informations sur l’utilisation de l’UC:

Cpu(s): 87.3%us,  1.2%sy,  0.0%ni, 27.6%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

Bien que je connaisse les définitions de chacune d’elles (loin ci-dessous), je ne comprends pas ce que ces tâches signifient exactement.

• hi - Que signifient les interruptions matérielles de maintenance?
• si - Que signifient les interruptions de service dans les logiciels?
• st - Ils disent que c'est "le temps de processeur associé à l'attente involontaire du processeur virtuel pendant que l'hyperviseur dessert un autre processeur (ou)% de temps CPU volé à partir d'une machine virtuelle".

Mais qu'est-ce que cela signifie réellement? Quelqu'un peut-il être plus clair?

J'énuméré tous us, sy, ni, etc., parce que cela pourrait aider les autres à la recherche de la même chose. Cette information ne figure pas dans les pages de manuel.

us: user cpu time (or) % CPU time spent in user space
sy: system cpu time (or) % CPU time spent in kernel space
ni: user nice cpu time (or) % CPU time spent on low priority processes
id: idle cpu time (or) % CPU time spent idle
wa: io wait cpu time (or) % CPU time spent in wait (on disk)
hi: hardware irq (or) % CPU time spent servicing/handling hardware interrupts
si: software irq (or) % CPU time spent servicing/handling software interrupts
st: steal time - - % CPU time in involuntary wait by virtual cpu while hypervisor is servicing another processor (or) % CPU time stolen from a virtual machine

hiest le temps passé à traiter les interruptions matérielles. Les interruptions matérielles sont générées par les périphériques matériels (cartes réseau, contrôleur de clavier, minuterie externe, capteurs matériels, ...) lorsqu'ils doivent signaler quelque chose à la CPU (les données sont arrivées, par exemple).

Comme ils peuvent se produire très fréquemment et bloquent essentiellement le processeur en cours de fonctionnement, les gestionnaires d’interruptions matérielles du noyau sont écrits pour être aussi simples et rapides que possible.

Si un traitement long ou complexe doit être effectué, ces tâches sont différées à l'aide d'un appel de mécanisme softirqs. Celles-ci sont planifiées indépendamment, peuvent être exécutées sur n’importe quel processeur et peuvent même s’exécuter simultanément (ce n’est pas le cas des gestionnaires d’interruptions matérielles).

_{La partie concernant les IRQ obligatoires qui bloquent le processeur actuel et la softirqspossibilité de s'exécuter n'importe où ne sont pas tout à fait correctes, il peut y avoir des limitations et certaines IRQ strictes peuvent en interrompre d'autres.}

Par exemple, une interruption matérielle "données reçues" provenant d'une carte réseau pourrait simplement stocker les informations "la carte que la carte ethX doit être entretenue" quelque part et planifier une softirq. Le softirqserait la chose qui déclenche le routage de paquets réel.

sireprésente le temps passé dans ceux-ci softirqs.

Une bonne lecture du softirqmécanisme (avec un peu d'histoire aussi) est celle de Matthew Wilcox: je le ferai plus tard: Softirqs, Tasklets, moitiés inférieures, files d'attente, tâches et minuteries (PDF, 64k).

st, "voler du temps", n’est pertinent que dans les environnements virtualisés. Il représente le temps pendant lequel le processeur réel n'était pas disponible pour la machine virtuelle actuelle - il a été "volé" de cette machine virtuelle par l'hyperviseur (pour exécuter une autre machine virtuelle ou pour ses propres besoins).

Le document de comptabilisation du temps CPU d’IBM contient davantage d’informations sur le temps de vol et la comptabilisation de la CPU dans les environnements virtualisés. (Il est destiné au matériel de type zSeries, mais l'idée générale est la même pour la plupart des plates-formes.)

• nous - Temps passé dans l'espace utilisateur
• sy - Temps passé dans l'espace noyau
• ni - Temps passé à exécuter des processus utilisateur simples (priorité définie par l'utilisateur)
• id - Temps passé dans les opérations inactives
• wa - Temps d'attente sur les périphériques IO (p. ex. disque)
• hi - Temps passé à gérer les routines d'interruption matérielle. (Chaque fois qu'un périphérique veut attirer l'attention de la CPU, il tire littéralement une ligne pour indiquer à la CPU de la réparer)
• si - Temps passé à gérer les routines d'interruption logicielle. (un morceau de code, appelle une routine d'interruption ...)
• st - Temps passé par les processeurs virtuels à attendre involontairement pendant que l'hyperviseur dessert un autre processeur (volé sur une machine virtuelle)

La valeur "st" peut être simplement expliquée à l'aide d'une instance T2.micro EC2 d'AWS.

Dans la documentation AWS, vous pouvez lire que vous n'obtenez que 10% de performances de base par VCPU. Cela signifie que si vous avez un processus qui consomme beaucoup de temps CPU, la valeur "st" restera autour de 90 puisque vous n'êtes autorisé à utiliser que 10% du VCPU. La somme des autres valeurs restera autour de 10.

AWS utilise donc l'hyperviseur pour vous permettre uniquement d'accéder à une certaine quantité de puissance de calcul. Cela vous ralentit par intention, car vous utilisez uniquement un type d'instance de niveau inférieur.

J'espère que cela rend les choses un peu plus faciles à comprendre.