Buoni strumenti di risoluzione dei problemi di sistema sono tutto. Grandi strumenti, tuttavia, sono più difficili da trovare. Fortunatamente, Linux viene fornito con una vasta gamma di programmi e utilità eccellenti che consentono di profilare, analizzare e risolvere i problemi di comportamento del sistema, dai colli di bottiglia delle applicazioni alle configurazioni errate e persino ai bug. Tutto inizia con uno strumento in grado di acquisire le metriche necessarie e fornirti i dati di cui hai bisogno.
Health-check è un programma accurato in grado di monitorare e profilare i processi, in modo da poter identificare e risolvere l'utilizzo in eccesso delle risorse o i problemi associati. Laddove si distingue rispetto al resto della folla:mira a offrire contemporaneamente molti aspetti utili dei dati di sistema, in modo da poter cercare più facilmente i componenti nei sistemi, risolvere i problemi di prestazioni e correggere gli errori di configurazione nel tuo ambiente. Invece di dover eseguire cinque strumenti contemporaneamente, o eseguire cinque corse per ottenere tutte le informazioni di cui hai bisogno, usi semplicemente il controllo dello stato e Bob è un tuo lontano parente. Bene. Va bene, pronto? Procedi.
Controllo sanitario in azione
Prima di eseguire l'utilità con rabbia, alcune piccole note. Uno, sono necessari i privilegi sudo per eseguire questo strumento, sebbene sia possibile eseguire l'applicazione effettiva nel contesto di altri utenti sul sistema (con il flag -u). Secondo, è necessaria una certa comprensione di come funziona Linux per utilizzare i risultati:ho un sacco di articoli su questo argomento, collegati più avanti.
In sostanza, come ho sottolineato solo un momento fa, health-check unisce le funzionalità di una varietà di programmi sotto un unico ombrello. Combina bene gli elementi che otterresti se esegui netstat, lsof, vmstat, iostat ed esamini vari struct in /proc e /sys. Questo è un po' come dstat, che combina la potenza di vmstat, iostat e ifstat. Puoi iniziare con la corsa semplice (-b flag):
sudo ./health-check -u "user" -b "binary"
Ci sarà molto output, anche in questa modalità "breve", qualcosa come:
Utilizzo CPU (in termini di 1 CPU):
Utente:34,24%, Sistema:13,30%, Totale:47,54% (carico elevato)
Innanzitutto, ottieni i dati della CPU di base, normalizzati per core (100% =1 core completo). Health-check ha soglie interne in base alle quali indicherà se si tratta di un carico basso, moderato o alto. Questo è solo per darti un'idea di cosa dovresti aspettarti. Le specifiche dipenderanno dal tipo di applicazione e dal carico di lavoro che stai profilando. Ci saranno differenze tra la GUI e gli strumenti a riga di comando, il software che legge da un database a uno che non lo fa, il software con un gran numero di librerie condivise, l'uso dell'hardware, ecc.
Errori di pagina:
Processo PID Minore/sec Maggiore/sec Totale/sec
1043 google-chrome 16156.46 0.25 16156.71
Abbiamo parlato a lungo di errori di pagina in passato (collegamenti nella sezione di ulteriori letture di seguito). Se non sai cosa dovrebbe fare la tua applicazione, i numeri non ti diranno molto da soli. Ma possono essere molto utili per studi comparativi, come due diversi programmi dello stesso tipo, o due diverse versioni dello stesso programma, o lo stesso programma in esecuzione su due piattaforme diverse.
Interruttori di contesto:
13687.53 cambi di contesto/sec (molto alto)
Il valore del cambio di contesto indica la frequenza con cui il kernel abbandona la coda di esecuzione e passa da un'attività all'altra. Per i processi interattivi (come il browser), che hanno un componente interattivo per l'utente, in realtà si desidera il maggior numero possibile di cambi di contesto (le attività vengono eseguite il meno possibile), perché non si desidera che queste attività monopolizzino il processore. In effetti, il calcolo lungo è un segno di lavori batch. In questo caso, avere pochi cambi di contesto potrebbe essere un'indicazione di un problema con un'applicazione interattiva (GUI) come il browser.
Operazioni di I/O su file:
Operazioni di I/O al secondo:312,80 di apertura, 283,49 di chiusura, 768,71 di lettura,
410,83 di scrittura
I valori di I/O sono utili se si dispone di una linea di base e dipendono anche dallo stack di I/O sottostante, inclusi l'hardware, il bus, il driver, la scelta del filesystem e qualsiasi altra operazione su disco in esecuzione contemporaneamente.
Analisi delle chiamate del sistema di polling:
google-chrome (1043), sondaggio:
1555 chiamate scadute immediate con timeout zero (peek non bloccanti)
1 chiamate polling ripetute scadute con timeout diverso da zero timeout
(polling leggero)
1125 chiamate polling ripetute con timeout immediato e zero timeout
(peek polling pesante)
Questa sezione è un altro indicatore della possibile interattività dell'utente del binario profilato. Le chiamate di sistema di polling sono chiamate di sistema che attendono che le descrizioni dei file siano pronte per eseguire operazioni di I/O. In genere, questo indicherà le connessioni di rete. Lo esamineremo più in dettaglio quando faremo una corsa completa.
Memoria:
Modifica nella memoria (K/secondo):
PID Tipo di processo Dimensione RSS PSS
1043 google-chrome Stack 32,51 27,59 27,59 (in crescita
moderatamente veloce)
1043 google-chrome Heap 67550.94 9092.51 9112.70 (in crescita molto
veloce)
1043 google-chrome Mapped 102764.33 27296.24 18781.80 (in crescita molto
veloce)
Per la maggior parte delle persone e per la maggior parte dei tipi di applicazioni, le operazioni sulla memoria non saranno così interessanti. I carichi di lavoro ad alta intensità di memoria non sono così comuni nei software desktop. Possono essere piuttosto importanti per database e calcoli complessi, cosa che normalmente faresti su un sistema di classe server. Ma questo insieme di numeri può essere utilizzato per esaminare le differenze tra piattaforme, kernel e versioni software.
Connessioni di rete aperte:
Processo PID Proto Invia indirizzo di ricezione
1043 google-chrome UNIX 531,52 K 35,16 K /run/user/1000/bus
1043 google-chrome UNIX 0,00 B 88,56 K /run /systemd/journal/...
1043 presa google-chrome 64,51 K 0,00 B:[2737924]
1043 presa google-chrome 30,55 K 0,00 B:[2746558]
1043 presa google-chrome Presa 3,98 K 0,00 B:[2742865]
...
L'insieme di numeri delle connessioni di rete ti dà risultati simili a quelli che fanno netstat e lsof, ma ottieni anche i valori di invio/ricezione, che possono essere molto utili. Se sai cosa deve fare il programma in termini di rete, puoi profilarne l'esecuzione e cercare possibili configurazioni errate nello stack di rete.
Corsa più lunga (dettagliata)
Puoi anche optare per più statistiche (ad esempio, con -c -f flag, no -b flag). Otterrai risultati estesi per ciascuna delle sezioni che abbiamo discusso in precedenza e questo può darti ulteriori informazioni sul comportamento del tuo software. Se stai tracciando processi e fork figli, puoi vedere la sequenza di esecuzione. Le statistiche della CPU verranno elencate in base all'utilizzo, con i più alti trasgressori in cima.
Utilizzo CPU (in termini di 1 CPU):
Processo PID USR% SYS% TOTAL% Durata
1715 vlc 47,04 8,17 55,21 14,71 (carico elevato)
1720 vlc 46,91 7,96 54,87 14,43 (carico elevato) )
1723 vlc 46.77 7.96 54.74 14.35 (carico elevato)
...
1721 vlc 1.69 1.08 2.77 1.21 (carico leggero)
1722 vlc 0.20 0.07 0.27 0.16 (carico molto leggero ). 0,00 0,06 (inattivo)
1719 vlc 0,00 0,00 0,00 0,06 (inattivo)
Totale 971,80 161,72 1133,52 (CPU a pieno carico)
Nell'esempio sopra, eseguendo VLC (con una riproduzione di clip HD di circa 14 secondi), abbiamo utilizzato l'1.133% del tempo della CPU, che si traduce in 11,33 core della CPU. Sembra molto, ma dal momento che il sistema ha otto core (thread), questo significa effettivamente che solo 1,5 core sono stati effettivamente utilizzati per il video. Sarebbe anche interessante sapere quali core sono stati effettivamente utilizzati.
Interruttori di contesto:
Processo PID Volontario Involontario Totale
Ctxt Sw/Sec Ctxt Sw/Sec Ctxt Sw/Sec
1744 vlc 2500,09 1,15 2501,24 (alto)
1723 vlc 1493,47 1,82 1495,29 ( alto)
1740 vlc 1224,03 3,31 1227,33 (alto)
1717 vlc 947,43 0,40 947,84 (abbastanza alto)
1731 vlc 736,37 0,81 737,18 (abbastanza alto)
Per gli errori di pagina, non c'è niente di nuovo. Con i cambi di contesto, otteniamo anche un elenco di CS volontari e involontari. Quest'ultimo gruppo può essere un'indicazione di attività che superano la loro fetta allocata, il che comporterebbe quindi una priorità dinamica inferiore la prossima volta che vengono eseguite (il che non va bene per i processi interattivi).
Operazioni di I/O su file:
PID Process Count Op Nome file
1715 vlc 176 R /home/roger/developers.webm
1715 vlc 48 C /etc/ld.so.cache
1715 vlc 48 O /etc/ld.so.cache
1715 vlc 34 R /usr/share/X11/locale/locale.alias
Il File I/O ora mostra anche il numero di operazioni per processo, il tipo di operazione e il nome del file. Questo non deve essere un file effettivo sul disco, potrebbe anche essere un bus. Le operazioni disponibili sono stampate in fondo a questa sezione. Il modo esatto in cui vengono eseguite le operazioni di lettura e scrittura dipende da molti fattori.
...
1715 vlc 1 C /lib/x86_64-linux-gnu/libnss_systemd.so.2
1715 vlc 1 O /usr/bin/vlc
Totale 4352
Op :O=Apri, R=Leggi, W=Scrivi, C=Chiudi
Ottieni anche la frequenza di queste operazioni di I/O:
Operazioni di I/O su file al secondo:
Processo PID Apri Chiudi Leggi Scrivi
1715 vlc 100,57 96,72 89,77 1,75
1719 vlc 3,24 4,99 3,04 0,00
...
La prossima sezione riguarda le chiamate di sistema ed è molto dettagliata. L'output è simile a strace. Avrai l'ID del processo, il nome del processo, la chiamata di sistema, il conteggio, la tariffa, il tempo totale (in noi) e la percentuale che ciascuna chiamata di sistema ha preso dal tempo di esecuzione totale. Non puoi interpretare questi numeri a meno che tu non sappia cosa deve fare l'applicazione o se non puoi confrontare con una linea di base.
Chiamate di sistema tracciate:
Processo PID Syscall Count Rate/sec Total uSecs % Call Time
1715 vlc stat 429 28,9555 3004 0,0011
1715 vlc mmap 240 16,1989 4912 0,0017
1715 vlc mprotect 20 13.7015 4739 0.0017
...
Le informazioni sono più utili quando si esaminano le chiamate di sistema di polling. Per brevità, ho leggermente modificato l'output di seguito. Gli ultimi quattro campi indicano tutti i timeout, ad es.:Timeout zero, Timeout minimo, ecc. In sostanza, forniscono un indicatore del tempo impiegato dal completamento di queste chiamate di sistema. Il campo Conteggio infinito si riferisce a chiamate di sistema con un'attesa infinita (per la durata dell'esecuzione dell'applicazione). Le informazioni vengono visualizzate anche come istogramma per processo, da zero a infinito, con intervalli logaritmici, fino a 10 us, 10-99 us, 100-99 us e così via.
Principali chiamate di sistema di polling:
PID Process Syscall Rate/Sec Inf Zero Min Max Avg
1715 vlc poll 3.2398 45 1 0.0 s 25.0 s 1.0 s
1715 vlc rt_sigtimed 0.1350 2 0 0.0 s 0.0 s 0,0 s
1717 sondaggio vlc 124.7312 5 1 0,0 s 30,0 s 958,4 ms
...
Il registro di output più dettagliato conterrà anche i dati di sincronizzazione del filesystem.
Sincronizzazioni file system:
PID fdatasync fsync sync syncfs totale totale (Tasso)
1723 0 2 0 0 2 0.13
File sincronizzati:
PID syscall # nome file sync
1723 fdatasync 1 /home/roger/.../vlc-qt-interface.conf.lock
1723 fdatasync 1 /home/roger/.../vlc-qt-interface.conf.XM1715
Infine, l'output dettagliato conterrà anche informazioni sulla memoria e sulla connessione di rete, ma la differenza principale saranno i risultati mostrati per processo. Come abbiamo discusso in precedenza, il primo in genere non sarà utile per la maggior parte dei carichi di lavoro desktop (a meno che tu non sia lo sviluppatore del programma), mentre il secondo può essere utile per trovare problemi nello stack di rete.
Health-check crea una serie piuttosto ampia di risultati, ma fornisce molte informazioni sul comportamento delle tue applicazioni. Puoi combinarne l'utilizzo con altri software per ottenere un'analisi completa del tuo software e risolvere eventuali problemi di prestazioni. Health-check può anche profilare le attività in esecuzione (-p flag), il che lo rende abbastanza utile come aggiunta alla tua cassetta degli attrezzi per la risoluzione dei problemi.
Configurazione manuale
Se non sei soddisfatto della versione disponibile nei repository, puoi compilare manualmente. Un altro motivo per farlo è aggirare eventuali problemi che potrebbero avere le versioni precedenti, come ad esempio l'errore timer_stats, per cui gli strumenti tentano di accedere a /proc/timer_stats, ma questa struttura non è più esposta nei kernel recenti:
Impossibile aprire /proc/timer_stats.
Infatti, se controlli, ottieni:
cat /proc/timer_stats
cat:/proc/timer_stats:nessun file o directory di questo tipo
Per compilare, esegui:
git clone https://kernel.ubuntu.com/git/cking/health-check.git/
cd health-check
make
Potresti visualizzare il seguente errore:
json.h:25:10:errore irreversibile:json-c/json.h:nessun file o directory di questo tipo
#include
Ciò significa che ti manca il pacchetto di sviluppo per JSON, che lo strumento deve compilare correttamente. Il nome effettivo del pacchetto varierà da una distribuzione all'altra, ma nel mio test su Kubuntu, quanto segue ha risolto l'errore di compilazione:
sudo apt-get install libjson-c-dev
Altre letture
Se sei interessato a strumenti aggiuntivi sulla risoluzione dei problemi del sistema, allora:
Strumenti di amministrazione super-duper Linux:strace
Strumenti di amministrazione super-duper Linux:lsof
Strumenti di amministrazione super-duper Linux:gdb
Sistema lento? Perf in soccorso!
Super tutorial sul debug del sistema LinuxFantastici hack di Linux - dalla prima alla quarta parte - che collegano solo l'ultimo.
Ultimo ma non meno importante, il mio libro di problem solving!
Conclusione
Il controllo dello stato di salute è uno strumento molto utile e pratico. Non sostituisce strace o netstat o perf, ma può sicuramente aiutarti a ottenere un'istantanea multidimensionale molto accurata di qualsiasi cosa tu stia profilando. Questo è un ottimo primo passo che può indirizzarti nella giusta direzione. È quindi possibile selezionare un'utilità che esamini in modo specifico l'aspetto rilevante dell'esecuzione del software (forse Wireshark per la rete o Valgrind per la memoria). In un certo senso, questo rende il controllo della salute un gioco da ragazzi.
Hai bisogno di una certa comprensione di come funzionano i sistemi Linux e dell'applicazione che stai eseguendo. Ma anche se non si dispone di tale conoscenza, il controllo dello stato può essere utilizzato per studi comparativi e risoluzione dei problemi dei colli di bottiglia delle prestazioni. Se sai che qualcosa non sta funzionando come dovrebbe, puoi tracciarlo una volta su un sistema buono, una volta su un sistema cattivo (interessato) e quindi confrontare i due. I molti tipi di dati forniti da Healthcheck aiuteranno notevolmente a risolvere il problema. E questo ci porta alla fine di questo tutorial. Con un po' di fortuna, hai imparato qualcosa di nuovo ed è stata anche una corsa divertente. Abbi cura di te.