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

9

Я использую 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

введите описание изображения здесь

Соломенная шляпа
источник
1
99% IOwait с 0 чтения и записи диска выглядит не очень хорошо. Здесь serverfault.com/questions/426181/… упоминается, что ввод / вывод может быть связан не только с работой диска, но и с сетью. Не могли бы вы проверить это, например, с помощью iftop (и других инструментов)?
Андрей Сапегин
@AndreySapegin добавил iftop
Соломенная Шляпа
Я думаю, что проблема была с диском, на котором был развернут экземпляр AWS. Я создал AMI текущего экземпляра и запустил новый экземпляр, используя его. Теперь нет дополнительной нагрузки на ввод-вывод
Straw Hat
@StrawHat означает ли это, что вы думаете, что что-то не так с диском в вашем первом экземпляре?
sbrattla
@sbrattla Нет, я думаю. после нескольких дней выскочила та же проблема
Соломенная Шляпа

Ответы:

2

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

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

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

fgbreel
источник
перемещение mysql в экземпляр RDS будет работать?
Соломенная шляпа
1
Вроде, главная проблема в том, что из-за большого количества itens в очередь постфиксов, поедающих ваши iops, вы можете увидеть это qshape deferredкомандой.
fgbreel
postconf: warning: /etc/postfix/main.cf: unused parameter: virtual_mailbox_limit_maps=proxy:mysql:/etc/zpanel/configs/postfix/mysql-virtual_mailbox_limit_maps.cf
Соломенная шляпа
postconf: warning: /etc/postfix/master.cf: unused parameter: smtpd_bind_address=127.0.0.1получил эти ошибкиqshape deferred
соломенная шляпа
1
Я думаю, что ваш постфикс может быть неправильно настроен, но для вашей текущей проблемы, посмотрите, сколько писем у вас есть /var/lib/postfix/deferred. Переместите их в holdочередь для дальнейшего расследования или очистки.
fgbreel
1

Отредактировано после получения дополнительной информации, собранной с помощью 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около минуты и вставьте сюда вывод.
shodanshok
источник
iostat -x -k 5 2, а также добавлено в вопросе
Соломенная Шляпа
1

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

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

ojovirtual
источник
0

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

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

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

MrMajestyk
источник
-3

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

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

Сверхразум
источник
EC2 является платформой виртуализации и использует виртуальные диски. DMA в этом не виноват. В любом случае, шторм IRQ наносит ущерб процессору, а не диску.
Сёданшок
Да и IRQ означает прерывания.
Сверхразум
Я бы сказал, что EC2 настолько далек от подобных проблем. Ввод / вывод ограничен типом экземпляра - и, в конце концов, некоторым действительно дорогим решением SAN, которое имеет много возможностей.
MrMajestyk