Назад | Перейти на главную страницу

Приложение становится ОЧЕНЬ медленным только утром: инструменты для отслеживания виновника?

У меня есть два сервера Ubuntu: один действует как сервер db (mysql), файловый сервер и сервер приложений. Используя эти три сервиса, приложение работает безупречно в течение нескольких месяцев.

Теперь мы выяснили, что КАЖДОЕ утро около 7:45 действительно замедляется. Через час все снова становится быстрым и можно использовать без вмешательства человека. Я пытаюсь разобраться в проблеме ...

Есть ли какой-либо инструмент для мониторинга и регистрации использования процессора, оперативной памяти, диска, сети? Как мне быстро найти проблему?

Быстрое решение - изолировать проблему и найти виновника.
Проверьте, какие cronjobs выполняются в это время, и перенесите их на другое время.
Если вы можете себе это позволить, отключите на это время сеть.
Если проблема не устранена, отключите все ненужные службы.
Правильный способ - это посмотреть на данные, которые вы уже собрали как часть процесса. Как уже было сказано, существует множество вариантов того, как это сделать. Мы используем систему построения графиков Cacti, поскольку это дает хорошее визуальное представление, и вы можете график практически все.

я нахожу sar хорошо указывает на вероятные причины медлительности. Установите atsar пакет в обеих системах. После того, как он проработает в течение дня, у вас должны быть данные, чтобы увидеть, какие ресурсы интенсивно используются, когда система работает медленно. Данные будут собираться в /var/log/atsar который в конечном итоге будет иметь 31 ежедневный файл. Это отличный инструмент для изучения проблем с нагрузкой.

я нахожу munin быть хорошим инструментом для общего мониторинга серверов. Я стараюсь не запускать munin сервер в системе, которая может быть перегружена. В вашем случае вы хотите, чтобы третий хост выступал в качестве сервера. munin собирает данные от каждого клиента каждые пять минут. Затем эти данные преобразуются в графики. По графикам достаточно легко увидеть, какой ресурс наиболее загружен. Это может помочь ускорить расследование с помощью sar.

Для быстрой проверки просто войдите на каждый сервер и запускайте его во время проблемного периода. Чтобы узнать, как выглядит нормальная нагрузка, полезно запустить его раньше. Если ваша средняя нагрузка превышает количество ядер на сервере в течение длительного периода времени, вы, вероятно, определили сервер, который вызывает замедление. Верхние строки могут использоваться, чтобы определить, является ли это ЦП (высокий процент пользователя) или какой-либо другой ресурс (высокий процент системы или высокий процент ожидания). Вы также получите представление об использовании памяти.

Пакет технологического учета acct может сказать вам, какие процессы выполняются в течение периода. Вам нужно будет бежать accton on для включения учета процессов. Команда dump-acct можно запустить, чтобы выгрузить данные в читаемом формате. man dump-acct включает информацию о формате вывода. Вероятно, вам нужны процессы, которые начинаются около 7:45.

Есть ли какой-либо инструмент для мониторинга и регистрации использования процессора, оперативной памяти, диска, сети?

Вы не поверите, сколько инструментов доступно. Я использую Nagios, sar, iotop, top, ps, mrtg и множество пользовательских скриптов. Но они просто скажут вам, насколько медленная система, а не Зачем это медленно.

Есть множество причин, по которым это может быть медленным - как вещи, происходящие на машине (например, резервное копирование, вызывающее сброс кеша, пакетная обработка, крадущая циклы ЦП ...), так и другие вещи (перегрузка сети, смещение большей части трафика из локального за границу), не говоря уже об отсутствии вещей, которые случаются, когда система работает быстро (низкий уровень трафика может вызвать такие вещи, как потеря кеширования, ранняя эвакуация соединений из плохо настроенных межсетевых экранов с отслеживанием состояния).