Tengo un sistema simultáneo con muchas máquinas/nodos involucrados. Cada máquina ejecuta varias JVM haciendo cosas diferentes. Es una arquitectura "estratificada" en la que cada capa consta de muchas JVM que se ejecutan en las máquinas. Básicamente, la JVM de capa superior recibe entrada desde el exterior a través de archivos, analiza la entrada y le envía tantos registros pequeños para "almacenamiento" en la capa dos. La capa dos en realidad no persiste en los datos en sí, pero en realidad persiste en la capa tres (HBase y Solr) y HBase en realidad no persiste tampoco, ya que lo envía a la capa cuatro (HDFS) para persistencia.Alto iowait con procesos java en Linux
mayor parte de la comunicación entre las capas se sincroniza así que por supuesto que termina en una gran cantidad de subprocesos en espera para las capas inferiores para completar. Pero esperaría que aquellos que esperan subprocesos sean "libres" del uso de la CPU.
Veo una muy alta iowait (% wa en la parte superior), aunque - algo así como 80-90% iowait y sólo sys uso de la CPU 10-20%/usr. El sistema parece agotado - lentos para iniciar sesión a través de ssh y lento para responder a los comandos etc.
Mi pregunta es si todos esos hilos de JVM en espera de capas inferiores para completar pueden causar esto? ¿No se supone que es "libre" esperando respuestas (sockets)? ¿Importa con respecto a esto, si las diferentes capas usan bloqueo o no bloqueo (NIO) io? Exactamente en qué situaciones Linux cuenta algo como iowait (% wa en la parte superior)? Cuando todos los hilos en todas las JVM en las máquinas se encuentran en una situación en la que están esperando (contando porque no hay otro hilo que ejecutar para hacer algo significativo mientras tanto)? ¿O los hilos en espera también cuentan en% wa a pesar de que hay otros procesos listos para usar la CPU para el procesamiento real?
yo realmente desee obtener una explicación completa de cómo funciona y cómo interpretar este alto wa%. Al principio supuse que contaba como% wa cuando todos los subprocesos estaban esperando, pero que en realidad había mucho espacio para hacer más, así que traté de aumentar el número de subprocesos que esperaban obtener más rendimiento, pero eso no sucede. . Entonces, es un problema real, no solo un problema "visual" que mira hacia arriba.
El siguiente resultado se toma de una máquina donde solo se ejecutan HBase y HDFS. Es en máquinas con HBase y/o HDFS que el problema que muestran (con mayor claridad)
--- 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
que ver una variedad de pregunta similar aquí y allá, pero éste en ServerFault tiene algunas cosas para tratar errores de hardware WRT: http://serverfault.com/questions/83778/finding-the-root- las causas de 100 iowait-en-linux Aquí hay otro en el mismo sentido, es decir, tal vez hay una condición de error, con algún otro depuración en torno al tema: http://www.articledashboard.com/Article/Linux -y-Alto-IO-Wait/959842 –
Continuando con ese pensamiento ... las condiciones de error no son su problema aquí, suponiendo que esté viendo esto en varias máquinas físicas, pero las herramientas en esas discusiones podrían dar algunos detalles adicionales sobre la murga.Habiendo dicho eso, estoy muy interesado en que alguien responda a la "explicación completa de cómo funciona", parte de su pregunta. –
Hay una columna de estado en la parte superior. ¿Qué muestra cuando ves los hilos en una caja? ¿Puedes proporcionar un resultado 'superior'? Los resultados de 'iostat -kd 1'? Los resultados de 'free -o'? – ingyhere