Comando "top" di Linux: Cosa siamo noi, sy, ni, id, wa, hi, si e st (per l'utilizzo della CPU)?

195

Quando emetto topin Linux, ottengo un risultato simile al seguente:

Schermata della parte superiore

Una delle righe ha informazioni sull'utilizzo della CPU rappresentate in questo modo:

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

Mentre conosco le definizioni di ciascuno di essi (molto più in basso), non capisco cosa significano esattamente questi compiti.

hi - che cosa significa manutenzione degli interrupt di processo?
si - cosa significano gli interrupt di manutenzione del software?
st - dicono che è il "tempo di CPU in attesa involontaria da parte della CPU virtuale mentre l'hypervisor sta servendo un altro processore (o)% del tempo di CPU rubato da una macchina virtuale".

Ma cosa significa in realtà? Qualcuno può essere più chiaro?

Ho elencato tutti us, sy, ni, ecc, perché potrebbe aiutare gli altri che cercano lo stesso. Questa informazione non è nelle pagine man.

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

linux cpu top

— sono io
fonte

92

hiè il tempo impiegato per l'elaborazione degli interrupt di processo. Gli interrupt di processo sono generati da dispositivi hardware (schede di rete, controller di tastiera, timer esterno, sensori hardware, ...) quando devono segnalare qualcosa alla CPU (i dati sono arrivati, ad esempio).

Dal momento che questi possono accadere 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ù rapidi e semplici possibile.

Se è necessario eseguire elaborazioni lunghe o complesse, queste attività vengono rinviate mediante una chiamata al meccanismo softirqs. Questi sono programmati in modo indipendente, possono essere eseguiti su qualsiasi CPU, possono anche essere eseguiti contemporaneamente (nulla di tutto ciò vale per i gestori di interrupt di processo).

_{La parte relativa agli IRQ rigidi che bloccano la CPU corrente e la parte relativa softirqsalla possibilità di funzionare ovunque non sono esattamente corretti, possono esserci delle limitazioni e alcuni IRQ duri possono interrompere altri.}

Ad esempio, un interrupt di processo "dati ricevuti" da una scheda di rete potrebbe semplicemente memorizzare l'informazione "la scheda ethX deve essere revisionata" da qualche parte e programmare un softirq. La softirqSarebbe la cosa che fa scattare l'instradamento dei pacchetti reale.

sirappresenta il tempo trascorso in questi softirqs.

Una buona lettura del softirqmeccanismo (anche con un po 'di storia) è di Matthew Wilcox che lo farò più tardi: Softirq, Tasklet, metà inferiori, Code attività, Code lavoro e Timer (PDF, 64k).

st, "rubare tempo", è rilevante solo negli ambienti virtualizzati. Rappresenta il momento in cui la CPU reale non era disponibile per la macchina virtuale corrente: è stata "rubata" da quella macchina virtuale dall'hypervisor (o per eseguire un'altra macchina virtuale o per le proprie esigenze).

Il documento di contabilità del tempo della CPU di IBM contiene ulteriori informazioni su rubare tempo e contabilità della CPU in ambienti virtualizzati. (È rivolto all'hardware di tipo zSeries, ma l'idea generale è la stessa per la maggior parte delle piattaforme.)

— Stuoia
fonte

molto chiaro. Quindi, se collego un nuovo sistema audio, cuffie, ecc. (Qualsiasi hardware del caso) provoca anche un'interruzione hardware, giusto?

— its_me,

2

Sì, potrebbe essere un modo per il tuo chipset audio di segnalare che "è successo qualcosa". Ma collegare un auricolare potrebbe essere gestito interamente dal chip audio stesso (reindirizzare il suono emesso dall'uscita principale verso le cuffie, ad esempio), quindi potrebbe non generare un interruzione alla CPU principale. Digitare un tasto sulla tastiera genererà interruzioni (dal dispositivo hub USB se si dispone di una tastiera USB). Vedi anche cat /proc/interrupts(man man procfor doc. Su quel file).

— Mat

15

noi - Tempo trascorso nello spazio utente
sy - Tempo trascorso nello spazio del kernel
ni - Tempo trascorso nell'esecuzione di processi utente nettati (Priorità definita dall'utente)
id - Tempo trascorso in operazioni inattive
wa - Tempo trascorso in attesa su periferiche IO (es. disco)
hi - Tempo impiegato a gestire le routine di interrupt di processo. (Ogni volta che un'unità periferica richiede attenzione dalla CPU, tira letteralmente una linea, per segnalare alla CPU di servirla)
si - Tempo impiegato nella gestione delle routine di interruzione del software. (un pezzo di codice, chiama una routine di interrupt ...)
st - Tempo trascorso in attesa involontaria dalla CPU virtuale mentre l'hypervisor sta servendo un altro processore (rubato da una macchina virtuale)

— Simon Rigét
fonte

2

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% della VCPU. La somma degli altri valori rimarrà intorno a 10.

Pertanto AWS utilizza l'hypervisor per consentire l'accesso a una determinata quantità di potenza di elaborazione. Ti rallenta di proposito poiché stai utilizzando solo un tipo di istanza di livello inferiore.

Spero che questo renda le cose un po 'più facili da capire.

— draufunddran
fonte