High iowait с процессами java на linux
У меня есть параллельная система со многими машинами/узлами. На каждой машине запущено несколько JVM, выполняющих разные задачи. Это "слоистая" архитектура, где каждый слой состоит из множества JVM, работающих на разных машинах. В основном, JVM верхнего уровня получает входные данные извне через файлы, анализирует их и отправляет в виде множества небольших записей для "хранения" на втором уровне. Второй уровень не хранит сами данные, а сохраняет их на третьем уровне (HBase и Solr), а HBase фактически не хранит их самостоятельно, поскольку отправляет их на четвертый уровень (HDFS) для сохранения.
Большинство коммуникаций между уровнями синхронизированы, поэтому, конечно, в итоге возникает множество потоков, ожидающих завершения работы нижних уровней. Но я бы ожидал, что эти ожидающие потоки будут "свободными" с точки зрения использования процессора.
Однако я вижу очень высокий iowait (%wa в верхней части) - что-то около 80-90% iowait и только 10-20% использования процессора sys/usr. Система кажется истощенной - медленно входит в систему через ssh, медленно отвечает на команды и т.д.
Мой вопрос в том, могут ли все эти потоки JVM, ожидающие завершения нижних уровней, вызвать это? Не должны ли они быть "свободными", ожидая ответов (сокетов). Имеет ли значение для этого, используют ли различные уровни блокирующий или неблокирующий (NIO) ио? В каких именно ситуациях Linux считает что-то iowait (%wa в топе)? Когда все потоки во всех JVM на машинах находятся в ситуации ожидания (подсчитывается, потому что нет другого потока, который можно запустить, чтобы сделать что-то значимое за это время)? Или ожидание потоков также учитывается в %wa, даже если есть другие процессы, готовые использовать CPU для реальной обработки?
Я бы очень хотел получить подробное объяснение того, как это работает и как интерпретировать этот высокий %wa. В начале я предполагал, что %wa считается, когда все потоки ждут, но на самом деле есть много места для выполнения большего, поэтому я пытался увеличить количество потоков, ожидая получить большую пропускную способность, но этого не происходит. Значит, это реальная проблема, а не просто "визуальная" проблема, если посмотреть сверху.
Приведенный ниже результат получен на машине, где запущены только HBase и HDFS. Именно на машинах с HBase и/или HDFS проблема проявляется (наиболее четко)
--- 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 ----
root@edrxen1-2:~# 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