it-swarm.it

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

Quando emetto top in Linux, ottengo un risultato simile al seguente:

Screenshot of top

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 - cosa significano gli interrupt di manutenzione?
  • 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 tutto us, sy, ni, ecc, perché potrebbe aiutare gli altri a cercare 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
206
its_me

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 utilizzando 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 alla possibilità che softirqs sia in grado di funzionare ovunque non sono esattamente corretti, possono esserci delle limitazioni e alcuni IRQ rigidi possono interrompere altri.

Ad esempio, un interrupt di processo "dati ricevuti" da una scheda di rete potrebbe semplicemente memorizzare l'informazione "la scheda deve essere revisionata da ethX" da qualche parte e programmare un softirq. softirq sarebbe la cosa che innesca il routing effettivo dei pacchetti.

si rappresenta il tempo trascorso in questi softirqs.

Una buona lettura del meccanismo softirq (anche con un po 'di storia) è quella di Matthew Wilcox Lo farò più tardi: Softirqs, Tasklet, metà inferiori, Code attività, Code lavoro e Timer = (PDF, 64k).

st, "steal time", è 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 VM dall'hypervisor (o per eseguire un'altra VM, o per le proprie esigenze).

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

96
Mat
  • 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 IO (ad 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 interruzione ...)
  • st - Tempo trascorso in attesa involontaria dalla CPU virtuale mentre l'hypervisor sta servendo un altro processore (rubato da una macchina virtuale)
20
Simon Rigét

Il valore "st" può essere semplicemente spiegato utilizzando un'istanza T2.micro EC2 di AWS.

Nella documentazione AWS puoi leggere che ottieni solo una prestazione di base del 10% per VCPU. Ciò significa che se si dispone di un processo che richiederebbe molto tempo 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.

2
draufunddran