Что вы в первую очередь проверяете, когда нетронутый сервер Unix начинает сходить с ума?

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

Какие дешевые вещи вы должны проверить, как только вы получите сеанс SSH на машине?

Меня особенно интересуют истории о травмах, которые подчеркивают неочевидные команды и редкие ситуации, но я думаю, что очевидное варьируется от человека к человеку, поэтому мы можем просто перечислить их все свободно

Первый порядок: отзывчив?

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

Второй порядок: находятся ли основные структуры системы в хорошем состоянии и порядке?

Проверьте «Золотую Триаду» систем:

• Достаточно процессорного времени для обработки
• На диске достаточно места для хранения
• Достаточно памяти свободно для рабочих нагрузок

За последние несколько десятилетий триада расширилась до «четырехугольника», который включает в себя коммуникации (сетевое взаимодействие):

• Связь функциональна, отзывчива и имеет емкость

Третий порядок: в чем серьезность проблемы?

Какие программы или услуги затронуты? В порядке убывания серьезности: системный (общесистемный), кластерный (группа программ) или изолированный (конкретная программа)? Кластеры программ обычно отключаются, потому что конкретный базовый сервис не работает или не отвечает. Системные проблемы иногда связаны с этим (например, конфликт DNS или IP), но ключ к решению проблемы - знать, где искать.

Четвертый порядок: диагностические инструменты предоставляют полезные данные, имеющие отношение к проблеме? Теперь, когда у вас есть информация о работоспособности системы (второй порядок) и о том, какие ее части испытывают проблемы (третий порядок), это позволит вам легко определить причину проблемы.

Сообщения об ошибках или файлы журналов должны быть общей путевой точкой в ​​этом путешествии.

Проблемы с процессором:

• loadav
• Топ
• Трассирование

Дисковое пространство / проблемы ввода-вывода:

• Д.Ф.
• дю
• Lsof
• IOSTAT
• vmstat

Проблемы с памятью:

• бесплатно

Проблемы с подключением:

• пинг
• маршрут (и арп и рарп и друзья)
• iptables, ipchains, ipfw (для тех, кто там BSD)
• traceroute или mtr
• hosts, nslookup или dig
• NetStat

Наиболее распространенная жалоба (которую я слышу):

Электронная почта доставляется недостаточно быстро (более одной минуты от отправки до получения получателем) или электронная почта отклоняет мою попытку отправки. Это обычно сводится к ограничителю скорости в Postfix, который включается во время спам-бури, что влияет на способность принимать внутреннюю доставку.

Пример из жизни:

Тем не менее, это не всегда так. Однажды проблема сохранялась независимо от перезапусков службы; так что через 3 минуты пришло время начать осматриваться. Процессор был загружен, но менее чем на 100%, однако нагрузка возросла до 15 на коробке с двумя ядрами и угрожала подняться выше. Команда top показала, что почтовая система была перегружена, наряду со сканером почты, но дочерних процессов amavis не было видно. Это был ключ - команда mail queue (mailq) показала около 150+ недоставленных сообщений, более 80% из которых были спамом, за последние 20 минут. Быстрая настройка для снижения ограничителя скорости (который уменьшил скорость приема спам-шторма) при одновременном увеличении числа дочерних процессов сканирования электронной почты (чтобы помочь в обработке отставания) с последующим перезапуском службы позволила устранить проблему, и система смогла завершить поставки в короткие сроки.

Причиной проблемы было то, что родительский процесс amavis был сбит с мертвой точки, и дочерние процессы в конечном итоге все пошли своим путем (они завершают свою работу после стольких сканирований, чтобы предотвратить утечки памяти). Так что в постфиксе были процессы SMTP, пытающиеся связаться ... из воздуха ... чтобы выполнить сканирование на спам / вирусы, которое было необходимо. В дистрибутиве, который я использовал, были устаревшие пакеты, которые никогда не будут обновлены; так как установка должна была быть заменена через год или около того, я вручную «отменил» установку до последней версии, которая включала несколько исправлений ошибок. У меня не было той же проблемы с тех пор.

обычно «кто» и «последний»

куча проблем на машинах, с которыми мне приходилось сталкиваться много раз, была из-за очень свободного определения «нетронутый» - часто кто-то что-то делал :)

Хорошо, я начну.

Это однажды меня поразило, я часами пробовал тысячи разных вещей, отключал службы тут и там, перезагружался и т. Д. В чем была проблема? Совершенно не хватает места на диске.

Итак, вот первое, что я печатаю при отладке неожиданно проблемного сервера:

df -h

Я никогда не забуду это сейчас. Это просто спасло меня от лишних усилий. Мысль, которой я поделюсь

top (или htop)

Если бы вы могли, я бы всегда пытался выключить все сетевые карты, кроме административного.

Проверка dmesg на наличие ошибок - я обычно начинаю с a dmesg | tail, потому что есть вероятность, что все идет не так, и сервер все еще пытается сделать то, что вызывает ошибку.

Первое, что я проверяю, это «top» (есть ли какие-то странные процессы, те, которые загружают память или процессорное время).

Если там ничего не появится, я проверю «кто», чтобы узнать, есть ли кто-то еще на моей машине по какой-то причине.

Возможно, файловая система была отключена; проверьте с помощью 'cat / etc / mtab', а затем 'fstab', чтобы убедиться, что все загрузится правильно при загрузке.

Проверьте время безотказной работы, чтобы убедиться, что число пользователей на коробке является разумным (должно быть только у вас), а затем просмотрите var / log / auth.log, чтобы увидеть, есть ли что-нибудь не так.

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

top df -h и ВСЕГДА проверяйте / var / log, чтобы убедиться, что раздел не заполнен. Это вызвало у меня полное таяние несколько раз.

дф-ха

проверить, заполнены ли жесткие диски, и кто-то не получил предупреждения

верх или верх

проверить использование памяти и процессора не слишком высоко.

В качестве альтернативы, если окно не отвечает, я захожу в клиент vm-ware и оттуда проверяю cpu / ram.

Запуск чего-то вроде (at) sar на хосте почти обязателен. Полезность возможности получать исторические снимки процессора, сети, памяти и дискового ввода-вывода (среди прочих) не может быть преуменьшена.

Много раз мне удавалось диагностировать неисправность, изучая, что делал хозяин за последние 24 часа, и видя, когда что-то пошло не так.

В Linux я обычно проверяю dmesg и / var / log / messages или / var / log / syslog. dmesg укажет, является ли это внезапной аппаратной ошибкой; довольно много других проблем будет отображаться в системных журналах.

Полагаю, первое, что я делаю, это проверка дискового пространства (как уже упоминали другие). Если простые проверки не выявят «типичную» проблему, я продолжу расследование.

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

lsof > /tmp/lsof.tmp &
ps auxfw > /tmp/ps.tmp &
netstat -anp > /tmp/netstat.tmp &

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