Высокий iowait с процессами Java на Linux

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

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

Я вижу очень высокий iowait (% wa сверху) - что-то вроде 80-90% iowait и только 10-20% использования sys /usr ЦП. Система выглядит исчерпанной - медленная регистрация через 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 ----
[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
11 голосов | спросил Per Steffensen 21 FebruaryEurope/MoscowbTue, 21 Feb 2012 11:32:56 +0400000000amTue, 21 Feb 2012 11:32:56 +040012 2012, 11:32:56

1 ответ


0

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

  • hdfs выполняет много обращений к диску и в результате замедляет доступ к другим дискам. (Проверка iostat -x может помочь, так как в ней будет показан дополнительный столбец «% util», в котором указано, какой процент времени диска занят».)
  • Вам не хватает системной памяти под нагрузкой, и иногда вы погружаетесь в своп.
ответил duskwuff 22 FebruaryEurope/MoscowbWed, 22 Feb 2012 11:36:13 +0400000000amWed, 22 Feb 2012 11:36:13 +040012 2012, 11:36:13

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132