Как отслеживать использование системы, сбои в работе и устранять неполадки серверов Linux. Часть 9

Хотя Linux очень надежен, мудрые системные администраторы должны найти способ постоянно следить за поведением и использованием системы. Обеспечение времени безотказной работы, максимально близкого к 100%, и доступности ресурсов являются критически важными потребностями во многих средах. Изучение прошлого и текущего состояния системы позволит нам предвидеть и, скорее всего, предотвратить возможные проблемы.

Представляем программу сертификации Linux Foundation

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

Использование пространства хранения

В Linux есть две хорошо известные команды, которые используются для проверки использования дискового пространства: df и du.

Первый, df (что означает «свободный диск») обычно используется для отчета об общем использовании дискового пространства файловой системой.

Пример 1. Отчет об использовании дискового пространства в байтах и в удобочитаемом формате.

Без опций df сообщает об использовании дискового пространства в байтах. При использовании флага -h та же информация будет отображаться в МБ или ГБ. Обратите внимание, что этот отчет также включает общий размер каждой файловой системы (в блоках по 1 КБ), свободное и доступное пространство, а также точку монтирования каждого устройства хранения.

df
df -h

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

Пример 2. Проверка использования индексного дескриптора файловой системой в удобочитаемом формате с помощью

df -hTi

вы можете увидеть количество используемых и доступных инодов:

Согласно изображению выше, в /home используется 146 индексных дескрипторов (1%), что означает, что вы все еще можете создавать файлы размером 226 КБ в этой файловой системе.

Пример 3: Поиск и/или удаление пустых файлов и каталогов

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

Используйте следующие команды, чтобы найти пустые файлы или каталоги (занимающие 0B), которые используют индексные дескрипторы без причины:

find  /home -type f -empty
find  /home -type d -empty

Кроме того, вы можете добавить флаг -delete в конце каждой команды, если вы также хотите удалить эти пустые файлы и каталоги:

find  /home -type f -empty --delete
find  /home -type f -empty

Предыдущая процедура удалила 4 файла. Давайте еще раз проверим количество используемых/доступных узлов в /home:

df -hTi | grep home

Как видите, сейчас используется 142 инодов (на 4 меньше, чем раньше).

Пример 4. Проверка использования диска по каталогам

Если использование определенной файловой системы превышает заранее определенный процент, вы можете использовать du (сокращение от «использование диска»), чтобы узнать, какие файлы занимают больше всего места.

Пример приведен для /var, который, как вы можете видеть на первом изображении выше, используется на 67%.

du -sch /var/*

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

Читайте также

1. 12 полезных команд «df» для проверки места на диске
2. 10 полезных команд «du» для определения использования дисковых файлов и каталогов

Использование памяти и процессора

Классическим инструментом в Linux, который используется для общей проверки использования процессора/памяти и управления процессами, является команда top. Кроме того, top отображает работающую систему в режиме реального времени. Существуют и другие инструменты, которые можно использовать для той же цели, например htop, но я остановился на top, поскольку он устанавливается «из коробки» в любом дистрибутиве Linux.

Пример 5: Отображение текущего состояния вашей системы с помощью top

Чтобы начать top, просто введите следующую команду в командной строке и нажмите Enter.

top

Давайте рассмотрим типичный верхний вывод:

В строках с 1 по 5 отображается следующая информация:

1. Текущее время (20:41:32) и время работы (7 часов 41 минута). В системе зарегистрирован только один пользователь, а нагрузка средняя за последние 1, 5 и 15 минут соответственно. 0,00, 0,01 и 0,05 указывают, что в течение этих интервалов времени система простаивала 0% времени (0,00: ни один процесс не ожидал процессора), затем она была перегружена на 1% (0,01: в среднем 0,01 процесса ждали ЦП) и 5% (0,05). Если значение меньше 0 и меньшее число (например, 0,65), система простаивала 35 % в течение последних 1, 5 или 15 минут, в зависимости от того, где появляется 0,65.

2. В настоящее время запущен 121 процесс (полный список можно увидеть в 6). Только 1 из них работает (в данном случае верхний, как вы можете видеть в столбце %CPU), а остальные 120 ждут в фоновом режиме, но «спят» и останутся в этом состоянии, пока мы их не вызовем. Как? Вы можете убедиться в этом, открыв командную строку MySQL и выполнив пару запросов. Вы заметите, как увеличится количество запущенных процессов.

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

3. us (время выполнения пользовательских процессов с неизмененным приоритетом), sy (время выполнения процессов ядра), ni (время выполнения пользовательских процессов с измененным приоритетом), wa (время ожидания завершения ввода-вывода), hi (время, затраченное на обслуживание аппаратных прерываний), si (время, затраченное на обслуживание программных прерываний), st (время, украденное у текущей виртуальной машины гипервизором — только в виртуализированных средах).

4. Использование физической памяти.

5. Использование пространства подкачки.

Пример 6: Проверка использования физической памяти

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

free

Конечно, вы также можете использовать переключатели -m (МБ) или -g (ГБ) для отображения той же информации в удобочитаемой форме:

free -m

В любом случае вам необходимо осознавать тот факт, что ядро резервирует как можно больше памяти и предоставляет ее процессам, когда они ее запрашивают. В частности, строка «-/+ buffers/cache» показывает фактические значения после учета этого кэша ввода-вывода.

Другими словами, объем памяти, используемый процессами, и объем, доступный другим процессам (в данном случае 232 МБ используется и 270 МБ доступно соответственно). Когда процессам потребуется эта память, ядро автоматически уменьшит размер кэша ввода-вывода.

Читайте также: 10 полезных «бесплатных» команд для проверки использования памяти Linux

Пристальный взгляд на процессы

В любой момент времени в нашей системе Linux выполняется множество процессов. Для тщательного мониторинга процессов мы будем использовать два инструмента: ps и pstree.

Пример 7: Отображение всего списка процессов в вашей системе с помощью ps (полный стандартный формат)

Используя опции -e и -f, объединенные в одну (-ef), вы можете перечислить все процессы, которые в данный момент выполняются в вашей системе. Вы можете передать этот вывод другим инструментам, таким как grep (как описано в первой части серии статей о LFCS), чтобы сузить вывод до нужного процесса(ов):

ps -ef | grep -i squid | grep -v grep

В приведенном выше листинге процессов отображается следующая информация:

владелец процесса, PID, родительский PID (родительский процесс), загрузка процессора, время запуска команды, tty (? указывает на то, что это демон), совокупное время процессора и команда, связанная с процессом.

Пример 8: Настройка и сортировка вывода ps

Однако, возможно, вам не нужна вся эта информация, и вы хотели бы показать владельца процесса, команду, которая его запустила, его PID и PPID, а также процент памяти, который он использует в данный момент – в этом порядке и отсортировать по использование памяти в порядке убывания (обратите внимание, что ps по умолчанию сортируется по PID).

ps -eo user,comm,pid,ppid,%mem --sort -%mem

Знак минус перед %mem указывает на сортировку по убыванию.

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

Пример 9. Приостановка выполнения запущенного процесса и его возобновление в фоновом режиме.

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

process_name &

или,
Как только он начнет работать на переднем плане, приостановите его и отправьте на задний план с помощью

Ctrl + Z

kill -18 PID

Пример 10: Насильственное уничтожение «вышедшего из-под контроля» процесса

Обратите внимание, что каждый дистрибутив предоставляет инструменты для корректной остановки/запуска/перезапуска/перезагрузки общих служб, таких как service в системах на базе SysV или systemctl в системах на базе systemd.

Если процесс не отвечает на эти утилиты, вы можете принудительно завершить его, отправив ему сигнал SIGKILL.

ps -ef | grep apache
kill -9 3821

Итак.. Что случилось/происходит?

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

cd /var/log

Некоторые элементы в /var/log представляют собой обычные текстовые файлы, другие — каталоги, а третьи — сжатые файлы ротированных (исторических) журналов. Вы захотите проверить те, в имени которых есть слово error, но проверка остальных тоже может пригодиться.

Пример 11. Проверка журналов на наличие ошибок в процессах

Представьте себе этот сценарий. Ваши клиенты локальной сети не могут печатать на сетевых принтерах. Первый шаг для устранения этой ситуации — перейти в каталог /var/log/cups и посмотреть, что там находится.

Вы можете использовать команду tail для отображения последних 10 строк файла error_log или команду tail -f error_log для просмотра журнала в реальном времени.

cd /var/log/cups
ls
tail error_log

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

Пример 12. Проверка журналов на предмет аппаратных сбоев

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

Изображение ниже взято из /var/log/messages после поиска слова error с помощью следующей команды:

less /var/log/messages | grep -i error

Мы видим, что у нас возникла проблема с двумя устройствами хранения: /dev/sdb и /dev/sdc, что, в свою очередь, вызывает проблему с RAID-массивом.

Заключение

В этой статье мы рассмотрели некоторые инструменты, которые помогут вам всегда быть в курсе общего состояния вашей системы. Кроме того, вам необходимо убедиться, что ваша операционная система и установленные пакеты обновлены до последних стабильных версий. И никогда, никогда не забывайте проверять логи! Тогда вы будете двигаться в правильном направлении, чтобы найти окончательное решение любых проблем.

Не стесняйтесь оставлять свои комментарии, предложения или вопросы, если они у вас есть, используя форму ниже.