Сервер Linux тормозит. С чего начать анализ?

Когда сервер начинает “тормозить”, а пользователи жалуются на время отклика, главное — быстро и системно найти “узкое место”. Вот простой и эффективный алгоритм из четырёх шагов, который поможет понять, в чём корень проблемы: в CPU, диске, памяти или чём-то ещё.

Если до сервера не достучаться по SSH, то пробуем

BASH

Свернуть Копировать

ssh -o ConnectTimeout=1 -o ConnectAttempts=1 user@host "nice -n 20 bash"

Нажмите, чтобы развернуть и увидеть больше

Команда откроет шелл с высоким приоритетом - даже когда ничего не помогает

Шаг 1: Проверяем общую нагрузку (Load Average)

Первая команда, которую стоит выполнить, — uptime. Ключевой показатель здесь — Load Average.

uptime

Пример вывода:

12:34:56 up 30 days, 22:10,  1 user,  load average: 2.15, 1.78, 1.25

На что смотреть:

• Показывается средняя нагрузка за 1, 5 и 15 минут.

• Грубое правило: если значение близко или превышает количество ядер CPU — система перегружена. Значение 2.15 на 4-ядерном процессоре — это нормально, а на одноядерном — тревожный сигнал.

• Растущие значения (2.15 > 1.78 > 1.25) говорят, что нагрузка снижается. Если ситуация обратная — нагрузка растёт.

Высокий Load Average при “спокойном” CPU часто указывает на проблемы с диском (I/O Wait).

Шаг 2: Кто потребляет процессор и память?

Запускаем утилиту top для анализа процессов в реальном времени.

top

Ключевые действия внутри top:

1. Сортировка по CPU: Нажмите клавишу P (заглавная латинская). Процессы, потребляющие больше всего процессорного времени, окажутся вверху списка.

2. Сортировка по памяти: Нажмите клавишу M. Вверху окажутся процессы, использующие наибольший объём оперативной памяти (RES).

3. Обратите внимание на строку %Cpu(s):

   • us — нагрузка от пользовательских процессов.

   • sy — нагрузка от ядра системы.

   • wa (I/O Wait) — очень важный показатель! Если он высокий (например, >10-20%), процессор простаивает в ожидании операций ввода/вывода с диска. Это прямое указание на проблему с дисковой подсистемой.

Шаг 3: Диагностика проблем с диском (I/O)

Если высокий Load Average сопровождается высоким %wa в top, самое время детально проверить диск. Поможет утилита iostat. Установка (если не установлена): sudo apt install sysstat для Debian/Ubuntu или: sudo yum install sysstat для RHEL/CentOS

iostat -x 1

На что смотреть (столбцы для вашего диска, например, sda или nvme0n1):

• %util — процент загруженности устройства. Значение, близкое к 100%, означает, что диск работает на пределе своих возможностей и является “бутылочным горлышком”.

• await — среднее время ожидания I/O-операции (в мс). Высокое значение (например, >50-100 мс для HDD или >10-20 мс для SSD) подтверждает проблему с откликом диска.

• r/s, w/s — количество операций чтения и записи в секунду.

Шаг 4: Анализ использования оперативной памяти

Проверяем, не исчерпана ли память и активно ли используется своп (swap).

free -h

Пример вывода:

               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       2.1Gi       1.5Gi       123Mi       4.1Gi       5.2Gi
Swap:          2.0Gi       0.0Gi       2.0Gi

На что смотреть:

1. Строка Mem (оперативная память):

   • available — самый важный показатель. Это оценка памяти, доступной для запуска новых приложений без использования свопа. Если это значение мало (менее 10-20% от total), система будет активно использовать своп, что резко снижает производительность.

   • Не пугайтесь высокого значения used. Linux активно использует свободную память для кеша (buff/cache), что ускоряет работу.

2. Строка Swap (файл подкачки):

   • used — если здесь больше 0, значит система уже начала вытеснять данные из RAM на медленный диск. Растущее или значительное (> 10% от total) использование свопа — явный признак нехватки оперативной памяти.

Краткий чек-лист для быстрой диагностики

1. uptime → Высокий Load Average? Переходим к шагу 2.

2. top (P, M) → %wa высокий? Идём к шагу 3. Памяти available мало? Идём к шагу 4.

3. iostat -x 1 → %util близок к 100%? Проблема в перегруженном диске.

4. free -h → available мало или swap используется? Проблема в нехватке оперативной памяти.

Следуя этим шагам, вы за несколько минут локализуете основную причину медленной работы сервера и сможете принять обоснованное решение: оптимизировать запросы к БД, добавить память, масштабировать службу или увеличить мощность дисковой подсистемы.