The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

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

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

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

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

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

  • Какие конкретно наблюдаются симптомы? Подвисания? Ошибки?
  • Когда проблема была замечена впервые?
  • Воспроизводится ли она?
  • Есть ли закономерность (например, происходит каждый час)?
  • Какие были последние изменения в системе (код, сервисы, стек приложений)?
  • Влияет ли проблема на определенную группу пользователей (авторизированных, не авторизированных, с общим географическим расположением...)?
  • Имеется ли документация на архитектуру (физическую и логическую)?
  • Используется ли система мониторинга? Munin, Zabbix, Nagios, New Relic... Подойдет любая.
  • Ведется ли (централизированное) журналирование? Loggly, Airbrake, Graylog.. Последние два пункта представляют собой наиболее удобные источники информации, но не возлагайте на них больших надежд: как ни печально, именно мониторинг и журналирование часто отсутствуют. Если не повезло, сделайте заметку, что это нужно поправить, и двигайтесь дальше. Кто здесь? $ w $ last Не критично, но обычно не стоит заниматься устранением неполадок в системе, в то время когда с ней играются другие люди. На кухне достаточно одного повара. Что делали в системе? $ history Всегда полезно посмотреть на историю команд в комбинации с информацией о том, кто ранее заходил в систему. Не забывайте про ответственность: то, что вы администратор, не дает вам права нарушать чужую конфиденциальность. Маленькая заметка в уме на потом - вы можете задать переменную окружения HISTTIMEFORMAT, чтобы была возможность отслеживать время, когда выполнялись команды из истории. Нет ничего более раздражающего, чем анализ устаревшего списка команд, не имеющих отношения к проблеме... Что запущено? $ pstree -a $ ps aux Вывод 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, и т.п. Вы даже могли уже найти непосредственную причину проблемы. Если нет, то вы находитесь в хорошей позиции для дальнейших поисков, зная, что все очевидное уже проверено. Оригинал: First 5 Minutes Troubleshooting A Server by Vincent Viallet, 6 March 2013. Translated by Ivan Pesin, July 2013
  •  
    18.07.2013 , Автор: Ivan Pesin , Источник: http://ivanpesin.info/blog/2013/07/...
    Раздел:    Корень / Администратору / Система / Просмотр состояния и мониторинг системы

    Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, Аноним (-), 23:00, 18/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    lsof +D / /* будьте осторожны, не положите сервер */

    хмм, это как? На клавиши нажимать не как обычно а нежнее? Или перед нажатием <enter> втянуть голову в плечи и приготовиться в худшему? Команда или сработает или нет, нельзя набрать команду "осторожно".

     
     
  • 2.4, Bers666 (?), 04:00, 19/07/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    прежде чем использовать команду, прочтите ее документацию. вот это называется осторожно.
     

  • 1.2, Zulu (?), 23:54, 18/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Иван Песин, админ уровня CNN (c)

    Начало -- Kepner-Tregoe для тех кто не был на их problem analysis trainings, продолжение -- бложик-о-секретах-командной-троки.

     
  • 1.3, pavlinux (ok), 00:17, 19/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Антиадмин!

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

    Чтоб не узнали:

    1. юзайте переменную HISTFILESIZE=0, для хардкора HISTSIZE=0
    2. Начинайте команды с пробела!
    3. С пробела и через echo: $  'echo -ne "rm -rf /*"'


    > Что запущено?
    >  $ pstree -a
    >   $ ps aux

    Нагуглите либу которая скрывает процесс    

    $ LD_PRELOAD=~/libhidepid.so rm -rf /*

    > "Слушающие" сервисы
    >  $ netstat -ntlp
    >  $ netstat -nulp
    >  $ netstat -nxlp

    Собственно переименуйте свои бинарь, скажем в squid, ну и порт 3182 (очень похоже на 3128)

     
     
  • 2.5, Аноним (-), 08:39, 19/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    HISTFILE=/dev/null
     
     
  • 3.6, Аноним (-), 09:09, 19/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    unset HISTFILE
     
     
  • 4.13, pavlinux (ok), 16:47, 19/07/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    возможно дефолное будет, надо код баша смотреть.
     
  • 2.8, тигар (ok), 10:11, 19/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Чтоб не узнали:

    а еще можно с упорством идиота работать из mc. оно, к сожалению, тоже не пишет в history выполненые из него команды.

     
     
  • 3.11, ананим (?), 15:17, 19/07/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    У него свой хистори, сказать имя файла?

    Зыж
    Это не аудит безопасности насколько я понял.
    Если таковой нужен, то перед сабжем воспользуйтесь методикой, которую вы можете не стесняясь набросать тут же.
    За обзор спасибо. Хоть мне лично всё это давно понятно, но для кого-то отличная отправная точка.
    Можно даже в должностные инструкции почти не правя.

     
     
  • 4.12, тигар (ok), 15:58, 19/07/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > У него свой хистори, сказать имя файла?

    не нужно, я его знаю. смотреть же в вывод history а потом еще лазать по ~/.mc это как-то.. ну не удобно.
    > Зыж
    > Это не аудит безопасности насколько я понял.

    так это.. в эмцэ пишем sudo <свой любимый шелл>, дальше Одминистрируем, именно с "О". профит:)
    > Можно даже в должностные инструкции почти не правя.

    О_О должностные инструкции кого?


     
     
  • 5.17, ананим (?), 00:23, 22/07/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >так это.. в эмцэ пишем sudo <свой любимый шелл>, дальше Одминистрируем, именно с "О". профит:)

    И sudo (как и su) у вас не логируются?
    И это животное ещё пытается чему-то учить.

    Зыж
    Не, если есть цель отбить желание на этот ресурс вообще что-либо постить, то этот шерханчик действует правильно — куча навоза, мало по-существу, почёсывание чсв,...

     
     
  • 6.19, тигар (ok), 00:50, 22/07/2013 [^] [^^] [^^^] [ответить]  
  • –4 +/
    >>так это.. в эмцэ пишем sudo <свой любимый шелл>, дальше Одминистрируем, именно с "О". профит:)
    > И sudo (как и su) у вас не логируются?
    > И это животное ещё пытается чему-то учить.
    > Зыж
    > Не, если есть цель отбить желание на этот ресурс вообще что-либо постить,
    > то этот шерханчик действует правильно — куча навоза, мало по-существу, почёсывание
    > чсв,...

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

     
     
  • 7.28, ананим (?), 00:40, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Тебя от себя не тошнит?
     
     
  • 8.29, тигар (ok), 07:25, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    а должно хотя ладно, сегодня я добрый, поясню 1 запускаешь эмцэ 2 пишешь в там... текст свёрнут, показать
     
     
  • 9.36, ГГГ (?), 22:38, 26/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    5 cat bash_history ... текст свёрнут, показать
     
  • 6.27, Аноним (-), 08:09, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > И sudo (как и su) у вас не логируются?

    Ну подумаешь, ус у полосатого кулхацкера отклеился. А так почти и не спалился, ага-угу :).

     

  • 1.7, тигар (ok), 09:59, 19/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    ухты.. в линакс есть аналог sockstat (ss). внезапно для меня. а то приходилось постоянно netstat терзать.
    остальное - выступление копетана. хаутушка для жуниор-убунтовода которого случайно взяли админом.
     
     
  • 2.9, tanatonaut (?), 10:55, 19/07/2013 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Завязывай, это не самая плохая последовательность действий.
    ИМХО, у каждого, с опытом накапливаются свои инструменты и методы работы.
    Но для тех, кто вообще не знает, что пилить, когда внезапно всё пиз...упало, эта статья будет полезной.
    Предупреждая крики "У норм админа внезапностей нет", скажу, а вот и есть. Именно внезапности и остаются, когда всё настроено и работает.
    Статья позиционирована очень верно и смысл в ней есть.
     
     
  • 3.10, тигар (ok), 10:59, 19/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    а я и не писал что там что-то плохое написано. там написаны очевидные действия, как раз для
    > Но для тех, кто вообще не знает, что пилить, когда внезапно всё
    > пиз...упало, эта статья будет полезной.

    + для себя открыл наличие к-ды ss в линаксах.

     
     
  • 4.14, pavlinux (ok), 16:49, 19/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > а я и не писал что там что-то плохое написано. там написаны
    > очевидные действия, как раз для
    >> Но для тех, кто вообще не знает, что пилить, когда внезапно всё
    >> пиз...упало, эта статья будет полезной.
    > + для себя открыл наличие к-ды ss в линаксах.

    А еще pf у вас дёрнули! Теперь БЗДа ваще не нужна, даже на роутерах! :)

     
     
  • 5.15, Аноним (-), 22:48, 19/07/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > А еще pf у вас дёрнули! Теперь БЗДа ваще не нужна, даже на роутерах! :)

    На роутерах уже давно пингвины свое заняли. И без pf всяких.

     
     
  • 6.18, тигар (ok), 00:48, 22/07/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> А еще pf у вас дёрнули! Теперь БЗДа ваще не нужна, даже на роутерах! :)
    > На роутерах уже давно пингвины свое заняли. И без pf всяких.

    тебя _очень_ обманули.

     
     
  • 7.20, Аноним (-), 11:56, 22/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Вы не в курсе?
     
  • 7.25, Аноним (-), 08:05, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > тебя _очень_ обманули.

    Да ну брось, на мелких домашних пингвины все повально оккупировали. На цысках больших - тоже с недавних пор. Такая фигня.

     
     
  • 8.31, тигар (ok), 07:37, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ну я тоже когда еще был студлом использовал дибиан на рутере, который соединял 2... текст свёрнут, показать
     
  • 3.16, sHaggY_caT (ok), 03:09, 21/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    "Завязывай, это не самая плохая последовательность действий. "
    А зачем смотреть хардваре, когда сервер, скажем, дико тормозит, и лежит критичный сервис?
    ИМХО, нужно сразу топ/вмстат/dstat/netstat/iotop и подобное смотреть
    Настройки биоса нужно смотреть, когда сразу не получится понять, в чем дело
     
     
  • 4.23, Crazy Alex (ok), 17:18, 22/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Я так понимаю - имелось в виду ситуация когда вы этот сервер в глаза не видели или не помните. Надо же оценить, что он вообще может.

    Ну и да, линк, ушедший в 10 мегабит (возможно - по вине другой стороны) - вполне основательная причина для проблем.

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

     

  • 1.21, anonymous (??), 14:11, 22/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Используется ли своп (si/so)?

    Я собственно думал, что si - это software interrupts. А где это so я вообще не вижу, в моем top'е нет =)

     
     
  • 2.22, Stax (ok), 15:18, 22/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Это swap in / swap out из vmstat, в top ни одного из них не видно, он не показывает, как пишут или читают из свопа.
     

  • 1.24, Аноним (-), 02:30, 23/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >conntrack

    Непонятно, откуда вообще это на нагруженном сервере может быть, кроме как оставленное по глупости. Удаление автозагрузки nf_conntrack - это практически первое, что делается при установке ОС на сервер, расчитанный на мало-мальски серьезную нагрузку.

     
     
  • 2.26, Аноним (-), 08:06, 23/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Непонятно, откуда вообще это на нагруженном сервере может быть, кроме как оставленное по глупости.

    Кэп намекает что сервера бывают разные.

     
     
  • 3.30, тигар (ok), 07:31, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Непонятно, откуда вообще это на нагруженном сервере может быть, кроме как оставленное по глупости.
    > Кэп намекает что сервера бывают разные.

    можно пример сервера, где оно нужно?

     
     
  • 4.33, anonymous (??), 11:46, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    А как NAT без conntrack будет работать? Или statefull firewall?
     
     
  • 5.34, тигар (ok), 12:22, 24/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    так а пример "сервера" какой в данном случае? точнее его роль
     
  • 2.42, Xaionaro (ok), 10:10, 28/10/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Непонятно, откуда вообще это на нагруженном сервере может быть, кроме как оставленное по глупости. Удаление автозагрузки nf_conntrack - это практически первое, что делается при установке ОС на сервер, расчитанный на мало-мальски серьезную нагрузку.

    Смотря что создаёт нагрузку. Если сетевого трафика мало, а нагрузка вся в user-space, то отключение неиспользование conntrack ничем не поможет снять нагрузку.

    В общем, как уже выше сказали, сервера бывают разные. Лично у меня всего на 3 серверах не используется conntrack.

     

  • 1.32, Аноним (-), 07:49, 24/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а у меня бизибокс в котором ничего кроме кастрированного ps и netstat нетути
     
  • 1.35, ffsdmad (ok), 15:02, 25/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    отправил своему заместителю, а вечером удалю его из dhcp и всех сервисов -- пускай утром сам себе даст доступ
     
     
  • 2.37, hshhhhh (ok), 16:22, 29/07/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Нынче без dhcp уже никак? :)
     

  • 1.38, hshhhhh (ok), 19:36, 29/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Огромное спасибо!
     
  • 1.39, Аноним (39), 04:00, 02/08/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Стоило бы уточнить какие утилиты доступны в минимальной сборке линей. Например, ss входит в пакет iproute2.
     
  • 1.40, Аноним (39), 04:02, 02/08/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Предположим сервер новый. Массив индексируется. Как понять, что "да, ждем пока отпустит"?
     
  • 1.41, Аноним (39), 04:03, 02/08/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    чОртов опеннет, makky написал 2 поста выше.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру