Linux watchdog: soft lockup/hard lockup, rcu stall и hung task — диагностика по dmesg и связь с I/O

Когда Linux-сервер начинает «замирать» на секунды или минуты, а в dmesg появляются строки про watchdog, soft lockup, hard lockup, rcu stall или hung task, задача администратора — быстро понять: это блокировка CPU/ядра, перекос IRQ/softirq, застрявший I/O или цепочка событий, которая может закончиться падением.

Ниже — практичный разбор: что означают эти сообщения, как собрать фактуру в логе ядра, как за 5–10 минут отделить I/O-зависание от CPU/IRQ-проблемы и какие настройки (включая kernel.watchdog, kernel.watchdog_thresh, irqbalance, isolcpus, nohz_full) чаще всего влияют на картину.

Что именно ругается: soft lockup, hard lockup и watchdog

watchdog в Linux — общий термин для механизмов, которые проверяют «живость» CPU/ядра. Если ядро видит, что конкретный CPU слишком долго не возвращается к планированию или не обслуживает прерывания, оно печатает предупреждение (а иногда, при дополнительных настройках, инициирует аварийное действие).

Soft lockup

soft lockup означает: конкретный CPU слишком долго не выходит из ядра к нормальному циклу планирования. Типичная строка:

watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [kworker/3:1:1234]

Частые причины:

• долгий непрерываемый участок кода ядра (драйвер, файловая система, сетевой стек);
• шторм прерываний или перекос IRQ на один CPU (особенно при ручном pinning без общей стратегии);
• сильная конкуренция за spinlock/RCU-секции на высокой нагрузке;
• проблемы с I/O, которые тянут за собой блокировки и накопление работы в kernel workers.

Hard lockup

hard lockup обычно серьёзнее: CPU перестал обслуживать прерывания и «пропал» для watchdog. Часто фигурирует NMI watchdog:

NMI watchdog: Watchdog detected hard LOCKUP on cpu 5

Частые причины:

• реальное зависание CPU (аппаратная проблема, микрокод, тяжёлый баг драйвера);
• аномально долгое отключение прерываний в ядре (редко, но возможно);
• особенности виртуализации: проблемы таймеров/PMU/NMI в гостевой системе при перегруженном хосте.

NMI watchdog

NMI watchdog использует NMI (немаскируемые прерывания) или PMU-счётчики, чтобы ловить «железобетонные» зависания CPU. В виртуальных машинах качество работы зависит от гипервизора и нагрузки на host CPU: где-то всё отлично, где-то возможны ложные срабатывания на пике.

RCU stall

rcu stall означает, что подсистема RCU не может завершить grace period, потому что один или несколько CPU слишком долго не проходят через quiescent state. Пример:

rcu: INFO: rcu_sched detected stalls on CPUs/tasks: { 2-... } (detected by 0, t=21002 jiffies)

Это не то же самое, что soft lockup, но часто идёт рядом: если CPU «залип» в ядре (или задыхается от IRQ/softirq), он может не «отпускать» RCU, и вы увидите оба симптома.

Hung task

hung task — задача слишком долго находится в D-state (непрерываемое ожидание), чаще всего из-за I/O. Пример:

INFO: task php-fpm:12345 blocked for more than 120 seconds.

Это один из самых полезных маркеров: «watchdog ругается на CPU», но корень проблемы может быть в диске, контроллере, сетевом хранилище или файловой системе.

Как собрать фактуру: journal, dmesg и корреляция по времени

В инциденте почти всё решает временная корреляция: что было за 1–3 минуты до первого lockup/stall, и что пошло следом. На системах с systemd удобнее смотреть kernel-логи через journal:

journalctl -k -b --no-pager

Чтобы увидеть только важное (и не утонуть в шуме):

journalctl -k -b -p warning..alert --no-pager

Классический вариант через dmesg (с человекочитаемыми таймстампами):

dmesg -T

Дальше ищите рядом с lockup/stall:

• ошибки блочного слоя, reset контроллера, timeouts, сообщения SCSI/NVMe;
• сообщения файловой системы (ext4/xfs/btrfs) о зависших транзакциях;
• OOM/сильную память под давлением (компакция, reclaim, PSI);
• сетевые watchdog-сообщения (например, «NETDEV WATCHDOG») — отдельная история, но симптомы похожи.

Быстрый triage: CPU lockup или I/O зависание?

Цель triage — за 5–10 минут выбрать правильное направление, не «лечить» симптомы выключением watchdog.

Признаки, что виноват I/O

• в логах есть hung task и/или много процессов в состоянии D (ожидание I/O);
• рядом в логе ядра: timeouts, reset, ошибки чтения/записи, предупреждения драйвера;
• в метриках высокий iowait, очередь диска и растущая латентность.

Минимальный набор быстрых проверок (если утилиты установлены):

uptime

vmstat 1 10

iostat -xz 1 10

На что смотреть в iostat -xz: рост await, высокий %util, увеличение avgqu-sz. Если задержки уезжают в сотни/тысячи миллисекунд — это уже объясняет D-state, а далее могут «выплывать» вторичные симптомы в watchdog/RCU.

Признаки, что виноват CPU/IRQ/ядро

• фризы есть, но по диску всё ровно: латентность стабильная, очереди не растут;
• в сообщении lockup фигурируют ksoftirqd, RCU-потоки, обработчики сетевых/дисковых IRQ;
• есть явный перекос прерываний на один CPU.

Проверки:

mpstat -P ALL 1 5

cat /proc/interrupts | head -n 40

Если один CPU стабильно забит softirq (в mpstat столбец %soft) и/или у него аномально высокий счётчик в /proc/interrupts, это прямой кандидат на soft lockup.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Почему I/O часто выглядит как «проблема CPU»

Важно не путать термины: soft lockup — симптом на стороне CPU, а «диск тормозит» — про I/O. Но на практике они легко сцепляются:

• зависшие I/O-запросы удерживают блокировки в ядре (драйвер/FS), а другие потоки начинают активно ждать и создавать давление;
• на проблемном хранилище растёт число retry/timeout обработок, часть работы уходит в kernel workers и softirq;
• для сетевого storage (NFS/iSCSI и т.п.) добавляется непредсказуемая сеть: фризы часто получаются «рваными».

Если вы одновременно видите hung task и soft lockup, почти всегда стоит сначала доказать или опровергнуть I/O-проблему. И только затем переходить к тонкой настройке watchdog и CPU-изоляции.

Как читать типичные строки dmesg: CPU, процесс, taint и stack trace

Сообщения lockup почти всегда дают минимум: номер CPU, поток, состояние taint и стек вызовов. Пример:

watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [kworker/u16:7:2222]
CPU: 1 PID: 2222 Comm: kworker/u16:7 Tainted: G        W  OE
Call Trace:
 ...

Что извлекать в заметки (потом пригодится для RCA):

• CPU#: повторяется один и тот же? Часто это IRQ-перекос или ошибочная affinity.
• Comm/PID: kworker, ksoftirqd, jbd2, xfsaild или конкретный сервис — уже направление для проверки.
• Tainted: подсказка про сторонние/проприетарные модули и нестандартные драйверы.
• Call Trace: если видно блочный слой/FS/драйвер диска или сетевой подсистемы, это усиливает гипотезу про I/O или IRQ.

Если у вас регулярно проявляются зависания на одном и том же типе нагрузки (например, пиковые бэкапы, массовые fsync, ротации логов, волны трафика), полезно связать это с лимитами в сервисах и systemd. По теме лимитов и «задушенных» сервисов может пригодиться разбор: лимиты CPU и памяти в systemd: как не получить неожиданные тормоза.

Настройки watchdog: что можно трогать, а что лучше не надо

Управление watchdog зависит от конфигурации ядра и параметров загрузки. В user space чаще всего встречаются kernel.watchdog и kernel.watchdog_thresh. Но важно помнить: «выключить watchdog» почти никогда не лечит первопричину — вы лишь скрываете симптом и увеличиваете время до обнаружения фатального зависания.

Посмотреть текущие значения

sysctl kernel.watchdog

sysctl kernel.watchdog_thresh

Практика для продакшена: если у вас доказаны длинные «стоп-миры» под конкретным профилем (например, известные тяжёлые пути в ядре, редкие операции на storage), допустимо временно поднять kernel.watchdog_thresh, но только параллельно с расследованием и сбором метрик.

Почему отключение watchdog — риск

Полное отключение watchdog может привести к «тихой смерти»: внешне VM ещё пингуется, но ssh не заходит, сервисы не отвечают, автоматика не перезапускает инстанс вовремя. Делайте так только если вы понимаете последствия и у вас есть внешнее наблюдение за доступностью и тайм-аутами.

IRQ и irqbalance: когда lockup вызван перекосом прерываний

На многоядерных системах частая история: один IRQ (virtio, NVMe, очередь сетевой карты) «прилип» к одному CPU. На пике этот CPU забивается обработкой прерываний и softirq, а планирование остального деградирует — появляются soft lockup и/или rcu stall.

Проверяем распределение IRQ

cat /proc/interrupts

Если строки вида virtio, nvme, драйвер вашей сетевой карты или virtio_net «льют» почти в один столбец CPU — есть смысл заняться балансировкой.

irqbalance

irqbalance распределяет IRQ по CPU. В некоторых высоконагруженных сценариях его отключают ради ручного pinning, но тогда важно выделить CPU под IRQ/softirq и CPU под ворклоад, иначе lockup-симптомы превращаются в «периодические загадки».

systemctl status irqbalance

isolcpus и nohz_full: как случайно сломать housekeeping

Ключи isolcpus и nohz_full используют для снижения джиттера и низких задержек. Но в типичном веб/БД-проде они нередко создают больше проблем, чем пользы: фоновые задачи ядра и обработка прерываний концентрируются на малом числе housekeeping CPU.

Типовой сценарий

• часть CPU изолирована под приложение;
• IRQ остаются на «не тех» CPU или наоборот попадают на изолированные ядра;
• на housekeeping CPU остаётся слишком много фоновой работы (kworker, flushers, network stack), он перегружается.

Результат: один CPU начинает «задыхаться», растут задержки, появляются rcu stall и soft lockup, а иногда проблема прогрессирует до более тяжёлого сбоя.

Что проверить

• параметры загрузки ядра в /proc/cmdline;
• куда реально приходят IRQ по /proc/interrupts;
• не закрепили ли вы критичные kernel threads на «неправильных» CPU (affinity/cgroups).

cat /proc/cmdline

Hung task и RCU stall: как снизить шум и не пропустить аварию

Иногда система не падает, но логи «забиваются» предупреждениями. Правильный порядок действий: сначала исключить деградацию I/O и перекос IRQ, и лишь потом думать о снижении шума настройками порогов.

Порог hung task

Таймаут диагностики hung task настраивается через kernel.hung_task_timeout_secs:

sysctl kernel.hung_task_timeout_secs

Если у вас легитимно бывают операции, которые могут ждать долго (например, тяжёлые fsync, trim, snapshot на загруженном хранилище), можно аккуратно поднять таймаут. Но это не замена расследованию причин латентности.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Когда lockup заканчивается падением и как снизить риск

Сам по себе soft lockup не обязан приводить к падению. Но в некоторых окружениях настроены более жёсткие реакции (включая аппаратный watchdog, политики гипервизора или панические опции), либо проблема прогрессирует до реального deadlock.

Практические меры, которые обычно дают эффект:

• обновить ядро в рамках вашей стабильной ветки (lockup-баги регулярно исправляются);
• проверить микрокод CPU (актуально для bare metal и части виртуализаций);
• проверить подсистему диска: ошибки, таймауты, очереди, реальную латентность;
• выровнять IRQ и убедиться, что CPU-изоляция не «переломала» housekeeping;
• если нужна автоматическая реакция на зависания сервисов в user space, настройте корректные healthcheck и рестарты (не путать с kernel watchdog): как работает systemd watchdog и рестарты по healthcheck.

Чек-лист диагностики: коротко, но по делу

1. Зафиксируйте окно времени и соберите kernel-логи: journalctl -k -b, dmesg -T.

2. Определите тип симптома: soft lockup, hard lockup, rcu stall, hung task.

3. Проверьте I/O: iostat -xz, vmstat, наличие D-state задач.

4. Проверьте IRQ/softirq: /proc/interrupts, mpstat, статус irqbalance.

5. Если используются isolcpus/nohz_full — проверьте housekeeping CPU и реальную affinity IRQ.

6. Только после этого решайте, нужно ли корректировать kernel.watchdog и kernel.watchdog_thresh (временно и осознанно).

Что делать во время фриза в проде (если SSH ещё жив)

Если сервер ещё отвечает, действуйте так, чтобы не потерять следы:

• снимите быстрые срезы: top, процессы в D-state, iostat, mpstat;
• не перезапускайте всё подряд: сначала соберите логи и метрики, иначе исчезнут ключевые симптомы;
• если фриз повторяется, запланируйте окно для углубления: обновления, проверка драйверов, тесты диска вне пиков, пересмотр IRQ/affinity.

Если сервер «мертв», а в логе перед этим только watchdog/lockup — это аргумент в пользу внешнего мониторинга и автоматического восстановления. На инфраструктуре с предсказуемой нагрузкой часто удобнее жить на виртуализации: при миграциях, быстрых ресайзах и замене узла проще локализовать «плохой хост» или деградирующее хранилище. Если вы как раз подбираете параметры под нагрузку, посмотрите памятку: как выбрать VDS по CPU и RAM под реальный профиль.

Для стабильной работы веб-проектов и предсказуемых обновлений полезно держать окружение в порядке: домен, сертификат и понятные точки отказа. По инфраструктуре Fastfox это закрывается базовыми услугами: VDS, регистрация доменов, SSL-сертификаты.