Перестаньте заучивать команды! Вместо этого освойте эти 10 рабочих сценариев Linux

Это перевод оригинальной статьи Stop Memorizing Commands! Learn These 10 Linux Workflows Instead.

Подписывайтесь на телеграм-канал usr_bin, где я публикую много полезного по Linux, в том числе ссылки на статьи в этом блоге.

Новички сосредоточены на командах. Опытные инженеры мыслят рабочими сценариями

Команды меняются, но рабочий процесс остается прежним

Команды — это всего лишь инструменты. Они могут различаться в зависимости от окружения, дистрибутива, версии системы или предпочтений команды. На одном сервере может быть доступен только top, на другом используют htop. Одни команды работают с grep, другие предпочитают rg (ripgrep). Именно поэтому недостаточно просто запоминать команды.

Например, если нам нужно проанализировать запущенные процессы, конкретная команда вторична. Гораздо важнее понимать, какую информацию необходимо получить и как её интерпретировать. Когда цель ясна, выбрать подходящий инструмент уже несложно. Рабочий процесс остаётся неизменным, даже если команды меняются.

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

#1. Высокое потребление памяти

Высокое потребление памяти — одна из самых распространённых причин срабатывания оповещений в Linux. Обычно первым делом запускают команду free -h, которая подтверждает наличие проблемы, но не объясняет её причину.

Когда использование памяти высокое, главная задача — не допустить, чтобы OOM Killer (Out-Of-Memory Killer) завершил критически важные сервисы, такие как базы данных или основные процессы приложения. Для этого нужен последовательный алгоритм действий, который поможет правильно определить причину и устранить проблему до того, как она станет критической.

Шаг 1. Проверьте, не сработал ли уже OOM Killer

OOM Killer (Out Of Memory Killer) означает, что в системе закончилась память, и Linux принудительно завершил один или несколько процессов, чтобы сохранить работоспособность системы. Если это уже произошло, текущее состояние отражает последствия аварии, а не нормальную работу системы.

dmesg -T | grep -E "(Out of memory|oom_kill|Killed process)" | tail -20

#or
journalctl -k | grep -i "killed process"

# Example output:
[Mon Feb 23 03:14:22 2026] Out of memory: Killed process 18432 (java)
 total-vm:8388608kB, anon-rss:6291456kB, file-rss:0kB, shmem-rss:0kB

Если ошибка нехватки памяти уже произошла:

Определите, какой процесс был завершён;
Оцените текущее состояние системы, найдите первопричину и устраните проблему с памятью (шаги 2–7);
Восстановите работу сервиса (systemctl restart <service-name>)

Шаг 2. Подтвердите наличие нехватки памяти

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

free -h

               total        used        free      shared  buff/cache   available
Mem:            15Gi       6.2Gi       1.1Gi       512Mi       7.7Gi       8.3Gi
Swap:           2.0Gi         0B       2.0Gi

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

Высокое значение (норма): доступно примерно 30–50% общего объёма RAM — запас памяти достаточный.
Среднее: доступно 10–30% — нормальное состояние, но стоит наблюдать, если показатель продолжает снижаться.
Низкое: менее 10% — память начинает испытывать нагрузку.
Критическое: менее 5% (или стабильно менее 1–2 ГБ на системах с большим объёмом памяти) — существует риск использования swap, снижения производительности или срабатывания OOM Killer.

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

Использование swap: Ещё один важный показатель — swap. Он показывает, какой объём данных был выгружен из оперативной памяти на диск из-за её нехватки. Однако оповещения должны срабатывать раньше, чем начинает активно использоваться swap, поскольку его использование обычно означает, что свободной RAM уже недостаточно.

0% swap — идеальное состояние, нехватки памяти нет.
Низкое использование: 1–20% от общего объёма swap — незначительная нагрузка, обычно это нормально (если показатель остаётся стабильным).
Высокое использование: более 20–30% — система испытывает серьёзную нехватку памяти, возможны замедление работы и повышенная нагрузка.

Шаг 3. Определите основных потребителей памяти

Если объём available невелик, проверьте, какие процессы используют больше всего памяти.

# live monitoring
top        # press Shift + M to sort by memory

# snapshot
ps -eo pid,comm,%mem,rss --sort=-rss | head

# Output: ps -eo pid,comm,%mem,rss --sort=-rss | head

  PID COMMAND         %MEM    RSS
 2341 firefox         12.3  1024300
 1987 chrome          10.1   842500
 1102 java             8.7   725300
  901 gnome-shell      3.2   265400
  745 systemd           1.5   120000
  512 dockerd           1.2    98000
  333 sshd              0.5    42000
  210 cron              0.1    12000
  105 systemd-journal   0.1    11000

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

Шаг 4: Изучите полученные результаты.

Для каждого процесса с высоким потреблением памяти или подозрительным поведением выясните, сколько памяти он использует: оперативной памяти (RAM), swap и виртуальной памяти.

cat /proc/<PID>/status | grep -E 'VmRSS|VmSwap|VmPeak|VmSize'

VmRSS   :  120000 kB   (RAM used)
VmSwap  :   50000 kB   (swap used)
VmSize  :  300000 kB   (total virtual memory)
VmPeak  :  320000 kB   (peak memory usage)

В первую очередь обращайте внимание на VmRSS и VmSwap: VmRSS показывает, сколько реальной оперативной памяти использует процесс, а VmSwap показывает, какой объём памяти процесса был выгружен на диск (в swap) из-за нехватки оперативной памяти.

VmRSS высокий уровень: > 30% RAM → процесс потребляет много RAM
VmSwap > 0 → часть памяти процесса уже находится в swap (нехватка памяти).
Высокий VmRSS + растущий VmSwap → явный признак проблем с памятью

Шаг 5: Подтверждение поведения

VmSwap > 0 (процесс уже использует swap) Иногда это может быть нормальным, но также может указывать на нехватку памяти, если объём swap продолжает расти или сопровождается высоким значением VmRSS.

# Monitor system memory + CPU + swap activity view updated every 1 second.
vmstat 1

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs  us  sy  id  wain   cs  us  sy  id  wa
 1  0  10240  200000  50000 800000    0    5     2     3   120  200  5   2  90   3

si (swap in) → память возвращается с диска в оперативную память.
so (swap out) → данные выгружаются из оперативной памяти в swap на диске.

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

Если si часто больше 0, значит система регулярно возвращает данные из swap обратно в RAM, что указывает на трудности с восстановлением свободной памяти.

VmRSS High Процесс использует большой объем оперативной памяти. Это может быть как нормальным явлением (для ресурсоёмких сервисов), так и свидетельствовать о проблеме (например, об утечке памяти).

# Monitor VmRSS every 5 seconds to check if memory usage is stable or growing
watch -n 5 "cat /proc/<PID>/status | grep VmRSS"

# Output:
VmRSS:   245678 kB

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

Шаг 6: Примите меры

После того как проблема с памятью подтверждена (высокий VmRSS, использование swap или непрерывный рост потребления памяти), выберите соответствующий способ её устранения, в зависимости от серьёзности проблемы:

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

systemctl restart <service-name>

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

# graceful shutdown (recommended first)
kill <PID>   # allows the process to exit cleanly

# force shutdown (use only if it does not respond)
kill -9 <PID>   # immediately terminates the process

3. Снизьте нагрузку на систему Снизьте нагрузку, временно освободив память и уменьшив объём выполняемой работы, чтобы система перестала активно использовать swap и вернулась в стабильное состояние.

# Clear cache (temporary relief)
sync; echo 3 > /proc/sys/vm/drop_caches

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

Шаг 7: Предотвратите повторение подобного инцидента

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

1. Найдите первопричину
Цель — определить, почему резко выросло значение VmRSS, почему начала использоваться swap и какие изменения в системе или приложении привели к этому.

# If we know which service is the root cause
# Analyze logs for a specific service
# Goal: find what exactly is wrong with that service
journalctl -u <service-name>

Обратите внимание на:

Критические ошибки: записи в логах с ERROR, FAILED или FATAL.
Частые перезапуски: быстро повторяющиеся циклы Restarting, Started или Stopped.
Системное вмешательство: сообщения OOM killed (нехватка памяти) или ошибки сегментации (segfault).
Узкие места: предупреждения о превышении времени ожидания или сбои в работе зависимостей.

# If we don’t know which service is the root cause
# Review all system logs leading up to the incident
# Goal: Correlate system-wide events to establish a timeline of the failure.
journalctl --since "2 hours ago" -p 3..0

Обратите внимание на:

События-триггеры: какой конкретный процесс или развертывание изменились непосредственно перед скачком потребления памяти?
Каскадные сбои: одновременные ошибки в нескольких независимых сервисах.
Вмешательства ядра: сообщения Out of memory: Kill process.
Ограничения ресурсов: предупреждения о проблемах с дисковой подсистемой, высокой нагрузке на CPU или нехватке памяти.

2. Внедрите долгосрочные меры по устранению проблемы

После выявления первопричины примените одно или несколько из следующих постоянных решений:

На уровне приложения → устраните утечки памяти в коде или оптимизируйте ограничения конфигурации (например, настройте размер кучи Java через параметр -Xmx или лимиты рабочих процессов Apache/Nginx).
На уровне инфраструктуры → задайте жёсткие ограничения ресурсов с помощью systemd cgroups или лимитов памяти Docker, чтобы один процесс не мог вывести из строя всю систему.
На уровне мониторинга → настройте предупреждения при использовании памяти на уровне 80%, чтобы вмешиваться до того, как система начнёт активно использовать swap или сработает OOM Killer.

#2. Высокая загрузка CPU

Высокая загрузка процессора — ещё одна распространённая причина оповещений в Linux. Обычно первым делом открывают top или htop и смотрят, какой процесс находится вверху списка. Однако это показывает лишь кто использует процессор, но не объясняет почему.

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

Шаг 1. Подтвердите загрузку CPU

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

# Refresh every 1 second to monitor CPU, memory, and process activity in real time
top -d 1

top - 14:32:15 up 10 days,  3:21,  2 users,  load average: 1.25, 1.10, 0.95
Tasks: 215 total,   1 running, 214 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.5 us,  3.2 sy,  0.0 ni, 83.1 id,  0.8 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Mem :  16000.0 total,   1200.0 free,   9500.0 used,   5300.0 buff/cache
MiB Swap:   2048.0 total,   1800.0 free,    248.0 used

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 1234 appuser   20   0   12.5g   4.2g   150m S  85.0 26.3  45:12.31 java
 5678 nginx     20   0  250000  45000  12000 S   2.0  0.3   2:15.04 nginx
 9012 mysql     20   0    3.0g   1.1g   300m S   1.5  6.9 120:45.18 mysqld

Обратите внимание на:

us (пространство пользователя): > 70% → приложение активно использует ЦП
sy (пространство ядра): >20% → высокая активность ядра; может указывать на большое количество системных вызовов, интенсивную работу сети или частое переключение контекста.
wa (ожидание ввода-вывода): > 5% → вероятно, узким местом является дисковая подсистема или сеть, а не процессор.

Шаг 2. Найдите виновника.

Если объем пользовательского пространства (%us) высок, выясните, какое приложение или сервис создаёт основную нагрузку.

# Show the top 20 processes sorted by CPU usage (highest first)
ps aux --sort=-%cpu | head -20

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
appuser   1234 85.2 12.3 12500000 4200000 ?   Sl   10:00  45:12 java
mysql     2345 15.4  6.8  3200000 1100000 ?   Sl   09:30 120:45 mysqld
nginx     3456  2.1  0.3   250000   45000 ?   S    08:00   2:15 nginx
root      4567  1.5  0.1   120000   12000 ?   S    07:00   0:30 systemd
...

Сосредоточьтесь на:

%CPU → какие процессы потребляют больше всего процессорного времени.
COMMAND → определите, какое приложение/сервис вызывает нагрузку (наше приложение, база данных или неожиданный процесс).
TIME → общее время использования CPU. Высокое значение за короткий период жизни процесса может указывать на резкий всплеск нагрузки.
PID → идентификатор процесса для дальнейшего анализа.
%MEM → проверьте, не является ли процесс одновременно ресурсоёмким по памяти.

Если системное пространство (%sy) велико, изучите активность ядра, чтобы определить, какие системные вызовы или системные задачи потребляют ресурсы ЦП.

# Show real-time system performance (updated every 1 second)
# Helps identify CPU pressure, context switching, and I/O wait
vmstat 1

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs  us  sy  id  wain   cs  us  sy  id  wa
 1  0  10240  200000  50000 800000    0    5     2     3  120  200   5   3  90   2
 2  0  10240  198000  50000 799000    0    3     0     4  150  250   6   4  88   2

Сосредоточиться на:

cs (переключения контекста): > 10 000/сек → процессор слишком часто переключается между процессами или потоками, что создаёт дополнительную нагрузку на планировщик задач и может замедлить работу системы.
in (прерывания): > 10 000/сек → процессор слишком часто обрабатывает аппаратные прерывания (сетевые карты, диски и другие устройства). Высокие значения обычно указывают на интенсивную сетевую активность, работу дисков или проблемы с драйверами.

Шаг 3. Выясните, что стало причиной всплеска нагрузки на CPU

Высокое значение us означает, что большая часть процессорного времени тратится на выполнение кода приложений (в пространстве пользователя, user space). Чтобы определить причину, выясните, какие изменения или условия могли увеличить нагрузку на приложение или снизить его эффективность:

Не увеличился ли неожиданно объём трафика или количество запросов?
Не было ли недавно развёртывания новой версии, изменения конфигурации или перезапуска?
Не зациклился ли процесс, не выполняет ли он чрезмерное количество повторных попыток (retries) или циклов обработки ошибок?
Не обрабатывает ли приложение необычно большой объём данных (пакетные задания, обработку данных, построение отчётов и т. п.)?

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

Выполнялись ли в момент всплеска нагрузки какие-либо задания cron?
Не потребляют ли ресурсы задачи резервного копирования?
Не устанавливались ли системные обновления примерно в это же время?
Совпадает ли всплеск загрузки CPU с увеличением активности пользователей?

Шаг 4. Выберите подходящее решение

Проблемы на уровне приложения (высокое us):

Ожидаемый рост нагрузки → Продолжайте наблюдение и убедитесь, что система остаётся стабильной при штатном масштабировании.
Всплеск трафика → Масштабируйте приложение по горизонтали (добавьте новые экземпляры) или оптимизируйте обработку запросов и распределение нагрузки.
Неэффективный код или неверная конфигурация → Выполните профилирование приложения, найдите наиболее затратные участки кода (hot paths) и оптимизируйте их.
Бесконечный цикл или некорректная логика → Исправьте ошибку и при необходимости перезапустите затронутый процесс.
Ресурсоёмкая пакетная обработка → Перенесите выполнение на другое время, ограничьте скорость обработки или распределите нагрузку между несколькими узлами.

Проблемы на уровне ядра/системы (высокое sy):

Высокая активность ввода-вывода (диск/сеть) → Оптимизируйте операции ввода-вывода, используйте кэширование и сократите количество лишних операций чтения и записи.
Слишком много системных вызовов → Уменьшите чрезмерное количество обращений приложения к ядру и по возможности объединяйте системные операции.
Интенсивное переключение контекста → Сократите число потоков и процессов, настройте уровень параллелизма.
Неэффективность ядра или драйверов → Обновите ядро/драйверы и изучите известные проблемы системного уровня.
Задания Cron, резервное копирование или системные задачи → Измените расписание их выполнения, чтобы избежать конкуренции за ресурсы.
Резкий скачок трафика, создающий нагрузку на систему → Масштабируйте инфраструктуру и настройте параметры ОС и сети (очереди, буферы, параметры сетевого стека).

Шаг 5. Предотвращение повторных проблем с CPU

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

Настройте мониторинг и оповещения по CPU → Отслеживайте устойчивые значения us и sy (а не только общую загрузку CPU) и настройте предупреждения до того, как ситуация станет критической.
Оптимизируйте неэффективный код → Выполните профилирование приложения, устраните наиболее затратные участки, сократите лишние циклы, повторные попытки и тяжёлые вычисления.
Настройте параметры приложения → Скорректируйте уровень параллелизма, размеры пулов потоков и пулов соединений, чтобы избежать перегрузки процессора.
Пересмотрите расписание фоновых задач → Разнесите по времени выполнение cron, резервного копирования и пакетных заданий, чтобы избежать предсказуемых пиков нагрузки.
При необходимости увеличьте ресурсы → Если высокая загрузка CPU стала новой нормой, а не временным всплеском, масштабируйте систему по горизонтали или увеличьте вычислительные ресурсы.

#3. Высокая интенсивность дискового ввода-вывода

Высокая нагрузка на дисковую подсистему — распространённая проблема в Linux, особенно на серверах баз данных, файловых серверах и системах с интенсивной обработкой данных. Первой реакцией часто становится запуск команды df -h, однако она показывает лишь использование дискового пространства, а не степень загрузки подсистемы ввода-вывода.

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

Шаг 1. Подтвердите наличие нагрузки на дисковую подсистему

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

# detailed disk I/O stats, refreshed every 1s (5 times)
iostat -xz 1 5

Device:         rrqm/s   wrqm/s     r/s     w/s   rMB/s   wMB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
sda               0.00     5.00   120.0    80.0     1.2     3.5     45.00     2.10   15.20    10.50    22.10   2.50  92.30

Сосредоточиться на:

%util: > 80% → диск сильно загружен (если значение длительное время держится около 100%, это может указывать на насыщение).
await: SSD > 1 мс, HDD > 10 мс → высокая задержка свидетельствует о медленной обработке операций ввода-вывода.
r/s и w/s → количество операций чтения и записи в секунду (интенсивность нагрузки).
rkB/s и wkB/s → объём данных, считываемых и записываемых в секунду (пропускная способность).

Шаг 2. Определите, какие процессы за это отвечают.

# show all processes with I/O activity (accumulated + active only)
iotop -ao

Total DISK READ: 12.34 M/s | Total DISK WRITE: 45.67 M/s
Current DISK READ: 3.21 M/s | Current DISK WRITE: 10.11 M/s
    TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN  IO>    COMMAND
  1823 be/4  mysql      2.10 M/s    8.30 M/s   0.00 %  95 %    mysqld
  2210 be/4  appuser    0.50 M/s    1.20 M/s   0.00 %  40 %    java -jar app.jar
  1401 be/4  root       0.00 M/s    0.80 M/s   0.00 %  20 %    rsyslogd

Обратите внимание на:

DISK READ / DISK WRITE → Объём данных, который процесс считывает с диска или записывает на диск в секунду. Ищите процессы с необычно высокой дисковой активностью.
IO% (или IO>): > 30% → процесс значительную часть времени ожидает завершения операций ввода-вывода. Это означает, что он блокируется дисковой подсистемой.
COMMAND→ определяет сервис, являющийся источником нагрузки.

Шаг 3. Определите, к каким файлам осуществляется доступ.

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

# list all files opened by a specific process
lsof -p <PID> | grep REG    # Regular files only

java    2210 appuser  5u  REG  8,1  1048576  789 /var/log/app.log
java    2210 appuser  7u  REG  8,1  5242880  912 /opt/app/data.db
java    2210 appuser 12w  REG  8,1   204800  333 /tmp/cache.tmp

Обратите внимание на:

FD → режим использования файла (r: чтение, w: запись, u: чтение и запись). Большое количество w/u может свидетельствовать об интенсивной записи, большое число FD — о возможной утечке, а постоянный доступ к одним и тем же файлам — о неэффективной работе приложения.
TYPE → тип ресурса. Обычно основной причиной высокой нагрузки являются обычные REG-файлы (такие как logs/DB/data).
NAME → путь к файлу. Это наиболее важное поле для определения реального источника дисковой нагрузки.

Шаг 4. Проверьте состояние файловой системы и устройства хранения

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

# Shows how much disk space is used on each filesystem and what type it is (ext4, xfs, etc.).
df -hT

# Searches kernel logs for disk and hardware-related errors.
dmesg | grep -i 'error\|I/O error\|reset\|timeout' # Detect failing disks, cables, or controllers

# Reads the internal health data of a physical disk.
smartctl -a /dev/sda  # Detect early hardware degradation

df -hT → «Не заполнен ли диск?»
dmesg → «Система сообщает об ошибках диска?»
smartctl → «Не выходит ли из строя сам накопитель?»

Шаг 5. Проверьте исчерпание инода

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

# show inode usage per filesystem (how many files can still be created)
df -ih

Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda1 1.2M 1.1M 100K 92% /
/dev/sdb1 2.0M 500K 1.5M 25% /data
tmpfs 250K 50K 200K 20% /run

Обратите внимание на:

IUse% (процент использования inode): > 90% → использование inode очень высокое. Система может перестать создавать новые файлы (логи, временные файлы, записи баз данных), даже если свободное место на диске ещё есть.

Шаг 6. Примите меры.

После того как причина проблемы определена, выполните соответствующие действия:

Выявлена проблема → Перезапустите, исправьте или настройте приложение, создающее чрезмерную нагрузку на дисковую подсистему ввода-вывода.
Интенсивная работа с файлами (логи, базы данных, временные файлы) → Настройте ротацию логов, оптимизируйте доступ к базе данных или очистите временные файлы.
Файловая система заполнена → Освободите место на диске или увеличьте объём хранилища.
Исчерпаны inode (IUse% > 90%) → Удалите ненужные мелкие файлы, очистите логи и кэш или увеличьте количество доступных inode.
Обнаружены ошибки диска или оборудования → Замените или отремонтируйте неисправный накопитель и выясните первопричину аппаратной неисправности.

#4. Медленная работа сети

Медленную работу сети бывает сложно диагностировать, потому что причина не всегда заключается в самой сети. Такие проблемы, как неполадки с DNS, высокая задержка, потеря пакетов, перегрузка сети, правила межсетевого экрана (firewall) или перегруженные приложения, могут сделать приложение медленным.

Многие начинают диагностику с ping, но успешный ответ на ping лишь подтверждает наличие соединения — он не объясняет проблемы с производительностью. Цель — определить, где возникает задержка, и понять, что является первопричиной: клиент, сервер, сетевой маршрут или приложение.

Шаг 1. Исключите задержки DNS.

Часто «медленная сеть» на самом деле оказывается медленным DNS-резолвером. Если разрешение имени занимает 2 секунды, а передача данных — всего 10 миллисекунд, значит сама сеть работает нормально.

# Measure precise DNS resolution time
time dig www.google.com

; <<>> DiG 9.18 <<>> www.google.com
;; ANSWER SECTION:
www.google.com.  300  IN  A  142.250.190.68

real    0m0.045s
user    0m0.010s
sys     0m0.005s

Обратите внимание на real (общее время разрешения DNS):

< 50 мс → Быстрый DNS
50–200 мс → Приемлемо
200–500 мс → Медленный DNS
> 1 с → Вероятная проблема с DNS

Шаг 2. Проверьте загрузку и ошибки локального сетевого интерфейса.

Убедитесь, что локальная сетевая карта (NIC) не теряет пакеты и не упирается в предел своей пропускной способности.

# View live network throughput across all interfaces
ip -s link

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP>
    RX: bytes    packets   errors   dropped
    1256347890   1543210   0        12

    TX: bytes    packets   errors   dropped
    987654321    1321456   0        5

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

# Monitor real-time interface statistics (refreshes every 1 second)
sar -n DEV 1

12:00:01 AM IFACE   rxkB/s   txkB/s
12:00:01 AM eth0     1250      980
12:00:02 AM eth0     1305     1024
12:00:03 AM eth0     1288      995

Следите за rxkB/s - входящим и txkB/s - исходящим сетевым трафиком: если значения длительное время близки к максимальной пропускной способности интерфейса, это может свидетельствовать о перегрузке сети.

Шаг 3. Определите источники сетевой нагрузки

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

# show top remote connections grouped by IP:port and TCP state
ss -tnp | awk '{print $5, $6}' | sort | uniq -c | sort -rn | head -20

150 10.0.0.5:443 ESTAB
120 10.0.0.8:443 ESTAB
 90 10.0.0.12:443 TIME-WAIT
 40 10.0.0.15:443 SYN-RECV
 25 10.0.0.20:443 CLOSE-WAIT

Обратите внимание на:

SYN-RECV (Соединения, ожидающие завершения TCP-рукопожатия) → Большое количество может указывать на SYN-флуд, проблемы балансировщика нагрузки или сети.
TIME-WAIT (недавно закрытые соединения) → Высокое количество соединений может наблюдаться во время пиков трафика или при работе приложений, создающих множество кратковременных соединений.
CLOSE-WAIT (удалённое соединение закрыто, локальное ещё нет) → Высокие значения обычно указывают на проблему в приложении (утечке соединений или отсутствии корректного закрытия).

Шаг 4. Проверьте общую нагрузку на сокеты

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

ss -s

Total: 1200
TCP:   900 (estab 600, closed 150, orphaned 0, timewait 120)

Transport Total     IP        IPv6
RAW       1
UDP       50
TCP       900
INET      951

Команда выводит сводную статистику по состояниям сокетов. Обратите внимание на:

Очень высокий показатель ESTAB → высокий сетевой трафик или приложение с большим количеством активных соединений;
Очень высокий показатель TIME-WAIT → множество короткоживущих соединений или отсутствие повторного использования соединений;
Ненулевое значение ORPHANED → Проблема обработки сокетов приложения

Шаг 5. Сбор и анализ трафика.

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

# capture 200 TCP packets on port 443 (HTTPS)
tcpdump -i eth0 -n -c 200 'tcp port 443'

12:01:01.123 IP 10.0.0.5.52344  > 10.0.0.12.443: Flags [S], seq 12345, win 64240
12:01:01.124 IP 10.0.0.12.443   > 10.0.0.5.52344: Flags [S.], seq 67890, ack 12346
12:01:01.125 IP 10.0.0.5.52344  > 10.0.0.12.443: Flags [.], ack 67891


# S → connection start (SYN)
# S. → SYN-ACK (handshake response)
# . → established data transfer
# F → connection close

Обратите внимание на:

Повторяющиеся SYN-пакеты (только S) → неудачные попытки подключения (возможно, флуд, блокировка брандмауэром или сбой рукопожатия)
Повторная передача SYN-пакета → повторная попытка клиента из-за отсутствия SYN-ACK (потеря пакета, перегрузка сети или нестабильность сети)
Нет ответа SYN-ACK → сервер не отвечает или трафик блокируется
Много кратковременных соединений (быстрое S → F) → неэффективная обработка соединений или высокая текучесть соединений.
Повторная передача / дублирование подтверждений → потеря пакетов, перегрузка сети или ухудшение качества сети.
Доминирование одного IP-адреса в трафике → всплеск трафика, неправильно настроенный клиент или возможная атака.

Шаг 6. Проверьте исчерпание таблицы отслеживания соединений (на хостах NAT/брандмауэра).

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

cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

Если значение count близко к max, новые соединения будут незаметно разрываться.

Шаг 7. Примите меры.

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

Задержки DNS → смените DNS-резолвер, исправьте конфигурацию DNS или настройте более эффективное кэширование.
Перегрузка или ошибки сетевого интерфейса → уменьшите объём трафика, увеличьте пропускную способность или устраните проблемы с сетевой картой и оборудованием.
Высокая сетевая нагрузка → ограничьте скорость для клиентов (rate limiting), оптимизируйте запросы или масштабируйте сервисы.
Перегрузка сокетов (TIME-WAIT, CLOSE-WAIT и т.д.) → настройте обработку соединений в приложении или устраните утечки соединений.
Потеря пакетов, повторные передачи, ошибки SYN → проверьте правила firewall, маршрутизацию и устраните перегрузку сети.
Исчерпание conntrack → увеличьте лимиты или уменьшите количество создаваемых соединений.
Проблемы на уровне приложения → оптимизируйте повторные попытки запросов, повторно используйте соединения и устраните неэффективные сетевые вызовы.

#5. Высокий показатель средней нагрузки (Load Average)

Высокая средняя загрузка не обязательно означает высокую загрузку ЦП (различие, которое многие упускают из виду). Средняя загрузка измеряет количество процессов, которые либо выполняются на процессоре, либо ожидают доступа к ресурсам, таким как процессорное время или дисковый ввод-вывод. В результате система может иметь высокую среднюю загрузку, даже если загрузка ЦП кажется низкой.

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

Шаг 1. Подтвердите среднюю загрузку.

Для начала проверьте текущую нагрузку.

# show system uptime and load average (1, 5, and 15 minutes)
uptime

14:32:18 up 25 days,  4:17,  2 users,  load average: 2.15, 1.87, 1.42

# 2.15 → average load over the last 1 minute
# 1.87 → average load over the last 5 minutes
# 1.42 → average load over the last 15 minutes

Сравните среднюю загрузку процессора с количеством ядер процессора:

Загрузка ≈ ядер CPU → система полностью загружена
Загрузка > ядер CPU → процессы ожидают ресурсов
Загрузка < ядер CPU → у системы есть запас производительности

Шаг 2. Разграничьте нагрузку на CPU и нагрузку на ввод-вывод.

Средняя загрузка процессора — это не только использование CPU. Она включает в себя процессы, работающие на CPU, и те, которые ожидают ресурсов, таких как операции ввода-вывода на диске. Высокая средняя загрузка может указывать на перегрузку CPU, узкие места в операциях ввода-вывода или и то, и другое.

# show CPU, memory, and I/O activity every 1 second (5 times)
vmstat 1 5

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa stin   cs us sy id wa st
 2  0      0 512000  45000 820000    0    0     5    10  120  300 25  5 70  0  0
 8  3      0 500000  45000 820000    0    0  1200  800  500 1200 20 10 30 40  0

В центре внимания: r (процессы, ожидающие загрузки CPU), b (процессы, заблокированные, обычно ожидающие операций ввода-вывода), wa (время CPU, затраченное на ожидание операций ввода-вывода), us / sy (нагрузка CPU приложения/системная нагрузка).

Высокая r (> количества ядер CPU) + высокая us/sy (us + sy > 70%) → загрузка ЦП
Высокий b (> 1) + высокий wa( wa > 10%) → нагрузка ввода/вывода
Высокое значение r (> количество ядер CPU) + низкое значение us/sy ( us + sy < 50%) → Наиболее вероятно - время ожидания ввода-вывода (подтвердите, проверив значение wa > 10% и/или ненулевое значение b)

Если проблема связана с загрузкой CPU, следуйте алгоритму действий при высокой загрузке CPU.
Если проблема связана с загрузкой ввода-вывода, следуйте алгоритму действий при высокой нагрузке на дисковый ввод-вывод.
Если проблема связана с ожиданием ввода-вывода, следуйте алгоритму действий при высокой нагрузке на дисковый ввод-вывод.

#6. Сервис не запускается

Отказ сервиса запускаться — одна из самых распространённых эксплуатационных проблем в Linux. Типичная реакция — снова и снова выполнять systemctl restart в надежде, что проблема исчезнет. Иногда это помогает. Но чаще всего — нет.

Цель — определить, почему сервис не смог запуститься, устранить первопричину и безопасно восстановить его работу.

Шаг 1. Подтвердите сбой.

# Show service state, recent logs, and start/stop status
systemctl status <service>

● nginx.service - A high performance web server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled)
   Active: failed (Result: exit-code) since Thu 2026-06-25 10:15:12
  Process: 2210 ExecStart=/usr/sbin/nginx (code=exited, status=1/FAILURE)

Jun 25 10:15:12 server nginx[2210]: nginx: [emerg] bind() to 0.0.0.0:80 failedbind() to 0.0.0.0:80 failed
Jun 25 10:15:12 server systemd[1]: nginx.service: Failed to start

Активное состояние active (running) → всё в порядке
failed → сервис не запускается
inactive → сервис остановлен
ExecStart error → показывает причину, по которой произошёл сбой при запуске
Строки логов (внизу) → указывают на первопричину (конфликт портов, ошибка конфигурации, проблема с правами доступа)

Шаг 2. Просмотрите логи

Логи обычно позволяют быстрее всего найти первопричину.

# Shows recent logs with errors and explanations
journalctl -u <service-name> -xe --no-pager

-- Logs begin at Thu 2026-06-25 --
Jun 25 10:15:12 systemd[1]: Starting My Application Service...
Jun 25 10:15:12 myapp[2210]: ERROR: Failed to load configuration file /etc/myapp/config.yaml
Jun 25 10:15:12 systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE
Jun 25 10:15:12 systemd[1]: myapp.service: Failed with result 'exit-code'.'exit-code'.
Jun 25 10:15:12 systemd[1]: Failed to start My Application Service.

Обратите внимание на:

сообщения об ошибках ( emerg, error, failed) → непосредственная причина сбоя сервиса
ошибки привязки/порта → порт уже используется
ошибки прав доступа → отсутствует доступ к файлу или каталогу
Сбои в работе зависимостей → необходимый сервис не запущен.

Шаг 3. Проверьте конфигурацию

Некорректная конфигурация — одна из самых частых причин, по которым сервис не запускается. Многие сервисы имеют встроенную команду проверки конфигурации, поэтому всегда выполняйте её перед перезапуском сервиса или применением изменений.

# test Nginx configuration for syntax errors
nginx -t

# test Apache configuration
apachectl configtest

# HAProxy syntax check
haproxy -c -f /etc/haproxy/haproxy.cfg

# SSH configuration test (syntax check only)
sshd -t

Если у сервиса нет встроенной команды проверки, вручную запустите исполняемый файл сервиса из командной строки, используя те же аргументы, которые указаны в unit-файле systemd.

# shows the full unit file including ExecStart
systemctl cat <service-name>

# /lib/systemd/system/nginx.service
[Unit]
Description=A high performance web server

[Service]
Type=forking
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
ExecReload=/usr/sbin/nginx -s reload
ExecStop=/bin/kill -s QUIT $MAINPID

[Install]
WantedBy=multi-user.target

Обратите внимание на:

ExecStart= → точная команда, используемая для запуска сервиса;
ExecReload/ExecStop → как сервис перезагружается и останавливается;
Дополнительные параметры (если присутствуют) → пользовательские переопределения, которые могут изменять поведение по умолчанию.

Шаг 4. Проверьте зависимости

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

# show all required and optional dependencies
systemctl list-dependencies <service>

myapp.service
● ├─network.target
● ├─mysql.service
● ├─redis.service
● ├─system.sliceslice
● └─basic.target

Обратите внимание на:

Обязательные сервисы (например, mysql.service, redis.service) → они должны быть активны, иначе сервис не запустится.

# check if a specific dependency is running
systemctl status <dependency-service>

network.target → сеть должна быть доступна до запуска сервиса.

Шаг 5. Проверьте наличие конфликтов портов

Если в логах указано "Address already in use" или "Failed to bind", это означает, что другой процесс уже прослушивает сетевой порт, который требуется вашему сервису.

# Identify which process is holding the target port (e.g., port 80)
ss -tulpn | grep :80

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

Шаг 6. Проверьте права доступа и владельцев файлов

Сервисы, которыми управляет systemd, часто запускаются от имени непривилегированного системного пользователя (например, mysql, www-data, redis). Если этот пользователь не может прочитать файл конфигурации или записать данные в каталоги логов или данных, сервис завершится с ошибкой при запуске.

# Verify the user/group assigned to the service
systemctl show <service-name> -p User,Group

# Verify ownership of the service's critical directories
ls -ld /var/log/<service-name> /var/lib/<service-name> /etc/<service-name>

Если во время ручной диагностики файлы были случайно изменены или созданы от имени root, восстановите правильного владельца:

# change ownership of service data directory to correct user and group
chown -R <service-user>:<service-group> /var/lib/<service-name>

Шаг 7. Проверьте системные ресурсы

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

# check CPU and memory usage
top

# check available memory and swap usage
free -h

# check disk space availability
df -h

# check process/resource limits
ulimit -a

Обратите внимание на:

высокое потребление памяти / недостаток свободной оперативной памяти → сервис может завершаться или не пройти инициализацию.
высокая загрузка ЦП → запуск может быть медленным или завершаться ошибкой;.
диск заполнен (100%) → сервис не сможет записывать логи или временные файлы;
слишком низкие лимиты файловых дескрипторов или других ресурсов → сервис не сможет открыть необходимые файлы или сокеты.

Шаг 8. Запустите сервис и убедитесь, что он работает

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

# start the service
systemctl start <service-name>

# verify service is active and running
systemctl status <service-name>

# check logs if service still fails or behaves unexpectedly
journalctl -u <service-name> -xe --no-pager

#7. Исследование процесса

Каждое приложение, работающее в Linux, является процессом. Понимание жизненного цикла процесса — одна из фундаментальных основ эффективного администрирования систем. Многие инженеры знают отдельные команды, такие как ps, kill или systemctl, однако устранение проблем, связанных с процессами, требует понимания всего жизненного цикла — от создания процесса до его завершения.

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

Шаг 1. Найдите процесс

# Search for a running process by name
ps aux | grep <process-name>

root      2210  2.5  1.2  450000 50200 ?  Sl  10:15   0:08 nginx: master process
www-data  2211  1.1  0.8  451200 34120 ?  S   10:15   0:03 nginx: worker process

Обратите внимание на PID(например, 2210, 2211) → уникальный идентификатор процесса, который используется в последующих командах для исследования, мониторинга или управления процессом.

Шаг 2. Исследуйте процесс

После того как PID найден, исследуйте процесс, чтобы понять его текущее состояние и поведение.

# Show detailed information for a specific process
ps -o pid,ppid,state,%cpu,%mem,etime,cmd -p <PID>

  PID  PPID S %CPU %MEM     ELAPSED CMD
 2210     1 S  2.5  1.2     02:15:43 nginx: master process

Обратите внимание на:

PPID: 1 → идентификатор родительского процесса.
STATE ( S): R → выполняется (Running)
S → спящий (Sleeping)
D → непрерываемый сон (ожидание I/O)
Z → процесс-зомби (Zombie)
%CPU: 2.5 → текущее использование CPU
%MEM: 1.2 → текущее использование памяти
ELAPSED: 02:15:43 → как долго длится этот процесс
CMD: nginx: master process → команда, которой был запущен процесс.

Шаг 3. Проверьте ооткрытые файлы и сетевые соединения

Определите, с чем именно взаимодействует данный процесс, например, с файлами, каталогами, устройствами и сетевыми сокетами.

# List all open files and network connections for the process
lsof -p <PID>

COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
nginx   2210 root  cwd    DIR  8,1      4096       2 /
nginx   2210 root  txt    REG  8,1   1260032  393298 /usr/sbin/nginx
nginx   2210 root    3r   REG  8,1    524288 1048576 /etc/nginx/nginx.conf
nginx   2210 root    6w   REG  8,1   1048576 2097152 /var/log/nginx/error.log
nginx   2210 root    7u  IPv4  45678       0     TCP 0.0.0.0:80 (LISTEN)
nginx   2210 root    8u  IPv4  45679       0     TCP 192.168.1.10:80->192.168.1.20:52314 (ESTABLISHED)

Обратите внимание на:

FD
r → чтение
w → запись
u → чтение и запись
TYPE
REG → обычный файл
DIR→ каталог
IPv4/ IPv6 → сетевой сокет
NAME Путь к файлу → указывает, к каким файлам обращается процесс
LISTEN → ожидание входящих соединений
ESTABLISHED → активное сетевое соединение

Шаг 4. Просмотрите логи

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

# Show all logs for a specific systemd service
journalctl -u <service>

Обратите внимание на:

Сообщения ERROR / FAIL → непосредственная причина сбоя;
последовательность запуска (Startup sequence) → что происходило до сбоя;
ошибки конфигурации или прав доступа → наиболее распространённые причины;
коды завершения (Exit codes) → причина остановки сервиса.

Шаг 5. Примите соответствующее решение

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

Ошибка конфигурации → исправьте конфигурационный файл, затем повторно выполните проверку и перезапустите сервис.
Сбой зависимостей → запустите или восстановите отсутствующую зависимость (БД, сеть, точку монтирования).
Конфликт портов → остановите конфликтующий процесс или измените порт сервиса.
Проблема с правами доступа → исправьте владельца или права (chown, chmod).
Проблема с ресурсами → освободите место на диске или память либо скорректируйте системные лимиты.
Сбой/неизвестная проблема → изучите более подробные логи и выполните отладку в фоновом режиме.

Не завершайте процесс, пока не поймёте его назначение и влияние на зависящие от него сервисы.

#8. Процесс не завершается

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

Шаг 1. Корректное завершение

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

# Request polite termination (SIGTERM - Signal 15)
kill -15 <PID>

Альтернатива для многопроцессных приложений: если главный процесс создал несколько рабочих процессов (например, Apache, Nginx или PHP-FPM), используйте pkill, чтобы отправить сигнал всей группе процессов по имени:

# Safely request all processes matching the name to stop
pkill -15 -f <process-name>

Шаг 2. Принудительное завершение.

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

# Force termination via the kernel (SIGKILL - Signal 9)
kill -9 <PID>

Шаг 3: Проверьте состояние процесса

Если kill -9 не удалил процесс из вывода ps или top, значит процесс находится в состоянии, в котором он не может принимать сигналы.

# show process state, wait channel, and command
ps -o pid,stat,wchan,comm -p <PID>

PID STAT WCHAN  COMMAND
 2210 D    0      java

Обратите внимание на STAT:

D → процесс находится в непрерываемом сне (Uninterruptible Sleep), обычно ожидая завершения операций ввода-вывода (диск, NFS или другое хранилище). Такой процесс нельзя завершить, пока операция ввода-вывода не завершится.
Z → процесс-зомби (Zombie). Он уже завершил выполнение, но всё ещё присутствует в таблице процессов, потому что родительский процесс ещё не получил его статус завершения.

Шаг 4. Выполните необходимые действия

Процесс находится в состоянии D (непрерываемый сон).
Если в столбце STAT отображается D, процесс ожидает завершения операций ввода-вывода на уровне ядра.

# Shows what kernel function the process is currently waiting on (if any)
cat /proc/<PID>/wchan

blk_mq_get_tag → ожидание очереди блочного устройства (узкое место дисковой подсистемы)
io_schedule → ожидание планировщика ввода-вывода
nfs_* → задержка сетевой файловой системы

Для решения этой проблемы необходимо определить и устранить узкое место в подсистеме хранения или сетевой файловой системе: уменьшить нагрузку на I/O, исправить проблемы с диском или NFS либо остановить процесс, создающий чрезмерную нагрузку. Если подсистема хранения полностью перестала отвечать, последним средством остаётся перезагрузка системы.

Процесс в состоянии Z (зомби) Если в столбце STAT отображается Z, значит, процесс уже завершил выполнение, но всё ещё присутствует в таблице процессов.

# Find the parent process
ps -o ppid= -p <PID>

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

#9. Дисковое пространство заполнено

Заполненный диск — один из самых распространённых инцидентов в Linux. Первая реакция — обычно выполнить df -h, чтобы убедиться, что файловая система заполнена. Но эта команда лишь показывает, где находится проблема, а не что именно занимает место.

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

Шаг 1. Определите затронутую файловую систему

Для начала определите, какая файловая система заканчивает свободное место.

# Show disk usage in human-readable format
df -h

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   45G   2.0G  96% /
/dev/sdb1       200G  120G   80G   60% /data
tmpfs            3.9G     0  3.9G    0% /run

Обратите внимание на:

Use% → процент использования
Mounted on → где файловая система смонтирована в системе.

Шаг 2. Найдите самые большие каталоги

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

# Shows which top-level directories consume disk space (e.g., /)
du -xh / --max-depth=1 2>/dev/null | sort -h

4.0K    /proc
120M    /boot
600M    /home
1.2G    /usr
2.5G    /var
8.0G    /opt
15G     /

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

Распространённые причины проблем в производстве:

/var/log/ → логи, которые не ротируются, или приложение пишет чрезмерно подробные (debug) логи.
/var/lib/docker/ → неиспользуемые слои контейнеров, "висящие" (dangling) тома или большие кэши сборки.
/tmp/ → забытые дампы памяти (core dumps) или неочищенные временные файлы, загруженные приложениями.

Шаг 3. Найдите большие файлы

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

# Search for files larger than 500MB within a specific mounted filesystem/directory
find <mount_point> -type f -size +500M

# find /var/lib -type f -size +500M
/var/lib/mysql/ibdata1
/var/lib/mysql/mysql-bin.000012
/var/lib/docker/overlay2/sha256-layer/layer.tar

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

Шаг 4. Проверьте удалённые файлы, которые всё ещё используются

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

# Show files that are deleted but still held open by processes
lsof | grep deleted

nginx   2210 root  6w   REG  8,1  104857600 /var/log/nginx/access.log (deleted)
java    3321 app   12u  REG  8,1  524288000 /tmp/cache.tmp (deleted)

Если удалённый файл всё ещё открыт, перезапуск процесса, которому он принадлежит, может освободить занимаемое пространство.

Шаг 5. Определите причину

Прежде чем что-либо удалять, разберитесь, почему диск оказался заполнен.

Не сработала ротация логов?
Приложение генерирует слишком много логов?
Недавно была создана резервная копия?
База данных растёт ожидаемым образом?
Пользователь загрузил большой объём данных?

Устранение симптома без устранения причины часто приводит к повторению того же инцидента.

Шаг 6. Безопасно освободите пространство

В зависимости от результатов анализа можно:

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

Избегайте бездумного удаления файлов, особенно в каталогах /var, /etc или каталогах с данными приложений.

Безопасная экстренная очистка

Если необходимо быстро освободить немного места, чтобы восстановить работу неработающего сервиса, выполните следующие безопасные команды очистки:

# Clean up systemd journal logs older than 3 days
journalctl --vacuum-time=3d

# Safely purge unused Docker containers, networks, and dangling images
docker system prune -f

# Clean package manager repository caches (Ubuntu/Debian)
apt-get clean

#10. Исчерпание inode

Иногда df -h показывает, что свободного места на диске достаточно, но приложения всё равно выдают ошибку No space left on device. Это означает, что закончились иноды (индексные узлы метаданных).

Шаг 1. Подтвердите исчерпание инода.

# Check inode utilization instead of block storage
df -i

Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/sda1      3276800 3200000  76800   98% /
/dev/sdb1     13107200  500000 12607200   4% /data
tmpfs          1000000     120   999880   1% /run

Обратите внимание на IUse% (процент использования inode):

< 80% → норма
80–90% → предупреждение
> 90% → высокий риск
~100% → исчерпание inode (невозможно создать новые файлы)

Шаг 2. Найдите каталоги, содержащие слишком большое количество файлов

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

# Find which directories consume most inodes
du -x --inodes / | sort -nr | head -n 10

1200000  /var
950000   /var/lib
600000   /var/log
450000   /home
300000   /var/cache
120000   /usr
80000    /tmp
50000    /opt
30000    /run
10000    /etc

Этот вывод показывает, какие каталоги используют больше всего inode (нагрузка по количеству файлов), а не дискового пространства.

Шаг 3. Перейдите к каталогам с большим количеством файлов.

# Narrow down inode-heavy subdirectories
du -x --inodes /var | sort -nr | head -n 10

800000   /var/log
500000   /var/lib
300000   /var/lib/docker
250000   /var/cache
120000   /var/spool
80000    /var/tmp
50000    /var/www
20000    /var/backups
15000    /var/mail
10000    /var/run

Что это нам говорит:

/var/log → взрывной рост логов (очень распространённая проблема с inode)
/var/lib/docker → слои контейнеров / образы / файлы overlay
/var/cache → накопление кэша (менеджеры пакетов, приложения)
/var/spool → задания в очереди (почта, печать, cron)

Эти данные помогают точно определить, какие подкаталоги внутри /var потребляют больше всего inode, позволяя выполнить целевую очистку вместо того, чтобы действовать наугад.

Шаг 4. Определите источник увеличения размера файлов

# Inspect directories likely generating many small files
find /var/log -type f | head

/var/log/syslog
/var/log/auth.log
/var/log/kern.log
/var/log/nginx/access.log
/var/log/nginx/error.log
/var/log/journal/abcd1234/system.journal
/var/log/mysql/error.log
/var/log/apt/history.log
/var/log/dpkg.log
/var/log/faillog

Эта команда позволяет быстро просмотреть структуру файлов логов, помогая определить, в каком направлении углубить анализ проблем с inode или использованием диска.

Шаг 5. Исправьте проблему и выполните очистку

Очистка логов / ротация:

logrotate -f /etc/logrotate.conf

Удалите безопасные временные файлы:

rm -rf /tmp/*
rm -rf /var/tmp/*

Исправление на уровне сервиса:

перезапустить шумный сервис
исправить конфигурацию логирования
снизьте скорость генерации файлов

Шаг 6. Проверьте восстановление

# confirm inode usage dropped
df -i

# 11. Сервер работает медленно

«Сервер работает медленно» — один из самых распространённых и при этом наименее конкретных инцидентов, с которыми мы сталкиваемся. Он не указывает на какую-то одну проблему. Первой реакцией часто становится подключение к серверу по SSH и запуск top. Хотя это вполне разумная отправная точка, она показывает лишь часть общей картины.

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

Шаг 1. Проверьте возможные причины

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

CPU → высокая загрузка или ресурсоёмкие процессы
Память → Высокое использование оперативной памяти или swap
Диск → высокий дисковый I/O, высокая задержка или недостаток свободного места на диске

# Display a one-time snapshot of CPU, memory, load average, and top resource-consuming process
top -b -n 1

Для быстрой оценки состояния системы обычно используются следующие пороговые значения:

Средняя загрузка: > количества ядер CPU → Высокая средняя загрузка
%CPU (us + sy): > 90% → Высокая загрузка CPU
Доступная память: < 20% → Нехватка памяти

Шаг 2. Определите дальнейшие действия

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

Высокая средняя загрузка → Сценарий при высокой средней загрузке
Высокая загрузка CPU (>90%) → Сценарий высокой загрузки CPU
Мало доступной памяти (<20%) → Сценарий диагностики высокой средней нагрузки

Если средняя загрузка, CPU и память в норме, проверьте другие параметры.

Сеть работает медленно.
Дисковое пространство заполнено

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

Если ничего очевидного не обнаруживается, выясните, что изменилось.

# Focus on recent system logs 
# to check errors, service failures, or anomalies in the last 30 minutes
journalctl -S "30 minutes ago"

Найдите наиболее распространённые причины медленной работы сервера в логах:

Изменения сервисов: Started, Stopped, Restarting, Reloaded
Ошибки и сбои: ERROR, failed, failure, crash
Проблемы производительности: timeout, slow, took too long, delayed
Проблемы с ресурсами: Out of memory, OOM killer, No space left on device
Нестабильность системы: kernel, panic, soft lockup, hang
Проблемы сети: connection refused, reset, timed out

Шаг 4. Проверьте приложение

Если сервер выглядит исправным, сосредоточьтесь на уровне приложений.

Проверьте логи приложения → найдите ошибки, исключения, тайм-ауты.
Проверьте состояние сервиса → убедитесь, что процессы приложения запущены и не перезапускаются/не завершаются с ошибкой.
Проверьте время отклика → медленные API, конечные точки с высокой задержкой.
Производительность базы данных → Медленные запросы, блокировки, ограничения на количество подключений
Недавние развертывания/изменения конфигурации → новый код, конфигурация или feature flags, вызывающие замедление
Внешние зависимости → превышение времени ожидания при вызовах API, сервисов или сторонних сервисов
Ограничения на количество потоков/соединений → Исчерпаны рабочие потоки или пулы соединений

Универсальный алгоритм устранения неполадок в Linux

Независимо от типа полученного оповещения (медленная работа сервера, высокая загрузка ЦП, проблемы с памятью или сбой сервиса), расследование обычно следует следующей закономерности:

Alert
  │
  ▼
Identify affected resource
(CPU, Memory, Disk, Network, Service)
  │
  ▼
Find the top consumer
  │
  ▼
Collect evidence
(top, vmstat, iostat, ss, journalctl)
  │
  ▼
Determine root cause
  │
  ▼
Apply a fix
  │
  ▼
Verify and monitor

Всегда используйте подход system → changes → application → root cause, который помогает избежать догадок и обеспечивает быструю и структурированную диагностику неисправностей каждый раз.

Заключительные мысли

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

В действительности опытные инженеры подходят к решению проблем иначе. Они не начинают с вопроса: «Какую команду мне выполнить?». Они начинают с вопроса: «Что именно я пытаюсь найти?». Когда цель ясна, выбрать правильную команду становится гораздо проще. Сценарии предоставляют воспроизводимый процесс исследования проблем независимо от того, какие инструменты доступны.

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

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

На этом все! Спасибо за внимание! Если статья была интересна, подпишитесь на телеграм-канал usr_bin, где будет еще больше полезной информации.