Мы используем munin и monit, чтобы отслеживать общую статистику наших vps, за последние пару недель мы столкнулись с проблемами, когда случайный всплеск ожидания ввода-вывода убивает производительность нашего сервера.
С тех пор мы проверяли cron на предмет возможных подозрений, но не нашли ни одной, которая соответствовала бы шаблонам спайков. Прибытие вовремя, чтобы проверить ps aux застаревший процесс не всегда возможен, а результат может измениться даже во время мероприятия.
Поэтому мне интересно, есть ли лучший способ настроить пассивный мониторинг, предпочтительно через munin / monit, который отслеживает процессы, которые испытывают / вызывают больше всего ожидания ввода-вывода?
(PS: я использовал некоторые из предложений в этом вопросе и ответе, но пока не смогли определить причину.)
Не может быть обработать это вызывает это. Более вероятна проблема подсистемы ввода-вывода или конфликта ресурсов. Я бы не стал искать отдельный процесс или группу процессов, которые вызывают это. Я бы отметил условия, при которых это происходит.
Есть ли у вас полные спецификации вашего сервера, включая детали настройки диска? Пожалуйста, разместите их вместе с версией / ядром ОС - uname -a
редактировать -
Полагаю, это VPS. Позвоните или напишите в службу поддержки вашего провайдера. Покажите им график и объясните свою ситуацию.
Возможно, вы захотите использовать учет процессов Linux. Если он включен в ваше ядро (я не уверен в текущем состоянии), вы можете включить его с помощью accton. Команда sa будет сообщать следующие данные по каждому процессу:
cpu - sum of system and user time in cpu seconds
re - "real time" in cpu seconds
k - cpu-time averaged core usage, in 1k units
avio - average number of I/O operations per execution
tio - total number of I/O operations
k*sec - cpu storage integral (kilo-core seconds)
u - user cpu time in cpu seconds
s - system time in cpu seconds
Вас может заинтересовать avio и tio ценности процессов.
В Руководство по бухгалтерским утилитам GNU так же хорошо как Включение учета процессов в Linux HOWTO дает более подробную информацию.
Возможно, вы превышаете лимит vps:
Даже если вы поймали процессы с высокими значениями io, возможно, это будет общий apache-php или другой процесс, связанный с веб-сайтом. Но этого недостаточно, вам понадобится фактический URL-адрес. И когда вы найдете URL-адрес, он НЕ будет причиной проблемы io, он будет ее жертвой. Большинству cms требуется ~ 1000 файлов для запуска, и любая проблема с жестким диском или кешем приведет к огромным всплескам io. Фактическая причина io может быть связана с какой-то другой учетной записью vps, или вы достигли пределов vps. Превышение лимитов vps действительно вызывает всплески io с учетом имеющихся ограничений.
Другие учетные записи или машинные процессы, зависящие от vps:
Вы можете подумать о смене провайдера!
У меня была похожая проблема, я потратил недели, пытаясь ее диагностировать, затем обменивался сообщениями с глухой бюрократической службой поддержки, и, наконец, мне это надоело, и я сменил хоста. Теперь все внезапно стало хорошо и уже год было хорошо! Что произошло? Тот же размер vps, тот же код, даже более медленная машина, даже более загруженный сайт, и все гладко.
В то время я предполагал, что какая-то другая учетная запись, занимающая жесткий диск, с огромной ежедневной резервной копией форума, нашла это через Google. Моим другим предположением было какое-то неэффективное программное обеспечение для резервного копирования серверов. Не знаю. Сходство с вашей ситуацией было в том, что это началось в определенный день и было довольно периодическим, и практически не было изменений в моем коде vps или в самой загрузке. Вы не можете ни поймать, ни доказать это с помощью программного обеспечения для мониторинга, ограниченного стенами vps.
Это было год назад. В настоящее время вокруг появились новые головные боли.
Дампы керна: Это новая мода, выгрузка ядра вместо регистрации ошибок. Истерия серверов. Когда что-то идет не так, сервер начинает дамп памяти 200M файла, и это поддерживает высокий io, поэтому другие вещи в цепочке идут не так, и вы получаете 3-5 файлов по 200M, сохраненных в самое загруженное время дня, останавливая hdd.
процессор изображений Imagick: По какой-то причине imagick начал работать с временными файлами 1G-50G. Если это произойдет, он заглохнет. Я подозреваю, что Мунин использует Imagick, какая ирония.
Еще одно практическое предложение: Держите munin открытым в окне, пока вы работаете над чем-то другим. Он автоматически обновляется каждые 5 минут. Так вы поймаете шип. Раньше я ловил такие шипы. Ваш спайк длится около 30 минут. Вы легко можете его поймать. Затем вы можете сделать ps aux и т. Д.