Винсент Виалле
First 5 Minutes Troubleshooting A Server by Vincent Viallet, 6 March 2013
Original post: http://devo.ps/blog/2013/03/06/troubleshooting-5minutes-on-a-yet-unknown-box.html
Translated by Ivan Pesin, July 2013
Когда наша команда еще занималась вопросами эксплуатации, оптимизации и масштабирования в предыдущей компании, нам приходилось иметь дело с отладкой медленно работающих приложений и целых инфраструктур, часто большого размера (представьте CNN или the World Bank). Горящие сроки, экзотические стеки технологий и недостаток информации обычно гарантировали незабываемые впечатления.
Причины неполадок редко были очевидными; ниже я привожу список шагов, с которых мы обычно начинали поиск проблемы.
Войдите немного в контекст
Не спешите бросаться на сервера, сперва нужно выяснить, что уже известно о системе и специфике проблемы. Не стоит тратить время на поиск проблемы вслепую.
Несколько обязательных вопросов, требующих ответа:
- Какие конкретно наблюдаются симптомы? Подвисания? Ошибки?
- Когда проблема была замечена впервые?
- Воспроизводится ли она?
- Есть ли закономерность (например, происходит каждый час)?
- Какие были последние изменения в системе (код, сервисы, стек приложений)?
- Влияет ли проблема на определенную группу пользователей (авторизированных, не авторизированных, с общим географическим расположением…)?
- Имеется ли документация на архитектуру (физическую и логическую)?
- Используется ли система мониторинга? Munin, Zabbix, Nagios, New Relic… Подойдет любая.
- Ведется ли (централизированное) журналирование? Loggly, Airbrake, Graylog…
Последние два пункта представляют собой наиболее удобные источники информации, но не возлагайте на них больших надежд: как ни печально, именно мониторинг и журналирование часто отсутствуют. Если не повезло, сделайте заметку, что это нужно поправить, и двигайтесь дальше.
Кто здесь?
Не критично, но обычно не стоит заниматься устранением неполадок в системе, в то время когда с ней играются другие люди. На кухне достаточно одного повара.
Что делали в системе?
Всегда полезно посмотреть на историю команд в комбинации с информацией о том, кто ранее заходил в систему. Не забывайте про ответственность: то, что вы администратор, не дает вам права нарушать чужую конфиденциальность.
Маленькая заметка в уме на потом — вы можете задать переменную окружения HISTTIMEFORMAT, чтобы была возможность отслеживать время, когда выполнялись команды из истории. Нет ничего более раздражающего, чем анализ устаревшего списка команд, не имеющих отношения к проблеме…
Что запущено?
Вывод ps aux содeржит, как правило, много подробной информации о процессах, тогда как pstree -a выдает наглядную и лаконичную картину запущенных процессов, вместе с родительской иерархией.
«Слушающие» сервисы
|
|
$ netstat -ntlp $ netstat -nulp $ netstat -nxlp |
Я предпочитаю выполнять эти команды отдельно, в основном потому что я не люблю смотреть на все сервисы одновременно. Тем не менее, netstat -nalp тоже подойдет и я бы не опускал опцию -n (IP-адреса, мне кажется, воспринимаются лучше).
Определите запущенные службы и выясните должны ли они выполнятся. Посмотрите какие порты находятся в слушающем состоянии. PID слушающего процесса можно всегда найти в выводе ps aux. Это может оказаться очень полезным, особенно когда в системе одновременно запущены несколько Java или Erlang процессов.
Обычно, мы стараемся, чтобы наши системы были более или менее специализированы, с небольшим количеством сервисов на каждой из них. Если вы видите десятки слушающих портов, наверно стоит отметить это себе в уме, чтобы потом разобраться как это можно почистить или реорганизовать.
Процессор и память
|
|
$ free -m $ uptime $ top $ htop |
Эти команды должны ответить на несколько вопросов:
- Есть ли свободная память? Происходит ли своппинг на диск?
- Насколько загружены процессоры? Сколько ядер доступно на сервере? Перегружены ли какие-то из них?
- Что больше всего нагружает систему? Какое у системы значение средней нагрузки (load average)?
Аппаратная часть
|
|
$ lspci $ dmidecode $ ethtool |
Обычные, невиртуализированные сервера продолжают широко использоваться, и эти команды должны помочь:
- Определить RAID-контроллер (есть ли у него батарея резервного питания?), процессор и количество доступных слотов памяти. Это может подсказать вам потенциальные причины проблемы и пути увеличения производительности.
- Выяснить правильно ли настроена сетевая карта? Не работает ли она в режиме полудуплекса? На скорости 10MBps? Есть ли ошибки приема-передачи?
|
|
$ 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 / /* будьте осторожны, не положите сервер */ |
- Сколько файловых систем смонтировано?
- Есть ли файловые системы, выделенные для конкретных сервисов? (MySQL например?)
- Какие указаны опции монтирования: noatime? default? Есть ли какие-то файловые системы смонтированные в режиме только для чтения?
- Есть ли свободное место на дисках?
- Нет ли больших удаленных файлов, которые продолжают удерживаться каким-либо процессом?
- Есть ли место для расширения раздела, если проблема в свободном пространстве?
Ядро, прерывания и сеть
|
|
$ 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 |
- Ищите любые сообщение об ошибках или предупреждения. Есть ли сообщения о слишком большом количестве соединений в conntrack?
- Есть ли сообщения об аппаратных ошибках или ошибках файловой системы?
- Коррелируется ли время между ошибками в журналах и предоставленной информацией о проблеме?
Задания cron
|
|
$ 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, и т.п.
Вы даже могли уже найти непосредственную причину проблемы. Если нет, то вы находитесь в хорошей позиции для дальнейших поисков, зная, что все очевидное уже проверено.