Когда наша команда еще занималась вопросами эксплуатации, оптимизации и масштабирования в предыдущей компании, нам приходилось иметь дело с отладкой медленно работающих приложений и целых инфраструктур, часто большого размера (представьте CNN или the World Bank). Горящие сроки, экзотические стеки технологий и недостаток информации обычно гарантировали незабываемые впечатления.

Причины неполадок редко были очевидными; ниже я привожу список шагов, с которых
мы обычно начинали поиск проблемы.

Войдите немного в контекст

Не спешите бросаться на сервера, сперва нужно выяснить, что уже известно о
системе и специфике проблемы. Не стоит тратить время на поиск проблемы вслепую.

Несколько обязательных вопросов, требующих ответа:

Какие конкретно наблюдаются симптомы? Подвисания? Ошибки?
Когда проблема была замечена впервые?
Воспроизводится ли она?
Есть ли закономерность (например, происходит каждый час)?
Какие были последние изменения в системе (код, сервисы, стек приложений)?
Влияет ли проблема на определенную группу пользователей (авторизированных, не авторизированных, с общим географическим расположением...)?
Имеется ли документация на архитектуру (физическую и логическую)?
Используется ли система мониторинга? Munin, Zabbix, Nagios, New Relic... Подойдет любая.
Ведется ли (централизированное) журналирование? Loggly, Airbrake, Graylog.. Последние два пункта представляют собой наиболее удобные источники информации, но не возлагайте на них больших надежд: как ни печально, именно мониторинг и журналирование часто отсутствуют. Если не повезло, сделайте заметку, что это нужно поправить, и двигайтесь дальше.
Кто здесь?

Code:

$ w
$ last

Не критично, но обычно не стоит заниматься устранением неполадок в системе, в
то время когда с ней играются другие люди. На кухне достаточно одного повара.

Что делали в системе?

Code:

$ history

Всегда полезно посмотреть на историю команд в комбинации с информацией о том,
кто ранее заходил в систему. Не забывайте про ответственность: то, что вы
администратор, не дает вам права нарушать чужую конфиденциальность.

Маленькая заметка в уме на потом - вы можете задать переменную окружения
HISTTIMEFORMAT, чтобы была возможность отслеживать время, когда выполнялись
команды из истории. Нет ничего более раздражающего, чем анализ устаревшего
списка команд, не имеющих отношения к проблеме...

Что запущено?


$ pstree -a
$ ps aux


Вывод ps aux содeржит, как правило, много подробной информации о процессах,
тогда как pstree -a выдает наглядную и лаконичную картину запущенных процессов,
вместе с родительской иерархией.

"Слушающие" сервисы

Code:

$ netstat -ntlp
$ netstat -nulp
$ netstat -nxlp

Я предпочитаю выполнять эти команды отдельно, в основном потому что я не люблю
смотреть на все сервисы одновременно. Тем не менее, netstat -nalp тоже подойдет
и я бы не опускал опцию -n (IP-адреса, мне кажется, воспринимаются лучше).

Определите запущенные службы и выясните должны ли они выполнятся. Посмотрите
какие порты находятся в слушающем состоянии. PID слушающего процесса можно
всегда найти в выводе ps aux. Это может оказаться очень полезным, особенно
когда в системе одновременно запущены несколько Java или Erlang процессов.

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

Процессор и память

Code:

$ free -m
$ uptime
$ top
$ htop

Эти команды должны ответить на несколько вопросов:
Есть ли свободная память? Происходит ли своппинг на диск?
Насколько загружены процессоры? Сколько ядер доступно на сервере? Перегружены ли какие-то из них?
Что больше всего нагружает систему? Какое у системы значение средней нагрузки (load average)?

Аппаратная часть

Code:

$ lspci
$ dmidecode
$ ethtool

Обычные, невиртуализированные сервера продолжают широко использоваться, и эти команды должны помочь:
Определить RAID-контроллер (есть ли у него батарея резервного питания?), процессор и количество доступных слотов памяти. Это может подсказать вам потенциальные причины проблемы и пути увеличения производительности.
Выяснить правильно ли настроена сетевая карта? Не работает ли она в режиме полудуплекса? На скорости 10MBps? Есть ли ошибки приема-передачи? +++

Производительность ввода-вывода

Code:

$ iostat -kx 2
$ vmstat 2 10
$ mpstat 2 10
$ dstat --top-io --top-bio

Очень полезные команды для анализа общей производительности системы хранения.
Проверяем свободное место: есть ли в системе полностью занятые файловые системы или диски?
Используется ли своп (si/so)?
Что занимает процессор: системные вызовы? пользовательские процессы? много ли времени крадется гипервизором (VM)?
Моя любимая команда - dstat. Какие процессы интенсивно используют ввод-вывод? Может быть MySQL грузит дисковую подсистему? Или это какой-то PHP-скрипт?

Точки монтирования и файловые системы

Code:

$ mount
$ cat /etc/fstab
$ vgs
$ pvs
$ lvs
$ df -h
$ lsof +D 

/ /* будьте осторожны, не положите сервер */

Сколько файловых систем смонтировано?
Есть ли файловые системы, выделенные для конкретных сервисов? (MySQL например?)
Какие указаны опции монтирования: noatime? default? Есть ли какие-то файловые системы смонтированные в режиме только для чтения?
Есть ли свободное место на дисках?
Нет ли больших удаленных файлов, которые продолжают удерживаться каким-либо процессом?
Есть ли место для расширения раздела, если проблема в свободном пространстве?

Ядро, прерывания и сеть

Code:

$ sysctl -a | grep ...
$ cat /proc/interrupts
$ cat /proc/net/ip_conntrack
$ netstat
$ ss -s

/* может занять некоторое время на загруженных серверах */
Распределены ли прерывания равномерно по всем процессорам? Возможно одно из ядер перегружено из-за прерываний от сетевой карты, RAID-контроллера, ...?
Какое задано значение swappinness в системе? 60 подходит для персональных компьютеров, но не для серверов. Желательно, чтобы сервер никогда не использовал своп, иначе во время чтения/записи данных на диск, процессы вытесненные в своп окажутся заблокированными.
Достаточно ли велико значение conntrack_max для существующего трафика?
Как долго TCP-соединения могут находится в различных состояниях (TIME_WAIT, ...)?
netstat может быть немного медленным при выводе всех существующих соединений, тогда используйте ss -s, чтобы быстро получить краткую статистику. Посмотрите статью про настройку TCP в Linux, в ней есть полезная информация на эту тему.

Системные журналы и сообщения ядра

Code:

$ dmesg
$ less /var/log/messages
$ less /var/log/secure
$ less /var/log/auth

Ищите любые сообщение об ошибках или предупреждения. Есть ли сообщения о слишком большом количестве соединений в conntrack?
Есть ли сообщения об аппаратных ошибках или ошибках файловой системы? ** Коррелируется ли время между ошибками в журналах и предоставленной информацией о проблеме?

Задания cron

Code:

$ ls /etc/cron* + cat
$ for user in $(cat /etc/passwd | cut -f1 -d:); do crontab -l -u $user; done

Есть ли задания, которые выполняются слишком часто?
Есть ли персональные конфигурационные файлы cron, спрятанные от постороннего взгляда?
Выполнялось ли какое-либо резервное копирование в то время, когда возникла проблема?

Журнальные файлы приложений

Здесь можно много что исследовать, но вряд ли у вас будет время, чтобы детально все просмотреть. Поэтому, сконцентрируйтесь на самом очевидном, например для LAMP-сервера:
Apache & Nginx; посмотрите журналы доступа и ошибок, ищите ошибки 5xx, возможные ошибки limit_zone.
MySQL; посмотрите есть ли ошибки в mysql.log, следы поврежденных таблиц, работающий процесс восстановления innodb. Посмотрите журнал медленных операций и определите есть ли проблемы с диском, индексами или запросами.
PHP-FPM; если включен журнал php-slow, покопайтесь в нем и попробуйте найти ошибки (php, mysql, memcache, ...). Если журнал выключен, активируйте его.
Varnish; проверьте отношение hit/miss в varnishlog и varnishstat. Не пропущено ли правило в конфигурации, в результате чего запросы конечных пользователей проходят до бекэнда, минуя varnish?
HA-Proxy; какой статус у бекэндов? Правильно ли работает проверка здоровья бекэндов? Не переполнена ли очередь запросов на фронтэнде или бекэндах?

Заключение

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