Quando si tratta di risolvere un problema di prestazioni su Linux, è molto importante conoscere le basi di vari output di comandi come uptime, vmstat. In questo post, cercheremo di comprendere le medie di carico e di eseguire la coda/coda bloccata in termini di utilizzo della CPU. Per prima cosa, capiamo cos'è la media del carico:
La media del carico è il numero di lavori nella coda di esecuzione (stato R) o in attesa di I/O su disco (stato D) con una media di 1, 5 e 15 minuti. Esempio di output dal comando uptime/top:
# uptime 11:49:14 up 25 days, 5:56, 68 users, load average: 0.03, 0.13, 0.47
# top -b -n 1 top - 11:49:34 up 25 days, 5:56, 68 users, load average: 0.09, 0.14, 0.46 Tasks: 456 total, 1 running, 445 sleeping, 10 stopped, 0 zombie Cpu(s): 0.8%us, 0.4%sy, 0.0%ni, 98.6%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 141823788k total, 140483388k used, 1340400k free, 313452k buffers Swap: 16772092k total, 0k used, 16772092k free, 134695384k cached
La regola pratica è:
- Sistema Single Core – se la media del carico è 1.00 significa che il sistema è completamente utilizzato e se ci saranno più attività in arrivo saranno in coda e attenderanno l'esecuzione.
- Sistema Single Core – se il carico medio è 2,00 significa che il sistema è già utilizzato e alcune attività sono già in coda e in attesa di esecuzione.
- Sistema multicore (4 core) – se il carico medio è 1,00 significa che il sistema utilizza 1/4 delle sue capacità della CPU, un'attività è attivamente in esecuzione e ci sono ancora 3 core in fase di "inattività".
- Sistema multicore (4 core) – se il carico medio è 4,00 significa che il sistema utilizza tutti e 4 i core e indica che il sistema è completamente utilizzato.
C'è ancora spazio per la testa nei casi precedenti? – normalmente no – se il carico medio è vicino al numero di core sul sistema – il sistema operativo dovrebbe essere rivisto per cercare il collo di bottiglia effettivo e l'ottimizzazione mancante o forse il sistema operativo non è stato ridimensionato correttamente per svolgere qualsiasi attività APP/DB.
Come viene calcolato il valore medio del carico sul sistema operativo attivo? – per questo dobbiamo trovare la coda di esecuzione che è disponibile tramite il comando vmstat:
Sistema inattivo (sistema a 8 core)
# vmstat 1 6 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 1674516 316588 134364752 0 0 0 1 0 0 1 0 99 0 0 0 0 0 1674624 316588 134364752 0 0 0 0 195 307 0 0 100 0 0 0 0 0 1674624 316596 134364752 0 0 0 12 168 302 0 0 100 0 0 0 0 0 1674624 316596 134364752 0 0 0 0 198 331 0 0 100 0 0 0 0 0 1674624 316596 134364752 0 0 0 0 206 356 0 0 100 0 0 0 0 0 1674624 316600 134364736 0 0 0 12 197 333 0 0 100 0 0
Sistema attivo (sistema a 8 core)
# vmstat 1 6 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 5 0 0 1674516 316588 134364752 0 0 0 1 0 0 1 0 99 0 0 7 0 0 1674624 316588 134364752 0 0 0 0 195 307 0 0 100 0 0 2 0 0 1674624 316596 134364752 0 0 0 12 168 302 0 0 100 0 0 6 0 0 1674624 316596 134364752 0 0 0 0 198 331 0 0 100 0 0 1 0 0 1674624 316596 134364752 0 0 0 0 206 356 0 0 100 0 0 8 0 0 1674624 316600 134364736 0 0 0 12 197 333 0 0 100 0 0
Gli output sopra sono un esempio:il primo mostra che la coda di esecuzione corrente (r) è 0 dove sul sistema attivo la coda di esecuzione salta da 1 a 8 in 6 sonde.
Cos'è esattamente la coda di esecuzione?
coda di esecuzione :numero di processi attivi (in esecuzione) e in coda.
Nel secondo esempio, quando il sistema è attivo, vediamo una coda di esecuzione di 8:questo è già il limite massimo massimo che dovrebbe essere eseguito dal sistema con 8 core. Ovviamente, la coda di esecuzione potrebbe mostrare valori come 36 o addirittura 101:andranno benissimo se sul primo 36 abbiamo 36 core e sul secondo 101 abbiamo più di 101 core.
La colonna della coda di esecuzione dovrebbe essere sempre inferiore/uguale al numero di core installati sul sistema – ovviamente la coda di esecuzione di 100 può essere visibile su un sistema con solo 8 core – significherà che 8 processi sono attivamente serviti dalla CPU e gli altri 92 sono in coda e in attesa di esecuzione. Se la coda di esecuzione è al di sopra dei core della CPU installati, l'indagine dovrebbe essere eseguita in termini di controllo delle prestazioni di APP/DB e ottimizzazione mancante o può indicare che il sistema non è stato ampliato correttamente per servire tale coda di esecuzione/carico.
Proprio come la coda di esecuzione media del carico dovrebbe rimanere al di sotto del numero di core installati:non mantenere questo valore al di sotto della soglia massima causerà rallentamento/blocco o sfratto (se il sistema è abilitato ad HA) poiché il sistema operativo può semplicemente mettere in coda il monitoraggio dell'heartbeat su disco/rete strato mentre è impegnato a svolgere altri compiti. Una media di carico elevata e una coda di esecuzione causeranno un arresto anomalo improvviso/caso sospeso:vale la pena monitorare entrambi i valori attivamente tramite strumenti di monitoraggio di terze parti e avvisare quando la coda di esecuzione/la media di carico occupano più del 70% delle risorse effettive della CPU.
La seconda colonna importante che viene presa anche da Load Average è lo stato "b" in vmstat che spiega i processi di stato bloccato - questo può essere facilmente interpretato come processi di stato D (in attesa che l'IO back-end finisca - di solito l'attività di archiviazione). Se il carico medio è alto e nessun processo è in esecuzione attivamente e vmstat mostra un valore di stato "b" anomalo, è il momento di rivedere le prestazioni della SAN o la verifica di qualsiasi componente del sistema operativo come ISCSI/NFS/NIC/HBA che potrebbe riscontrare alcuni problemi e portare a grave stato bloccato sotto Linux. Ad esempio, il server NFS potrebbe essere occupato a livello di CPU e tutti i processi/attività client (Linux) verranno accodati nello stato-d ( b ) portando all'"accodamento" che potrebbe quindi rilasciare una coda di esecuzione massiccia in seguito, poiché tutti i processi erano in attesa che l'IO back-end finisca più tardi, potrebbero nuovamente passare a In esecuzione portando a una coda di esecuzione massiccia che può causare uno stato di blocco/panico o portare a un caso di sfratto in seguito.
Anche il throughput di rete e il traffico TCP/UDP subiranno un impatto a causa dell'elevata media di carico, poiché il sistema sarà semplicemente impegnato a svolgere altre attività oltre a confermare le connessioni in entrata/uscita e a dare priorità al traffico di I/O di rete in ingresso tramite NFS/ISCSI ecc. In alcuni casi potrebbe mostrare TOP su %CPU valore superiore a 100 questo va perfettamente bene poiché il comando TOP per impostazione predefinita in Linux mostra operazioni single core, quindi nelle configurazioni multi-core il valore %CPU può essere maggiore del 100%. Ad esempio, se il PID utilizza completamente 4 core, il valore %CPU mostrerà 400
# top top - 11:49:34 up 25 days, 5:56, 68 users, load average: 0.09, 0.14, 0.46 Tasks: 456 total, 1 running, 445 sleeping, 10 stopped, 0 zombie Cpu(s): 0.8%us, 0.4%sy, 0.0%ni, 98.6%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 141823788k total, 140483388k used, 1340400k free, 313452k buffers Swap: 16772092k total, 0k used, 16772092k free, 134695384k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1438 java 20 0 945m 4220 2528 S 400.5 0.0 56:31.95 java <---
Informazioni sulla %CPU:
## %CPU -- CPU Usage The task's share of the elapsed CPU time since the last screen update, expressed as a percentage of total CPU time. In a true SMP environment, if a process is multi-threaded and top is not operating in Threads mode, amounts greater than 100% may be reported. You toggle Threads mode with the 'H' interactive command. ##
Per elencare rapidamente i processi in esecuzione/bloccati, utilizzare il comando ps di seguito:
# ps r -Af
Per elencare i thread dei processi per verificare se alcuni thread generati dal PID padre non stanno causando problemi di picco della CPU, eseguire:
# ps -e -To pid,ppid,state,pcpu,command
o
# ps -elfL
Inoltre, per verificare se le CPU del sistema operativo stanno servendo attivamente lo spazio utente ( USA ) usa gli esempi di comando seguenti:
# sar -P ALL 1 Linux 3.8.13-118.13.3.el6uek.x86_64 (lgeeklab) 01/08/2017 _x86_64_ (8 CPU) 02:40:38 PM CPU %user %nice %system %iowait %steal %idle 02:40:39 PM all 12.62 0.00 0.12 6.88 0.00 80.38 02:40:39 PM 0 0.00 0.00 0.00 54.55 0.00 45.45 02:40:39 PM 1 0.00 0.00 0.00 0.00 0.00 100.00 02:40:39 PM 2 0.99 0.00 0.00 0.00 0.00 99.01 02:40:39 PM 3 0.00 0.00 0.00 0.00 0.00 100.00 02:40:39 PM 4 100.00 0.00 0.00 0.00 0.00 0.00 02:40:39 PM 5 0.98 0.00 0.98 0.00 0.00 98.04 02:40:39 PM 6 0.00 0.00 0.00 0.00 0.00 100.00 02:40:39 PM 7 0.00 0.00 0.00 0.00 0.00 100.00 Average: CPU %user %nice %system %iowait %steal %idle Average: all 12.63 0.00 0.13 6.00 0.00 81.24 Average: 0 0.00 0.00 0.00 45.23 0.00 54.77 Average: 1 0.50 0.00 0.00 3.00 0.00 96.50 Average: 2 0.50 0.00 0.00 0.00 0.00 99.50 Average: 3 0.00 0.00 0.00 0.50 0.00 99.50 Average: 4 100.00 0.00 0.00 0.00 0.00 0.00 Average: 5 0.50 0.00 0.50 0.00 0.00 99.00 Average: 6 0.00 0.00 0.00 0.00 0.00 100.00 Average: 7 0.00 0.00 0.00 0.00 0.00 100.00
# mpstat -P ALL Linux 3.8.13-118.13.3.el6uek.x86_64 (geeklab) 01/08/2017 _x86_64_ (8 CPU) 02:41:26 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 02:41:26 PM all 0.79 0.00 0.10 1.18 0.00 0.02 0.00 0.00 97.92 02:41:26 PM 0 0.94 0.00 0.14 2.84 0.00 0.02 0.00 0.00 96.06 02:41:26 PM 1 0.94 0.00 0.14 2.70 0.00 0.02 0.00 0.00 96.20 02:41:26 PM 2 0.93 0.00 0.14 1.13 0.00 0.03 0.00 0.00 97.77 02:41:26 PM 3 0.94 0.00 0.13 2.71 0.00 0.02 0.00 0.00 96.20 02:41:26 PM 4 0.65 0.00 0.06 0.01 0.00 0.01 0.00 0.00 99.28 02:41:26 PM 5 0.65 0.00 0.06 0.01 0.00 0.01 0.00 0.00 99.27 02:41:26 PM 6 0.65 0.00 0.06 0.01 0.00 0.01 0.00 0.00 99.27 02:41:26 PM 7 0.64 0.00 0.05 0.01 0.00 0.01 0.00 0.00 99.29
Inoltre, le opzioni di comando TOP sottostanti possono essere utilizzate per ottenere informazioni sul thread PID e anche quale core ha servito il PID l'ultima volta:
Per mostrare i thread in TOP:
# top -H
Per mostrare quale PID principale servito l'ultima volta, eseguire:
# top
Quindi premi 'F ' e premi 'J ' e premi invio per ottenere l'output sotto dove 'P La riga ' sarà l'ultima CPU utilizzata.
Tasks: 1045 total, 2 running, 1043 sleeping, 0 stopped, 0 zombie Cpu(s): 0.2%us, 0.2%sy, 0.0%ni, 93.6%id, 5.9%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 16159656k total, 15349888k used, 809768k free, 597960k buffers Swap: 8232956k total, 218784k used, 8014172k free, 9840192k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P COMMAND 10428 root 20 0 15228 2228 1724 S 0.7 0.0 0:26.86 2 top 10838 oracle 20 0 4921m 585m 5708 S 0.7 3.7 137:11.13 3 mysqld 15360 root 20 0 15888 2792 1724 R 0.7 0.0 0:00.55 6 top 528 root 20 0 0 0 0 S 0.3 0.0 76:39.23 0 jbd2/dm-0-8 9003 root 20 0 0 0 0 S 0.3 0.0 8:49.33 2 jbd2/dm-3-8 10815 oracle 20 0 4921m 585m 5708 S 0.3 3.7 13:35.18 1 mysqld 14902 oracle 20 0 9431m 2.4g 28m S 0.3 15.5 19:54.77 3 java 15021 oracle 20 0 9431m 2.4g 28m S 0.3 15.5 20:09.19 1 java 15094 oracle 20 0 9431m 2.4g 28m S 0.3 15.5 6:54.88 3 java 32045 enduser 20 0 15228 2220 1724 S 0.3 0.0 9:32.73 5 top 32278 root 20 0 15228 2212 1724 S 0.3 0.0 9:32.96 1 top
Domande frequenti
Il sistema dovrebbe funzionare con un limite superiore come 8 processi in esecuzione con una media di carico allo stesso valore su un sistema a 8 core?
Risposta - No
Il sistema dovrebbe essere ridimensionato correttamente e non superare il 70% delle sue possibilità, quindi c'è un po' di spazio per l'esecuzione di nuove attività, questo è particolarmente importante per i server abilitati HA e per i sistemi in cui sono presenti qualsiasi fascia alta Componenti di I/O/rete che potrebbero essere accidentalmente accodati dal sistema operativo attivo. Per questo controllo approfondito dovrebbe essere eseguito dal team APP/DB per verificare cosa è esattamente in esecuzione attivamente sotto il sistema operativo.
Solo le attività APP/DB causano code di esecuzione elevate/media di carico
Risposta - No
Alcune attività del sistema operativo potrebbero causare una coda di esecuzione elevata o un carico medio, ma questi sono casi davvero rari. In questo caso, il comando top sarà utile per monitorare i valori US /SY / NI / ID / WA / HI / SI / ST e concentrarsi sulla sezione SY (System) che indica quanto tempo del processore impiega a livello di kernel. Assicurati che sia sempre inferiore all'utilizzo effettivo degli Stati Uniti (Utente) e che SY non stia, ad esempio, utilizzando il 20-30% della CPU (dipende dalla configurazione della CPU e dal caso effettivo).
Ad esempio, %SY alto potrebbe essere visibile durante le operazioni di I/O/rete alta o durante i casi di carenza di memoria - il processo di esempio è:kjorunald. %SY elevato potrebbe essere visibile anche durante carichi di sistema pesanti, ad esempio, coda di esecuzione elevata o coda bloccata causata da attività APP/DB, per lo più si osserva che %SY sarà intorno al 20-30% dove %US sarà essere molto più alto.
Una %SY più alta non significa sempre che ci sia un problema con il kernel o con il sistema operativo - ad esempio, potrebbe esserci del codice dell'applicazione/del database che sta causando molte chiamate di sistema attorno a specifiche funzioni del kernel - per eseguire il debug di questo ulteriore strace o perf dovrebbe essere usato per verificare l'interazione PID specifica.
Significa che single core può servire solo un'attività di processo singola alla volta?
Risposta - Sì/No
Le CPU sono progettate per il multitasking - anche con sistemi single core gli utenti possono comunque eseguire più attività e avviare più applicazioni - nella configurazione single core viene utilizzato il "time-slicing" che consente di eseguire attività per un certo periodo di tempo mentre altre attività attenderanno di essere eseguito (questo può accadere un paio di volte al secondo).
I sistemi moderni utilizzeranno funzionalità multicore/multithreading per rendere meno visibile questo impatto di commutazione, quindi su Enterprise Systems gli utenti hanno una configurazione multi-core in cui le applicazioni possono creare thread più piccoli che realizzeranno operazioni multitasking effettive (ogni core può svolgere attività diverse) portando a molto di più meno carico medio sul sistema e coda di attività più bassa - Ad esempio, il sistema dual core può dividere applicazioni/thread/attività in due core separati consentendo al core di cambiare solo la metà delle attività rispetto al sistema single core causando un impatto molto minore sulle prestazioni del sistema.