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

Дисковая подсистема и I/O

На самом деле наиболее частая причина задержек при свободном CPU — операции ввода-вывода. Среди других причин, связанных с этой подсистемой: 

Высокий iowait

Процессор в этом случае свободен, но ждёт завершения чтения или записи. Если у вас в отчёте iostat -x или vmstat высокий %iowait (выше 10–15%), значит, есть именно такая проблема. 

iostat -x -z 1 10

Чаще всего «узким местом» оказывается самый медленный элемент в цепочке. Если на сервере несколько накопителей (RAID-массив на HDD, SSD, NVMe и т. п.), то медленный HDD точно повлияет на производительность. 

Процессы в состоянии D

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

Проверить это можно командой top -H (показывает потоки) и сортировкой по столбцу S. Если множество потоков «висит» в статусе D, это почти всегда указывает на проблемы с диском или удалённой файловой системой.

top -H

Очереди и планировщики I/O

В контроллерах есть очереди запросов — если поступает слишком много запросов на чтение/запись, они накапливаются, и даже быстрые SSD начинают тормозить (высокий await и длина очереди по iostat -x или vmstat).

Что делать, если проблема обнаружилась? Перенести нагрузку на более быстрый носитель, либо перераспределить I/O, сменив планировщик (для SSD и NVMe обычно используют mq-deadline или none). Критичные тома можно монтировать на SSD/NVMe, а фоновые операции — на отдельный диск или даже на другой сервер. Также не забудьте настроить ionice, чтобы «фоновая» запись не конкурировала с «боевой».

Своп и политика памяти

Даже при кажущемся изобилии оперативки проблема может быть в свопе. Если провери��ь параметр ядра через sysctl vm.swappiness, то в большинстве случаев там будет значение 60. В этом случае ядро охотно выталкивает анонимные страницы на диск ещё до полного исчерпания памяти. Логично это приводит к падению производительности. 

cat /proc/sys/vm/swappiness

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

Что делать, если проблема обнаружилась? Во-первых, убедитесь, что на сервере нет «мёртвого» своп-раздела на медленном носителе. 

Во-вторых, контролируйте vm.swappiness — значение можно уменьшить, чтобы минимизировать ненужный свопинг (для серверных сред значение можно установить в диапазоне от 1 до 20). 

sudo sysctl -w vm.swappiness=10

Для объективности отмечу, что уменьшение этой опции увеличивает приоритет данных приложений, но взамен ухудшается кэширование I/O. Отключать полностью не рекомендую.  

Также не забывайте про zswap, который сжимает страницы памяти перед их записью в swap-раздел на диске. Чтобы проверить, активен ли он, выполните команду: 

cat /sys/module/zswap/parameters/enabled 

Если будет Y, значит, включён, если N — выключен. Но и он тоже ест ЦП. 

Виртуализация и CPU Steal Time

Даже если в гостевой ОС ЦП практически не занят, задержка возможна из-за менеджмента гипервизора. Проверить это можно в колонке %st (столбец stolen) в выводе top, там видно, сколько времени гостевая виртуалка была готова работать, но гипервизор выделил ядро другому «гостю». 

Если там вы видите почти 100% idle, но %st отличен от нуля (особенно двузначные значения), это признак чрезмерной нагрузки на хосте. Причины в этом случае никак не связаны с вами, это либо оверселлинг, либо «шумный сосед», который выжимает ресурсы и замедляет вас. 

Что делать, если проблема обнаружилась? Как писал ранее, первый шаг — зафиксировать заторможенность метриками. Проверьте %st в top, vmstat 1 или mpstat и убедитесь, что steal растёт на фоне низкой загрузки приложения и CPU user/sys. В этом случае выход один — берите цифры и идите к провайдеру. 

Если провайдер даёт метрики гипервизора, дополнительно сверьте загрузку физических ядер. Разумно использовать порог около 10% steal при длительном удержании значения и сопоставлять временные метки с ростом latency, таймаутами и логами APM. 

Сетевая подсистема

Интенсивная сетевая активность серверов (БД-кластеры, REST-запросы, массовый обмен данными) тоже может проявляться как «фриз» системы. Перегрузка каналов или файрволла в этом случае приводит к очередям в сетевом стеке.

Сбросы и затыки пакетов можно посмотреть в netstat -s и iftop. Но, если у вас 100% загруженный канал, даже обычные SSH/HTTP-запросы будут отставать, хоть ЦП кажется свободным.

netstat -s | less

или

sudo iftop -i eth0

Также проблема может проявляться из-за потери пакетов. Процессы будут ждать подтверждений при передаче, несмотря на простой CPU. Глянуть количество ошибок и дропов можно в: 

cat /proc/net/dev

или 

ethtool -S eth0 | egrep -i 'drop|err|fail|miss|over|timeout|abort|reset'

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

Что делать, если проблема обнаружилась? В этом случае проверьте /proc/interrupts — если одна сеть или диск генерирует слишком много прерываний на одном ядре, можно запустить irqbalance или вручную настроить affinity для конкретных IRQ. 

Наконец, виртуальные сетевые адаптеры тоже могут добавлять небольшую задержку, особенно при частых транзакциях. Если у ВМ несколько интерфейсов, проверяйте статистику каждого (ifconfig, ethtool). 

Планирование, частоты CPU и прерывания

Существуют и внутренние нюансы ОС, которые влияют на отклик.

Менеджмент частоты CPU

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

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

Потоки прерываний

Если сетевая карта или контроллер генерируют слишком много прерываний и они обрабатываются одним ядром, это тоже влияет на производительность. Проверить ситуацию можно в /proc/interrupts — если видно, что один CPU постоянно обслуж��вает львиную долю сетевых или дисковых IRQ, это повод вмешаться.

cat /proc/interrupts | head -n 40

В простых случаях помогает irqbalance: 

sudo systemctl enable --now irqbalance

systemctl status irqbalance --no-pager

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

Блокировки и перегонки (mutex, spinlock)

На уровне приложений или драйверов может происходить конфликт при захвате блокировки — потоки простаивают в ожидании, несмотря на то что физически ЦП свободен.

Диагностируется это через perf, рост context switch в vmstat и характерные вызовы futex или spin_lock в профилях. Исправляется проблема пересмотром архитектуры, ограничением параллелизма и обновлением проблемных компонентов. 

vmstat 1 10

Драйверы и баги ядра

Старые или криво написанные дрова диска/сети/чипсета порой сами создают задержки. В этом случае поможет обновление драйверов и ядра.

Особенности ОС

Помимо очевидных узких мест, у каждой ОС есть свои особенности работы, которые могут неожиданно влиять на задержки. В Linux и FreeBSD активно используется файловый кэш, и при интенсивной записи ядро может тратить заметное время на WriteBack «грязных» страниц.

Иногда задержки возникают и из-за вспомогательных механизмов. Например, слишком частые обращения к /proc со стороны мониторинга способны дать нагрузку.

Виртуальные файловые системы (NFS/SMB) и редкие состояния (неожиданные ошибки I/O) тоже иногда приводят к непредсказуемым простоям. Поэтому при поиске причин стоит заглянуть в dmesg и системные журналы — именно там часто фиксируются таймауты дисков, сбои сетевых драйверов и другие аппаратные проблемы.

dmesg -T | tail -n 200

и

journalctl -b -p err..alert --no-pager

Наконец, нужно почаще собирать метрики. Например, запускать iostat 1, sar, vmstat, или подключить APM/трейсинг. Из опенсорных решений для этого подойдут: 

  • система распределённого трейсинга Jaeger (упустим момент недружественности) или Zipkin,

  • коллектор для метрик, логов и трасс OpenTelemetry Collector,

  • хранитель трейс-данных Grafana Tempo (кстати, хорош для дешёвого long-term хранения спанов),

  • APM-платформа с трейсингом, метриками и алертингом Apache SkyWalking,

  • open-source альтернатива платным APM SigNoz.

Делитесь своими практиками устранения «тормозов» при свободных CPU и RAM в комментариях. Какую метрику смотрите в первую очередь? 

© 2026 ООО «МТ ФИНАНС»