hi est 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 au CPU (des données sont arrivées, par exemple).
Étant donné que ceux-ci peuvent se produire très fréquemment et qu'ils bloquent essentiellement le processeur actuel pendant leur exécution, les gestionnaires d'interruptions matérielles du noyau sont écrits pour être aussi rapides et simples que possible.
Si des traitements longs ou complexes doivent être effectués, ces tâches sont différées à l'aide d'un mécanisme appelé softirqs . Ceux-ci sont programmés indépendamment, peuvent s'exécuter sur n'importe quel processeur, peuvent même s'exécuter simultanément (rien de tout cela n'est vrai pour les gestionnaires d'interruptions matérielles).
La partie sur les IRQ dures bloquant le CPU actuel, et la partie sur softirqs être capable de fonctionner n'importe où n'est pas tout à fait correct, il peut y avoir des limitations, et certaines IRQ dures peuvent en interrompre d'autres.
Par exemple, une interruption matérielle "données reçues" d'une carte réseau pourrait simplement stocker les informations "la carte ethX doit être réparée" quelque part et planifier un softirq . Le softirq serait la chose qui déclenche le routage réel des paquets.
si représente le temps passé dans ces softirqs .
Une bonne lecture sur le softirq mécanisme (avec un peu d'histoire aussi) est I'll Do It Later:Softirqs, Tasklets, Bottom Halves, Task Queues, Work Queues and Timers de Matthew Wilcox (PDF, 64k).
st , "steal time", 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é" à cette machine virtuelle par l'hyperviseur (soit pour exécuter une autre machine virtuelle, soit pour ses propres besoins).
Le document de comptabilisation du temps CPU d'IBM contient plus d'informations sur le temps de vol et la comptabilisation du 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 sympas (priorité définie par l'utilisateur)
- id - Temps passé en opérations inactives
- wa - Temps passé à attendre sur les périphériques IO (ex. disque)
- salut - Temps passé à gérer les routines d'interruption matérielle. (Chaque fois qu'une unité périphérique demande l'attention du CPU, elle tire littéralement une ligne, pour signaler au CPU de l'entretenir)
- si - Temps passé à gérer les routines d'interruption logicielles. (un bout de code, appelle une routine d'interruption...)
- er - Temps passé en attentes involontaires par le processeur virtuel pendant que l'hyperviseur gère un autre processeur (volé à une machine virtuelle)
La valeur "st" peut être expliquée simplement en utilisant 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 consommerait beaucoup de temps processeur, 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 ne vous permettre d'accéder qu'à une certaine puissance de calcul. Cela vous ralentit intentionnellement puisque vous n'utilisez qu'un type d'instance de bas niveau.
J'espère que cela rend les choses un peu plus faciles à comprendre.