Высокая нагрузка из-за ожидания ввода-вывода в Ubuntu 12.04 на экземпляре EC2

Я использую Ubuntu server 12.04, не могу найти причину загрузки, я видел изменение времени отклика сервера с прошлой недели

после прочтения Устранение неполадок в Linux, часть I: высокая нагрузка

Кажется, что нет проблем с CPU и RAM, и эта нагрузка может быть связана с нагрузкой, связанной с вводом / выводом, с помощью topкоманды, которую я получил после вывода

Вот она 97.6%wa, ОЗУ свободна и не используется своп.

Ниже приведен вывод команды, iostatкоторая сеет, что есть89% iowait

ubuntu@ip-my-sys-ubuntu:~$ iostat
Linux 3.2.0-58-virtual (ip-172-31-6-203)    02/19/2015  _x86_64_    (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.05    0.01    3.64   89.50    3.76    0.03

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvdap1           69.91         3.81       964.37     978925  247942876

Я также использовал, iotopкоторый после фиксированного интервала показывает 99% ввода-вывода, диск пишет, что я наблюдатель как1266 KB/s

а также

Это плохо? как время отклика снижается. Чем это вызвано?

РЕДАКТИРОВАТЬ, которые просят другие

iftop O / P

                  12.5kb             25.0kb            37.5kb             50.0kb       62.5kb
└─────────────────┴──────────────────┴─────────────────┴──────────────────┴──────────────────
ip-12-1-1-111.ap-southeast-1.  => 115.231.218.130                      0b   2.04kb   522b
                                 <=                                      0b   1.53kb   393b
ip-112-1-1-111.ap-southeast-1.  => 62.snat-111-91-22.hns.net.in      1.52kb  1.52kb  1.72kb
                                 <=                                    208b    208b    262b
ip-112-1-1-111.ap-southeast-1.  => static-mum-120.63.141.177.mtnl.      0b    480b    240b
                                 <=                                      0b    350b    175b
ip-112-1-1-111.ap-southeast-1.  => ip-112-11-1-1.ap-southeast-1.co      0b    118b    178b
                                 <=                                      0b    210b    292b
ip-112-1-1-111.ap-southeast-1.  => static-mum-120.63.194.119.mtnl.      0b      0b    240b
                                 <=                                      0b      0b    175b

TX:             cum:    123kB   peak:   3.72kb               rates:   1.67kb  2.02kb  1.78kb
RX:                    51.5kB           4.88kb                        1.19kb   989b    918b
TOTAL:                  174kB           8.60kb                        2.86kb  2.98kb  2.68kb

вывод iostat -x -k 5 2

ubuntu@ip-111-11-1-111:~$ iostat -x -k 5 2
Linux 3.2.0-58-virtual (ip-111-11-1-111)        03/04/2015      _x86_64_        (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.75    0.01    4.74   22.72    4.06   64.71

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdap1            0.00   263.80    0.42  109.42     7.28  1572.36    28.76     1.92   17.52   17.57   17.52   2.31  25.39

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.97    0.00    4.77   76.34    9.92    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdap1            0.00    35.69    0.00   85.88     0.00   438.93    10.22   137.55 1612.71    0.00 1612.71  11.11  95.42

@shodanshok точка 2

iotop -a

Настройте службу mysql так, чтобы она не касалась диска и не выглядела в очереди постфиксов. Возможно, в очередь, чувствительную к вводу / выводу, может быть много писем (т. Е. Отложенные, небольшие itens со случайным поведением чтения).

Ваша система электронной почты использовалась в качестве реле для спамеров.

Посмотрите документацию postfix и ограничьте доступ к вашему MTA.

Отредактировано после получения дополнительной информации, собранной с помощью iostat и iotop.
Ваш диск загружен на 100%, так как на нем заканчиваются доступные IOPS: согласно iostat у вас есть постоянные 50+ IOPS (85 с / с 35 слияния / с). Экземпляры EC2, особенно дешевые, имеют сильные ограничения на длительные IOPS (в диапазоне 30-50 IOPS).

Согласно новому выводу iotop, mysql и bounce потребляют значительное количество IOPS. Однако вывод iotop кажется неполным или, по крайней мере, плохо отсортированным. Можете ли вы повторно запустить «iotop -a» сортировку один раз по IOPS, а другой раз по записи на диск?

Оригинальный ответ
Моя ставка: процесс "отказов" выдает много синхронизированных записей, которые душат виртуальное дисковое устройство, предлагаемое Amazon (кстати, какой профиль вы используете? Диски EC2 имеют довольно строгие правила для непрерывного ввода-вывода).

Во всяком случае, определить, что записывает пропускную способность ввода / вывода, может быть довольно сложно время от времени. Хотя iotop - очень хороший инструмент, иногда он не дает необходимой информации. Нам нужно идти глубже. Итак, следуйте этим советам:

1. Во-первых, нам нужно определить тип обрабатываемого ввода-вывода и задействованное блочное устройство.
   Пожалуйста , выполните следующую команду: iostat -x -k 5 2. Пожалуйста, сообщите оба набора результатов.
2. Затем нам нужно определить процессы, ожидающие ввода-вывода .
   Когда для этого можно использовать «top»: запустите его, нажмите shift + f (F), затем w, затем введите, затем shift + r (R). Первыми процессами будет процесс в состоянии D или D + (т. Е. Ожидание диска / сети). Пожалуйста, сообщите обратно список.
3. Используйте iotop, чтобы показать накопленные значения ввода / вывода для процессов .
   Запустите iotop -aоколо минуты и вставьте сюда вывод.

Немного поздно, но у меня была та же проблема на аналогичной машине, и я обнаружил, что проблема была в связке поврежденных таблиц MySQL. Поскольку в некоторых из этих таблиц было много данных, было много времени ожидания ввода-вывода.

Посмотрите /var/log/mysql/error.logили используйте, mysqlcheckчтобы найти и восстановить поврежденные данные.

Как указывалось выше, вполне вероятно, что ваш экземпляр EC2 поставляется с ограничением ввода-вывода или, может быть, он поддерживается на томе Amazon EBS Standard, который просто не обеспечивает большой объем ввода-вывода. Посмотрите, что эта страница - она ​​описывает различные типы томов, которые предлагает Amazon.

Даже если у вас медленный вид тома, вы все равно сможете писать на него достаточно быстро, но если ваша загрузка носит случайный характер, как это может быть (SQL), вы можете обновить IOPS емкость, так как это обычно ставит верхнюю границу производительности SQL.

Итак, из ваших номеров может показаться, что у вас закончились IOPS с использованием стандартного хранилища. Покупка более быстрого хранилища не так уж и дорога. Посмотрите на это .

Диск может быть в режиме не DMA. Пожалуйста, проверьте состояние DMA привода. (команда hdparm)

Если это не так, что-то еще может вызвать много прерываний. Кто-нибудь помнит те из старой доброй эпохи DOS?