Первые 5 минут устранения неполадок на Linux-сервере

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

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

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

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

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

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

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

Кто здесь?

w
last
w
last

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

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

history
history

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

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

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

pstree -a
ps aux
pstree -a
ps aux

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

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

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

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

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

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

Эти команды должны ответить на несколько вопросов:

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

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

lspci
dmidecode
ethtool
lspci
dmidecode
ethtool

Обычные, невиртуализированные сервера продолжают широко использоваться, и эти
команды должны помочь:

  • Определить RAID-контроллер (есть ли у него батарея резервного питания?),
    процессор и количество доступных слотов памяти. Это может подсказать вам
    потенциальные причины проблемы и пути увеличения производительности.

  • Выяснить правильно ли настроена сетевая карта? Не работает ли она в режиме
    полудуплекса? На скорости 10MBps? Есть ли ошибки приема-передачи?

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

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

Очень полезные команды для анализа общей производительности системы хранения.

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

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

mount
cat /etc/fstab
vgs
pvs
lvs
df -h
lsof +D / /* будьте осторожны, не положите сервер */
mount
cat /etc/fstab
vgs
pvs
lvs
df -h
lsof +D / /* будьте осторожны, не положите сервер */
  • Сколько файловых систем смонтировано?
  • Есть ли файловые системы, выделенные для конкретных сервисов? (MySQL например?)
  • Какие указаны опции монтирования: noatime? default? Есть ли какие-то
    файловые системы смонтированные в режиме только для чтения?
  • Есть ли свободное место на дисках?
  • Нет ли больших удаленных файлов, которые продолжают удерживаться каким-либо процессом?
  • Есть ли место для расширения раздела, если проблема в свободном пространстве?

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

sysctl -a | grep ...
cat /proc/interrupts
cat /proc/net/ip_conntrack /* может занять некоторое время на  загруженных серверах */
netstat
ss -s
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, в ней есть полезная информация на эту тему.

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

dmesg
less /var/log/messages
less /var/log/secure
less /var/log/auth
dmesg
less /var/log/messages
less /var/log/secure
less /var/log/auth
  • Ищите любые сообщение об ошибках или предупреждения. Есть ли сообщения о
    слишком большом количестве соединений в conntrack?
  • Есть ли сообщения об аппаратных ошибках или ошибках файловой системы?
  • Коррелируется ли время между ошибками в журналах и предоставленной информацией о проблеме?

Задания cron

  • Есть ли задания, которые выполняются слишком часто?
  • Есть ли персональные конфигурационные файлы 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, и т.п.

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

    Оригинал статьи находится тут http://devo.ps/blog
    Перевод взял от сюда http://ivanpesin.info/blog