hi è il tempo impiegato per elaborare gli interrupt hardware. Gli interrupt hardware vengono generati dai dispositivi hardware (schede di rete, controller della tastiera, timer esterno, sensori hardware, ...) quando devono segnalare qualcosa alla CPU (ad esempio, sono arrivati dei dati).
Poiché questi possono verificarsi molto frequentemente e poiché essenzialmente bloccano la CPU corrente mentre sono in esecuzione, i gestori di interrupt hardware del kernel sono scritti per essere il più veloci e semplici possibile.
Se è necessario eseguire un'elaborazione lunga o complessa, queste attività vengono rinviate utilizzando un meccanismo chiamato softirqs . Questi sono pianificati in modo indipendente, possono essere eseguiti su qualsiasi CPU, possono anche essere eseguiti contemporaneamente (niente di tutto ciò vale per i gestori di interrupt hardware).
La parte sugli IRQ rigidi che bloccano la CPU corrente e la parte su softirqs essere in grado di funzionare ovunque non è esattamente corretto, ci possono essere limitazioni e alcuni IRQ difficili possono interromperne altri.
Ad esempio, un interrupt hardware "dati ricevuti" da una scheda di rete potrebbe semplicemente memorizzare le informazioni "la scheda ethX deve essere riparata" da qualche parte e programmare un softirq . Il softirq sarebbe la cosa che attiva l'effettivo instradamento dei pacchetti.
si rappresenta il tempo trascorso in questi softirqs .
Una buona lettura del softirq (con anche un po' di storia) è I'll Do It Later di Matthew Wilcox:Softirqs, Tasklets, Bottom Halves, Task Queues,Work Queues and Timers (PDF, 64k).
st , "steal time", è rilevante solo negli ambienti virtualizzati. Rappresenta il momento in cui la vera CPU non era disponibile per la macchina virtuale corrente:è stata "rubata" da quella VM dall'hypervisor (o per eseguire un'altra VM o per le proprie esigenze).
Il documento di contabilità del tempo della CPU di IBM contiene ulteriori informazioni sul tempo di furto e sulla contabilità della CPU negli ambienti virtualizzati. (Si rivolge all'hardware di tipo zSeries, ma l'idea generale è la stessa per la maggior parte delle piattaforme.)
- us - Tempo trascorso nello spazio utente
- sy - Tempo trascorso nello spazio del kernel
- ni - Tempo impiegato per l'esecuzione di processi utente migliorati (priorità definita dall'utente)
- id - Tempo trascorso in operazioni inattive
- wa - Tempo trascorso in attesa sulle periferiche IO (ad es. disco)
- hi - Tempo speso a gestire le routine di interrupt hardware. (Ogni volta che un'unità periferica richiede attenzione dalla CPU, tira letteralmente una linea, per segnalare alla CPU di ripararla)
- si - Tempo impiegato a gestire le routine di interrupt del software. (un pezzo di codice, chiama una routine di interrupt...)
- st - Tempo impiegato in attese involontarie dalla cpu virtuale mentre l'hypervisor sta eseguendo la manutenzione di un altro processore (rubato da una macchina virtuale)
Il valore "st" può essere semplicemente spiegato utilizzando un'istanza T2.micro EC2 di AWS.
Nella documentazione di AWS puoi leggere che ottieni solo una prestazione di base del 10% per VCPU. Ciò significa che se si dispone di un processo che consumerebbe molto tempo della CPU, il valore "st" rimarrà intorno a 90 poiché è consentito utilizzare solo il 10% del VCPU. La somma degli altri valori rimarrà intorno a 10.
Quindi AWS utilizza l'hypervisor per consentirti di accedere solo a una certa quantità di potenza di calcolo. Ti rallenta intenzionalmente poiché stai utilizzando solo un tipo di istanza di basso livello.
Spero che questo renda le cose un po' più facili da capire.