Подтвердить что ты не робот

Высокий iowait с java-процессами на linux

У меня есть параллельная система со многими задействованными машинами/узлами. Каждая машина запускает несколько JVM, которые делают разные вещи. Это "многоуровневая" архитектура, где каждый слой состоит из множества JVM, работающих по машинам. В основном, JVM верхнего уровня получает вход извне через файлы, анализирует ввод и отправляет ему столько маленьких записей для "хранения" в слое-два. Layer-two фактически не сохраняет данные, но на самом деле сохраняет их в слое-три (HBase и Solr), и HBase фактически не сохраняет его сам, поскольку он отправляет его на уровень 4 (HDFS) для сохранения.

Большая часть связи между слоями синхронизируется, поэтому, конечно, она заканчивается множеством потоков, ожидающих завершения нижних уровней. Но я ожидаю, что эти ожидающие потоки будут "свободными" от использования ЦП.

Я вижу очень высокий iowait (% wa наверху), хотя - что-то вроде 80-90% iowait и всего лишь 10-20% использования sys/usr CPU. Система кажется исчерпанной - медленный вход в систему через ssh и медленный ответ на команды и т.д.

Мой вопрос в том, может ли это привести все эти потоки JVM, ожидающие завершения нижних уровней? Не предполагается ли это "свободным" ожиданием ответов (сокетов). Имеет ли значение в отношении этого, используют ли разные слои блокировку или неблокирование (NIO) io? Точно в каких ситуациях Linux считает что-то как iowait (% wa наверху)? Когда все потоки во всех JVM на машинах находятся в ситуации, когда они ожидают (считая, потому что нет другого потока для выполнения чего-то значимого в то же время)? Или ожидание потоков также подсчитывается в% wa, хотя есть другие процессы, готовые использовать CPU для реальной обработки?

Я бы очень хотел получить подробное объяснение того, как это работает и как интерпретировать этот высокий% ва. Вначале я догадался, что он считается% 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 ----
[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
4b9b3361

Ответ 1

Ожидание IO в Linux указывает на то, что процессы блокируются для бесперебойного ввода-вывода. На практике это обычно означает, что процесс выполняет доступ к диску - в этом случае я бы предположил одно из следующего:

  • hdfs выполняет множество операций с доступом к диску, что приводит к замедлению процесса доступа к диску. (Проверка iostat -x может помочь, поскольку в нем будет показан дополнительный столбец "% util", который указывает, какой процент от времени "занят" на диске.)
  • Вы теряете системную память под нагрузкой и иногда окунаетесь в swap.