hi ist die Zeit, die für die Verarbeitung von Hardware-Interrupts aufgewendet wird. Hardware-Interrupts werden von Hardware-Geräten (Netzwerkkarten, Tastatur-Controller, externe Zeitgeber, Hardware-Sensoren, ...) generiert, wenn sie der CPU etwas signalisieren müssen (z. B. Daten sind angekommen).
Da dies sehr häufig passieren kann und da sie im Wesentlichen die aktuelle CPU blockieren, während sie laufen, sind Kernel-Hardware-Interrupt-Handler so geschrieben, dass sie so schnell und einfach wie möglich sind.
Wenn eine lange oder komplexe Verarbeitung durchgeführt werden muss, werden diese Aufgaben unter Verwendung eines Mechanismusaufrufs softirqs zurückgestellt . Diese werden unabhängig geplant, können auf jeder CPU laufen, können sogar gleichzeitig laufen (nichts davon gilt für Hardware-Interrupt-Handler).
Der Teil über harte IRQs, die die aktuelle CPU blockieren, und der Teil über softirqs überall laufen zu können, sind nicht ganz richtig, es kann Einschränkungen geben, und einige harte IRQs können andere unterbrechen.
Beispielsweise könnte ein Hardware-Interrupt "Daten empfangen" von einer Netzwerkkarte einfach die Information "Karte ethX muss gewartet werden" irgendwo speichern und einen softirq planen . Die softirq wäre das Ding, das das eigentliche Paket-Routing auslöst.
si stellt die in diesen softirqs verbrachte Zeit dar .
Eine gute Lektüre über die softirq Mechanismus (mit ein wenig Geschichte) ist Matthew Wilcox's I'll Do It Later:Softirqs, Tasklets, Bottom Halves, Task Queues,Work Queues and Timers (PDF, 64k).
st , „Zeit stehlen“, ist nur in virtualisierten Umgebungen relevant. Es stellt die Zeit dar, in der die reale CPU für die aktuelle virtuelle Maschine nicht verfügbar war – sie wurde von dieser VM durch den Hypervisor „gestohlen“ (entweder zum Ausführen einer anderen VM oder für den eigenen Bedarf).
Das CPU-Zeitabrechnungsdokument von IBM enthält weitere Informationen zu Steal Time und CPU-Abrechnung in virtualisierten Umgebungen. (Es zielt auf zSeries-Hardware ab, aber die allgemeine Idee ist für die meisten Plattformen gleich.)
- us – Im Benutzerbereich verbrachte Zeit
- sy - Im Kernelspace verbrachte Zeit
- ni - Zeit, die für das Ausführen von netten Benutzerprozessen aufgewendet wird (benutzerdefinierte Priorität)
- id - Zeit, die im Leerlauf verbracht wird
- wa - Zeit, die für das Warten auf IO-Peripheriegeräte (z. B. Festplatte) aufgewendet wird
- hi - Zeitaufwand für die Bearbeitung von Hardware-Interrupt-Routinen. (Immer wenn eine periphere Einheit Aufmerksamkeit von der CPU will, zieht sie buchstäblich eine Leitung, um der CPU zu signalisieren, sie zu warten)
- si - Zeitaufwand für die Bearbeitung von Software-Interrupt-Routinen. (ein Stück Code, ruft eine Interrupt-Routine auf...)
- st – Zeit, die von der virtuellen CPU für unfreiwillige Wartezeiten aufgewendet wird, während der Hypervisor einen anderen Prozessor bedient (von einer virtuellen Maschine gestohlen)
Der „st“-Wert lässt sich einfach durch die Verwendung einer T2.micro EC2-Instanz von AWS erklären.
In der AWS-Dokumentation können Sie lesen, dass Sie nur 10 % Basisleistung pro VCPU erhalten. Das bedeutet, wenn Sie einen Prozess haben, der viel CPU-Zeit verbrauchen würde, bleibt der "st"-Wert bei etwa 90, da Sie nur 10 % der VCPU verwenden dürfen. Die Summe der anderen Werte bleibt bei etwa 10.
AWS verwendet also den Hypervisor, um Ihnen nur den Zugriff auf eine bestimmte Menge an Rechenleistung zu ermöglichen. Es verlangsamt Sie absichtlich, da Sie nur einen Instanztyp der unteren Ebene verwenden.
Ich hoffe, das macht die Sache ein wenig verständlicher.