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