Высокий 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, даже если есть другие процессы, готовые использовать ЦП для реальной обработки?

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

person Per Steffensen    schedule 21.02.2012    source источник
comment
Я вижу множество подобных вопросов здесь и там, но в этом вопросе на ServerFault есть кое-что, что можно попробовать в отношении аппаратных ошибок: serverfault.com/questions/83778/ Вот еще в том же духе, т.е. может тут ошибка условие, а также некоторые другие отладки вокруг проблемы: articledashboard.com/ Статья/Linux-and-High-I-O-Wait/959842   -  person Don Branson    schedule 21.02.2012
comment
Продолжая эту мысль... условия ошибки не являются вашей проблемой здесь, если предположить, что вы видите это на нескольких физических машинах, но инструменты в этих обсуждениях могут дать некоторые дополнительные сведения об ожиданиях. Сказав это, мне очень интересно, чтобы кто-то ответил на подробное объяснение того, как это работает, часть вашего вопроса.   -  person Don Branson    schedule 21.02.2012
comment
Вверху есть столбец состояния. Что он показывает, когда вы просматриваете темы на одном ящике? Можете ли вы предоставить top вывод? Результаты iostat -kd 1? Результаты free -o?   -  person ingyhere    schedule 22.02.2012
comment
Что ж, вы можете увидеть много вопросов, но я вижу все, кроме одного, как углубляющие вопросы и предлагаемые части ответов :-) Вопрос в том, какие условия во многих JVM на одной машине с Linux заставят ОС считать iowait (% wa вверху)   -  person Per Steffensen    schedule 22.02.2012


Ответы (1)


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

  • hdfs выполняет много обращений к диску, в результате чего доступ к другим дискам замедляется. (Может помочь проверка iostat -x, так как она покажет дополнительный столбец «%util», который указывает, какой процент времени диск «занят».)
  • У вас не хватает системной памяти под нагрузкой, и иногда вы погружаетесь в своп.
person Community    schedule 22.02.2012
comment
Спасибо за ответ. Я добавил вывод iostat -x в исходный пост. - person Per Steffensen; 22.02.2012
comment
Я знал, что считается ожиданием ввода-вывода со стороны ОС - непрерываемый ввод-вывод. Но это не дает понять, какие вещи в java-коде заставляют поток выполнять непрерывный ввод-вывод. Кроме того, JVM запускает несколько потоков, которые обычно не сопоставляются 1-1 с процессами ОС. Таким образом, один процесс ОС будет выполнять работу многих потоков JVM. Так как же потоки, выполняющие нецелевой ввод-вывод, транслируются в процесс, который считается выполняющим нецелевой ввод-вывод — когда все потоки выполняют нецелевой ввод-вывод или когда это делают некоторые потоки? Или же? В этом была суть вопроса. - person Per Steffensen; 22.02.2012
comment
Вывод iostat говорит о том, что ваши диски были заняты в среднем на 90% в то время, когда машина работала — они дают вам все, что у них есть. Время для более быстрых дисков! - person ; 22.02.2012
comment
Не сомневайся, сумраквафф. Или время для оптимизации потока, чтобы использовать гораздо меньше дискового ввода-вывода. - person Per Steffensen; 23.02.2012