Come faccio a leggere htop


9

Ho difficoltà a comprendere le informazioni visualizzate dal htoppopolare sostituto del comando principale Linux.

dump dello schermo htop

Nella schermata sopra, ci sono molte istanze java elencate, ma solo quella principale utilizza il tempo della CPU. Quali sono gli altri?

Perché le barre di utilizzo della CPU mostrano core così occupati quando la colonna% CPU mostra che non accade molto in tutti i processi? In realtà, si muovono senza correlazione per la maggior parte del tempo.

Perché la media del carico, in alto a destra, che presumo sia una cronologia in 3 passaggi, così bassa quando i core sono quasi sempre verdi e sembrano occupati?

Qualcuno sarebbe così gentile da spiegare come leggere queste informazioni?

Grazie!


Ho apportato alcune modifiche che aiutano molto. Visualizza i thread con un colore diverso, mostra i nomi dei thread, aggiorna i nomi dei processi durante l'aggiornamento e, soprattutto, cambia il ritardo a 2/10 secondi. La velocità di aggiornamento predefinita mostra solo un enorme ritardo tra i misuratori della CPU e i processi.
Luke Puplett,

1
Almeno per la media del carico, questo non è necessariamente un valore basso. Il carico è essenzialmente un indicatore del fatto che il sistema debba aspettare per fare qualcosa. Un valore accettabile è inferiore al numero di core, in questo caso 4. Quindi tali medie sono ragionevoli. Sono gli ultimi 1, 5 e 15 minuti. Per maggiori informazioni, vedi [Wikipedia] ( en.wikipedia.org/wiki/Load_(computing))
ssmy

Risposte:


5
  1. Per quanto riguarda "Carica" ​​e CPU%, Wikipedia ha una spiegazione dettagliata ed esempio, di seguito è riportato un preventivo parziale

    Un computer inattivo ha un numero di carico pari a 0 e ogni processo che utilizza o attende la CPU (la coda pronta o la coda di esecuzione) incrementa il numero di carico di 1. La maggior parte dei sistemi UNIX conta solo i processi in esecuzione (su CPU) o eseguibili (in attesa di CPU). Tuttavia, Linux include anche processi in stato di sonno ininterrotto (in genere in attesa di attività del disco), che può portare a risultati notevolmente diversi se molti processi rimangono bloccati nell'I / O a causa di un sistema di I / O occupato o in stallo. Ciò, ad esempio, include il blocco dei processi a causa di un errore del server NFS o del rallentamento dei supporti (ad es. Dispositivi di archiviazione USB 1.x). Tali circostanze possono comportare una media del carico elevata, che non riflette un effettivo aumento dell'utilizzo della CPU (ma dà comunque un'idea di quanto tempo gli utenti devono attendere).

    I sistemi calcolano la media del carico come media mobile esponenzialmente smorzata / ponderata del numero di carico. I tre valori della media del carico si riferiscono ai precedenti uno, cinque e quindici minuti di funzionamento del sistema.

    Per i sistemi a CPU singola che sono associati alla CPU, si può pensare alla media del carico come una percentuale di utilizzo del sistema durante il rispettivo periodo di tempo. Per i sistemi con più CPU, è necessario dividere il numero per il numero di processori per ottenere una percentuale comparabile.

    Le barre potrebbero essere impegnate a muoversi, ma non raggiungono mai il 100%, il che indica che la CPU / core è completamente utilizzata. La barra è solo una visualizzazione del% di utilizzo della CPU, che è al 27%, 26,5%, 24,5%, 24,7% e 71,7%. Tutti i core della CPU hanno ancora il potere di "risparmiare". A quel punto sono tutti sottoutilizzati.

    Un sistema 5 core / cpu completamente utilizzato avrà carico 5 o superiore.

  2. Per quanto riguarda le righe Java, sono processi padre (PID = 5073) e figlio. Non riesco a spiegare perché il genitore accumuli più tempo della CPU. Dipende molto dalla logica interna del programma. Tuttavia, secondo TIME +, quei processi figlio consumavano il tempo della CPU, con l'ultimo (PID = 5074) accumulato di più.


È possibile che i processi figlio siano il threadpool JVM? Quando imposto l'opzione per mostrare i nomi dei thread, tutti hanno lo stesso nome. Sono un programmatore di Windows + .NET, a proposito.
Luke Puplett,

Sì, è possibile che siano thread.
John Siu,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.