Определяем, что тормозит Linux: память, CPU или I/O

Если ваша Linux-система тормозит, быстро проверьте: заполнение RAM/Swap (память), загрузку всех CPU-потоков (процессор) или активность дисковой подсистемы (I/O). Установите htop и iotop, посмотрите цветные индикаторы и списки процессов, затем примените целевую меру — добавить ОЗУ, оптимизировать процессы, или улучшить дисковую подсистему. Ниже — пошаговая инструкция, чек-листы и playbook для разных ролей.

Быстрые ссылки

• Memory, Compute (CPU), or I/O Bound?

• Installing htop and iotop

• CPU Bound

• Memory bound

• I/O bound

• Mitigating Performance Issues

• More Than One Performance Bottleneck?

• Wrapping up

Важно: в статье используются примеры команд для систем на базе Debian/Ubuntu и Red Hat/Fedora. Все команды выполняйте с учётом прав доступа и на тестовой среде при первом запуске.

Краткие определения

• Память (RAM): оперативная память, используемая процессами и ядром. Коротко: если система «перестала отвечать» и виден активный swap — проблема с памятью.
• CPU: центральный процессор, измеряется загрузкой каждого ядра/потока. Коротко: если все CPU-потоки близки к 100% — система CPU-bound.
• I/O: ввод/вывод, в основном операции чтения/записи на диск и контроллеры. Коротко: если диск постоянно читает/пишет и процессы ждут I/O — система I/O-bound.

Memory, Compute (CPU), or I/O Bound?

Когда система работает медленно, обычно это самый медленный компонент или цепочка компонентов. Иногда это ПО, иногда — аппаратная часть. Представьте компоненты как водопроводы: самый узкий участок ограничивает общий поток. Точно так же медленный диск, недостаток RAM или перегруженный CPU ограничат производительность.

На Linux типичные узкие места: память (RAM и swap), CPU (много процессов или тяжёлая нагрузка на все потоки) и I/O (медленные HDD, перегруженные контроллеры, частые записи). Для быстрой диагностики используются htop и iotop — простые полуграфические утилиты.

Installing htop and iotop

Чтобы установить htop и iotop на распределениях Debian/Ubuntu/Mint:

sudo apt install htop iotop

Для Red Hat / Fedora / CentOS:

sudo yum install htop iotop

На современных Fedora также может использоваться dnf:

sudo dnf install htop iotop

Если у вас минимальная система без репозиториев, получите пакеты из официального репозитория или соберите из исходников. Для iotop требуется Python и доступ к /proc; утилита обычно запрашивает sudo при запуске.

CPU Bound

Как понять, что система CPU-bound:

1. Запустите htop:

htop

2. Посмотрите на цветные полосы процессора в верхней части. Если у вас 16 потоков — будет 16 полос.
3. Если большинство полос почти полностью заполнены (близки к 100%), это признак, что CPU — узкое место.
4. Проверьте строку Load average — три числа: 1 минута, 5 минут, 15 минут. Если значение значительно выше количества потоков (в долгосрочной перспективе > 2× потоков), система не справляется.

Дополнительно:

• В htop смотрите список процессов внизу: какие процессы занимают CPU? Часто проблема — один или несколько «процессоражующих» процессов.
• Обратите внимание на число задач (Tasks). Очень большое число задач может указывать на сильное переключение контекста (context switching), что тоже снижает реальную пропускную способность CPU.

Когда это не CPU-bound: если полосы CPU не заполнены, но система медленная — ищите другие причины (память или I/O).

Примеры мер при CPU-bound:

• Найти и оптимизировать или рестартовать «холдеров» CPU.
• Ограничить использование CPU через cgroups/systemd slices.
• Перенести тяжёлые расчёты на отдельные узлы/контейнеры.
• В крайнем случае — апгрейд CPU или добавление узлов в кластер.

Memory bound

Как определить проблему с памятью:

1. Откройте htop и посмотрите строки Mem и Swp.
2. Если Memory заполнена полностью, а Swap используется интенсивно — система свопит и будет медленной.
3. swap — операции записи/чтения на диск, очень медленные по сравнению с RAM; постоянный swap — критическая ситуация.

Быстрая команда для проверки:

free -g

или для небольших устройств (Raspberry Pi и т. п.):

free -m

Интерпретация вывода free:

• total — общий объём RAM
• used — занятая
• free — полностью свободная
• buffers/cache — память, используемая под кэш и буферы
• available — сколько реально доступно для новых процессов (учитывает кэши)

Важно понимать: Linux активно использует свободную память для кэша — это нормально. Высокий процент использования RAM не всегда означает проблему: смотрите available и swap.

Когда поведение нормальное, но swap используется немного (10–20%) — это может быть оптимизацией ядра, когда редко используемые страницы выгружаются на диск. Проблемой становится, когда swap растёт и нет свободной RAM.

Меры при Memory-bound:

• Найти процессы с большим потреблением RAM (htop, ps aux –sort=-rss).
• Перезапустить или оптимизировать приложения, снизить число VM/контейнеров.
• Добавить RAM физически.
• Настроить swappiness (параметр /proc/sys/vm/swappiness), если нужно поменять стратегию использования swap.

Пример как посмотреть самые прожорливые по RAM процессы:

ps aux --sort=-rss | head -n 20

Или в htop нажать F6 и отсортировать по MEM%.

I/O bound

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

1. Запустите iotop с правами sudo:

sudo iotop

2. Обратите внимание на верхние индикаторы чтения/записи (обычно в МБ/с). Даже несколько мегабайт в секунду на старом HDD могут быть интенсивной нагрузкой.
3. В списке процессов iotop видно, какие процессы генерируют I/O и сколько байт они читают/пишут.

Признаки I/O-bound:

• Процессы часто находятся в состоянии D (uninterruptible sleep) — в htop это может указывать на ожидание ввода-вывода.
• Высокие показатели await и svctm в iostat (если установлена systat/iostat).
• Долгие latency при выполнении операций чтения/записи.

Команды для дополнительной диагностики:

sudo iostat -xz 1
sudo blktrace /dev/sdX  # продвинутая диагностика
sudo watch -n1 'cat /proc/diskstats'

Меры при I/O-bound:

• Уменьшить лишние записи логов; перенести логи на отдельный диск.
• Перейти на SSD/NVMe вместо HDD.
• Использовать RAID, кеширование (LVM cache, bcache) или контроллеры с технологией offloading.
• Проверить контроллеры/кабели — иногда неверная конфигурация влияет сильнее, чем сам диск.
• Настроить ограничение I/O (ionice, cgroups) для фоновых задач.

Mitigating Performance Issues

Выбор шага зависит от того, какой компонент оказался узким местом:

• Диск/I/O-bound: уменьшение записей, апгрейд на SSD/NVMe, выделение отдельного тома для логов, использование RAID/кеша.
• Memory/Swap-bound: уменьшение числа процессов, оптимизация работы приложений, увеличение RAM, корректировка swappiness.
• CPU-bound: оптимизация/перезапуск тяжёлых процессов, распределение нагрузки, cgroups, масштабирование или замена процессора.

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

More Than One Performance Bottleneck?

Часто проблема многослойная. Например, старый I/O контроллер может занимать много CPU, а диск при этом ещё медленный — оба компонента вместе создают узкое место. Адресуйте все составляющие цепочки: апгрейд одного компонента не решит проблему полностью, если другой остаётся узким звеном.

Пример: контроллер, занимающий 80% CPU для обработки данных, и медленный HDD, загруженный на 80% — даже при замене диска без замены контроллера выигрыш будет ограничен.

Важно оценивать взаимодействие подсистем: CPU, памать, диск и сеть часто зависят друг от друга.

Playbook: пошаговая методика для быстрой диагностики

1. Сбор информации (1–3 минуты):
   • uptime && w
   • top/htop
   • free -m
   • sudo iotop (короткий просмотр)
2. Определение типа узкого места: по полосам CPU, Mem/Swap, I/O.
3. Локализация виновника: процессы с наивысшим потреблением CPU/MEM/I/O.
4. Простая мера: перезапуск процесса, очистка кэша, временное ограничение I/O.
5. План работ: если временное решение помогло, составьте план долгосрочного исправления (апгрейд RAM/SSD/CPU, перераспределение нагрузки).
6. Тестирование: прогоните нагрузку; замеряйте SLI/SLO по времени отклика и пропускной способности.
7. Документирование: зафиксируйте причину, действия и итог.

Decision flowchart

flowchart TD
  A[Начало: система медленно отвечает] --> B{htop: CPU полосы заполнены?}
  B -- Да --> C[CPU bound: проверить процессы, cgroups]
  B -- Нет --> D{Mem/Swap заполнены?}
  D -- Да --> E[Memory bound: смотреть swap, ps, reduce memory]
  D -- Нет --> F{iotop показывает активный I/O?}
  F -- Да --> G[I/O bound: найти процессы, проверить диск]
  F -- Нет --> H[Сложно: проверить сеть, блокировки файлов, сеть/БД]
  C --> I[Применить меры: оптимизировать/ограничить/масштабировать]
  E --> I
  G --> I
  H --> I
  I --> J[Мониторить и документировать]

Ролевые чек-листы

Администратор/DevOps:

• Установить htop и iotop на все критические хосты.
• Настроить системный мониторинг (Prometheus, Grafana) для CPU, RAM, disk I/O, latency.
• Автоматизировать оповещения при превышении порогов (например, CPU_avg > 80% на 5 минут).
• Подготовить playbook для экстренного вмешательства.

Разработчик приложения:

• Проверить утечки памяти и неоптимальные циклы.
• Ограничить логирование в пиковые часы.
• Добавить трассировку медленных запросов (APM).

Пользователь/стек приложения:

• Сообщить точное время и симптоматику тормозов.
• Предоставить выводы htop/iotop и free -m если возможно.

SOP для быстрого реагирования (краткий план действий)

1. Собрать первичные метрики — uptime, htop, free -m, sudo iotop (1–2 минуты).
2. Выявить тип узкого места по визуальным индикаторам.
3. Найти топ-потребителей ресурсов.
4. Применить временную меру (рестарт сервиса, ограничение, миграция нагрузки).
5. Если невозможно быстро устранить — переключить на резерв/масштабировать.
6. После стабилизации подготовить план постоянного решения.

Критерии приёмки

• Время отклика сервиса вернулось к предельному SLA.
• CPU/Mem/IO стабилизировались в пределах установленных порогов.
• Нет постоянного использования swap и длительных очередей дисковых операций.

Команды и подсказки (cheat sheet)

• Просмотр процессов по CPU/MEM: htop
• Быстрая сводка памяти: free -m
• Топ по RSS: ps aux –sort=-rss | head -n 20
• iotop: sudo iotop
• iostat: sudo apt install sysstat; iostat -xz 1
• Ограничение IO: ionice -c2 -n7 -p # приоритизация
• cgroups v2: systemd-run –scope -p CPUQuota=50% <команда>

Важно: ionice и cgroups помогают временно смягчить влияние тяжёлых фоновых задач без полной остановки сервиса.

Типовые ошибки и когда предложенные решения не сработают

• Замена диска на SSD не улучшила ситуацию: причина может быть в контроллере или драйверах.
• Добавление RAM не помогло: возможно, приложение загружает CPU или есть утечка, приводящая к swap в другом месте.
• Перезапуск процесса повторно вызывает пик — причина на уровне приложения, необходимо профилирование.

Безопасность и приватность

• При диагностике не копируйте и не публикуйте логи с чувствительными данными.
• Доступ к iotop/htop требует прав; давайте доступ только доверенным операторам.
• При внедрении решений с переносом логов убедитесь, что конфиденциальные данные защищены и соблюдаются регламенты хранения.

Факто-бокс: ключевые подсказки

• htop показывает загрузку CPU по потокам, память и swap в визуальном виде.
• free -m даёт понятную картину доступной памяти и использования swap.
• iotop показывает процессы с наибольшим вкладом в дисковые операции.
• Одна процедура диагностики: htop → free → iotop → ps/ps aux → iostat.

Глоссарий (одна строка на термин)

• Swap: область на диске, используемая как расширение оперативной памяти.
• Load average: усреднённая загрузка очереди задач за 1/5/15 минут.
• I/O wait: время, в течение которого CPU ждёт завершения операций ввода/вывода.
• cgroups: механизм ядра Linux для ограничения ресурсов процессов.

Короткое объявление для команды (100–200 слов)

Система: Быстрая инструкция по диагностике производительности. Если сервер отвечает медленно — сначала выполните htop и free -m, затем sudo iotop. Это поможет быстро определить, что ограничивает производительность: CPU, память или диск. В большинстве случаев достаточно перезапустить проблемный процесс или перенести нагрузку, но при повторяющихся инцидентах требуется план по апгрейду железа или оптимизации приложения. Документируйте шаги и оповещайте команду об итогах.

Итог

• Начните с htop и free -m, затем проверьте iotop.
• Диагностируйте по признакам: заполнение RAM/Swap, перегруженные CPU-потоки, интенсивный дисковый I/O.
• Применяйте целевые меры и автоматизируйте мониторинг.

Спасибо за чтение. Если нужно, могу подготовить playbook под вашу конкретную инфраструктуру (команды, thresholds, мониоринг) — пришлите краткое описание окружения.