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