Профилирование производительности сервера Linux - как узнать, что вызвало высокую нагрузку
Если сервер испытывает высокую нагрузку, я использую верхние и аналогичные инструменты для выяснения причин. Однако это эффективно только в том случае, если я могу анализировать, пока сервер испытывает проблему.
Каковы хорошие инструменты для поиска первопричины высокой нагрузки на сервер в прошлые времена? Например, я планировал помещать задание cron для сохранения результатов top, статистики сервера apache, списка процессов mysql и т. Д. Каждые 5 минут. Но это не выглядит очень элегантно, интересно, если кто-то придумал какие-то утилиты для этого уже.
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, чтобы затем ловить этих плохих парней и искать таблицы, требующие индексов.
Иногда lo-tech не плохая технология.:) Зачем использовать бензопилу, когда нож подойдет.
Мог бы также посмотреть на коллекцию, как на альтернативу Мунина.
Он дополняет top/htop, потому что со временем может собирать статистику.