Высоко загрузитесь из-за ввода-вывода, ожидают в Ubuntu 12.04 на экземпляре EC2
Я использую сервер Ubuntu 12.04, испытывая затруднения, находящие причину загрузки, я видел изменение в ответ время сервера с прошлой недели
после чтения Поиска и устранения неисправностей Linux, Первой части: Высокая Загрузка
Кажется, что нет никакой проблемы с ЦП и RAM, и эта загрузка может быть связана с загрузкой I/O-bound при помощи 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%I/O, Записи на диск I наблюдателей как 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, чтобы не касаться диска и следить за своей постфиксной очередью, у вас может быть много писем в очереди, чувствительной к вводу-выводу (т.е. отложенные, маленькие сообщения со случайным чтением поведение).
Ваша электронная почта использовалась как ретранслятор для спамеров.
Взгляните на документацию по постфиксу и ограничьте ретрансляционный доступ к вашему MTA.
Отредактировано после дополнительной информации, собранной с помощью iostat и iotop
Ваш диск загружен на 100%, так как на нем заканчиваются доступные IOPS: согласно iostat, у вас есть константа 50+ IOPS (85 Вт / с - 35 объединенных Вт / с). Экземпляры EC2, особенно дешевые, имеют жесткие ограничения на устойчивое количество операций ввода-вывода в секунду (в диапазоне 30-50 операций ввода-вывода в секунду).
Согласно новому выводу 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примерно на минуту и вставьте сюда результат.
Возможно, диск находится в режиме без DMA. Пожалуйста, проверьте статус DMA накопителя. (команда hdparm)
Если это не так, что-то еще может генерировать множество прерываний. Кто-нибудь помнит те из старых добрых времен DOS?
Немного поздно, но у меня была такая же проблема на аналогичной машине, и я обнаружил, что проблема заключалась в кучке поврежденных таблиц MySQL. Поскольку в некоторых из этих таблиц было много данных, они вызывали большое время ожидания ввода-вывода.
Посмотрите /var/log/mysql/error.log или используйте mysqlcheck для поиска и восстановления поврежденных данных.
Как указано выше, это вполне вероятно что ваш инстанс EC2 поставляется с ограничением ввода-вывода или, возможно, он поддерживается на томе Amazon EBS Standard, который просто не обеспечивает большого количества операций ввода-вывода. Посмотрите, что эта страница - на ней описаны различные типы томов, которые предлагает Amazon.
Даже если у вас медленный тип тома, вы все равно сможете писать на него достаточно быстро, но если ваша нагрузка является случайной по своей природе, как кажется, это может быть (материал SQL), вы можете захотеть повысить пропускную способность IOPS, поскольку это обычно устанавливает верхнюю границу производительности SQL.
Итак, судя по вашим числам, может показаться, что у вас могут закончиться IOPS при использовании стандартного хранилища. Купить более быстрое хранилище не так уж и дорого. Взгляните на это .