Если сервер испытывает высокую нагрузку, я использую лучшие и аналогичные инструменты, чтобы выяснить причину. Однако это эффективно только в том случае, если я могу анализировать, пока сервер испытывает проблему.
Какие есть хорошие инструменты для поиска первопричины высокой нагрузки на сервер в предыдущие времена? Например, я планировал выполнить задание cron для сохранения «верхнего» вывода, статистики сервера apache, списка процессов mysql и т.д. каждые 5 минут. Но это не кажется очень элегантным, если интересно, не придумал ли кто-нибудь какие-нибудь утилиты для этого.
Для постоянного мониторинга вы можете рассмотреть возможность установки munin. Он будет собирать информацию каждые 5 минут и создавать графики, которые позволят вам увидеть, где находятся узкие места. Я также использую sar который можно запустить в фоновом режиме, собирая данные на диск. Это дает довольно подробную информацию о том, что является узким местом. Для каких процессов, которые выполнялись в прошлом, вам понадобится пакет учета процессов.
Мне нравится collectd, но я недавно начал играть с pcp (второй пилот по производительности). В нем есть несколько полезных функций для исторической диагностики. [1]: http://oss.sgi.com/projects/pcp/
Ваше неэлегантное решение на самом деле является хорошим без настройки отдельных консолей мониторинга (подумайте о ловушках SNMP). Если вы используете систему в стиле RHEL / CentOS, убедитесь, что вы установили sysstat (и включили его), чтобы собирать текущую статистику о процессоре, памяти, дисковом вводе-выводе и т. Д. (см. файлы конфигурации /etc/sysconfig/sysstat.* для настройки).
Как только у вас будет сбор базовой статистики для вас, ее можно использовать для определения тенденции нагрузки (так что, помимо высокой загрузки ЦП, выполняется ли резервное копирование вашей очереди процессов? Вы видите серьезные ошибки в подкачке страниц? Как ваше использование свопа?) затем вы можете сопоставить свои списки типов mysqladmin proc stat и так далее. Если это стек LAMP, возьмите все процессы httpd, а затем быстро просуммируйте / разделите, чтобы узнать средний размер процесса для записи. Включите журнал медленных запросов в MySQL, чтобы затем отлавливать этих плохих парней и искать таблицы, требующие индексов.
Иногда лоу-тек - это не плохая технология. :) Зачем использовать бензопилу, если подойдет нож.
Можно также посмотреть на collectd, как на альтернативу munin.
Он дополняет top / htop, поскольку может собирать статистику с течением времени.