Высокая нагрузка из-за ожидания ввода-вывода в Ubuntu 12.04 на экземпляре EC2
Я использую Ubuntu server 12.04, не могу найти причину загрузки, я видел изменения в времени отклика сервера с прошлой недели
после прочтения Устранение неполадок в Linux, часть I: высокая нагрузка
Кажется, что нет проблем с ЦП и ОЗУ, и эта нагрузка может быть связана с нагрузкой, связанной с вводом-выводом, с помощью top Команда, которую я получил следующий вывод
Вот 97.6%wa, RAM свободна и не используется подкачка.
Ниже приведен вывод команды 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
5 ответов
Настройте службу 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 - очень хороший инструмент, иногда он не дает необходимой информации. Нам нужно идти глубже. Итак, следуйте этим советам:
- Во-первых, нам нужно определить тип обрабатываемого ввода-вывода и задействованное блочное устройство.
Пожалуйста, запустите следующую команду:iostat -x -k 5 2, Пожалуйста, сообщите оба набора результатов. - Затем нам нужно определить процессы, ожидающие ввода-вывода.
Когда для этого можно использовать "top": запустите его, нажмите shift+f (F), затем w, затем введите, затем shift+r (R). Первыми процессами будет процесс в состоянии D или D+ (т. Е. Ожидание диска / сети). Пожалуйста, сообщите обратно список. - Используйте iotop, чтобы показать накопленные значения ввода / вывода для процессов.
Бежатьiotop -aв течение минуты и вставьте сюда вывод.
Немного поздно, но у меня возникла та же проблема на аналогичной машине, и я обнаружил, что проблема в связке поврежденных таблиц MySQL. Поскольку в некоторых из этих таблиц было много данных, было много времени ожидания ввода-вывода.
смотреть на /var/log/mysql/error.log или использовать mysqlcheckнайти и восстановить поврежденные данные.
Как указывалось выше, вполне вероятно, что ваш экземпляр EC2 поставляется с ограничением ввода-вывода или, может быть, он поддерживается на томе Amazon EBS Standard, который просто не обеспечивает большой объем ввода-вывода. Посмотрите, что эта страница - она описывает различные типы томов, которые предлагает Amazon.
Даже если у вас медленный объем тома, вы все равно сможете писать на него достаточно быстро, но если ваша загрузка носит случайный характер, как это может быть (SQL), вы можете обновить IOPS емкость, так как это обычно ставит верхнюю границу производительности SQL.
Итак, из ваших номеров может показаться, что у вас закончились IOPS с использованием стандартного хранилища. Покупка более быстрого хранилища не так уж и дорога. Посмотрите на это.
Диск может быть в режиме не DMA. Пожалуйста, проверьте состояние DMA привода. (команда hdparm)
Если это не так, что-то еще может генерировать много прерываний. Кто-нибудь помнит те из старой доброй эпохи DOS?