Ho un sistema concorrente con molte macchine/nodi coinvolti. Ogni macchina esegue diversi JVM facendo cose diverse. Si tratta di un'architettura "a strati" in cui ogni livello è costituito da molte JVM in esecuzione su tutte le macchine. Fondamentalmente il JVM dello strato superiore riceve input dall'esterno tramite file, analizza l'input e lo invia tanti piccoli record per "storage" nel layer-2. Layer-2 in realtà non persiste i dati stessi, ma in realtà lo persiste nello strato-3 (HBase e Solr) e HBase in realtà non lo mantiene da solo poiché lo invia a layer-four (HDFS) per la persistenza.Alto iowait con i processi java su linux
La maggior parte delle comunicazioni tra i livelli è sincronizzata, quindi ovviamente finisce in molti thread in attesa del completamento dei livelli inferiori. Ma mi aspetterei che quei thread in attesa fossero "gratuiti" rispetto all'utilizzo della CPU.
Tuttavia, vedo un iowait molto alto (% wa in alto) - qualcosa come 80-90% di iowait e solo il 10-20% di sys/usr. Il sistema sembra esausto - lento per accedere via ssh e lento a rispondere ai comandi, ecc
La mia domanda è se tutti quei fili JVM in attesa di strati più bassi per completare può causare questo? Non dovrebbe essere "libero" in attesa di risposte (prese). È importante in relazione a ciò, se i diversi livelli utilizzano il blocco o non blocco (NIO) io? Esattamente in quali situazioni Linux conta qualcosa come iowait (% wa in alto)? Quando tutti i thread in tutte le JVM sulle macchine si trovano in una situazione in cui sono in attesa (contando perché non c'è altro thread da eseguire per eseguire qualcosa di significativo nel frattempo)? Oppure i thread in attesa contano anche in% wa anche se ci sono altri processi pronti per utilizzare la CPU per l'elaborazione reale?
Vorrei davvero ottenere una spiegazione approfondita su come funziona e come interpretare questo alto% wa. All'inizio ho intuito che contava come% wa quando tutti i thread erano in attesa, ma che lì in realtà c'era molto spazio per fare di più, così ho cercato di aumentare il numero di thread aspettando di ottenere più throughput, ma ciò non accade . Quindi è un vero problema, non solo un problema "visivo" che guarda in alto.
L'output di seguito è preso da una macchina su cui sono in esecuzione solo HBase e HDFS. E 'su macchine con HBase e/o HDFS che il problema che mostrano (più chiaro)
--- jps ---
19498 DataNode
19690 HRegionServer
19327 SecondaryNameNode
---- typical top -------
top - 11:13:21 up 14 days, 18:20, 1 user, load average: 4.83, 4.50, 4.25
Tasks: 99 total, 1 running, 98 sleeping, 0 stopped, 0 zombie
Cpu(s): 14.1%us, 4.3%sy, 0.0%ni, 5.4%id, 74.8%wa, 0.0%hi, 1.3%si, 0.0%st
Mem: 7133800k total, 7099632k used, 34168k free, 55540k buffers
Swap: 487416k total, 248k used, 487168k free, 2076804k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND
19690 hbase 20 0 4629m 4.2g 9244 S 51 61.7 194:08.84 java
19498 hdfs 20 0 1030m 116m 9076 S 16 1.7 75:29.26 java
---- iostat -kd 1 ----
[email protected]:~# iostat -kd 1
Linux 2.6.32-29-server (edrxen1-2) 02/22/2012 _x86_64_ (2 CPU)
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
xvda 3.53 3.36 15.66 4279502 19973226
dm-0 319.44 6959.14 422.37 8876213913 538720280
dm-1 0.00 0.00 0.00 912 624
xvdb 229.03 6955.81 406.71 8871957888 518747772
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
xvda 0.00 0.00 0.00 0 0
dm-0 122.00 3852.00 0.00 3852 0
dm-1 0.00 0.00 0.00 0 0
xvdb 105.00 3252.00 0.00 3252 0
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
xvda 0.00 0.00 0.00 0 0
dm-0 57.00 1712.00 0.00 1712 0
dm-1 0.00 0.00 0.00 0 0
xvdb 78.00 2428.00 0.00 2428 0
--- iostat -x ---
Linux 2.6.32-29-server (edrxen1-2) 02/22/2012 _x86_64_ (2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
8.06 0.00 3.29 65.14 0.08 23.43
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
xvda 0.00 0.74 0.35 3.18 6.72 31.32 10.78 0.11 30.28 6.24 2.20
dm-0 0.00 0.00 213.15 106.59 13866.95 852.73 46.04 1.29 14.41 2.83 90.58
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 5.78 1.12 0.00
xvdb 0.07 86.97 212.73 15.69 13860.27 821.42 64.27 2.44 25.21 3.96 90.47
--- free -o ----
total used free shared buffers cached
Mem: 7133800 7099452 34348 0 55612 2082364
Swap: 487416 248 487168
Ho vedere una varietà di domanda simile qui e là, ma questo ServerFault ha alcune cose da provare errori hardware WRT: http://serverfault.com/questions/83778/finding-the-root- causa-of-100-iowait-in-linux Ecco un altro sulla stessa linea, cioè, c'è una condizione di errore, con qualche altro debug intorno al problema: http://www.articledashboard.com/Article/Linux -e-High-IO-Wait/959.842 –
Continuando quel pensiero ... le condizioni di errore non sono il problema qui, partendo dal presupposto che si sta vedendo questo su più macchine fisiche, ma gli strumenti a quelle discussioni potrebbero dare qualche dettaglio aggiuntivo sulla attende.Detto questo, sono molto interessato a qualcuno che risponda alla "spiegazione approfondita su come funziona" parte della tua domanda. –
C'è una colonna di stato in alto. Cosa mostra quando visualizzi i fili su una scatola? Puoi fornire un output 'top'? I risultati di 'iostat -kd 1'? I risultati di 'free -o'? – ingyhere