rcu_sched самообнаруживаемая остановка процессора + сторожевой таймер: ошибка: мягкая блокировка - процессор № 3 застрял на 22 секунды

Question

rcu_sched самообнаруживаемая остановка процессора + сторожевой таймер: ошибка: мягкая блокировка - процессор № 3 застрял на 22 секунды

Будучи не в состоянии подключиться к компьютеру по ssh, я подключил его к монитору и обнаружил следующее:

Машина работает под управлением Ubuntu Server 18.04 LTS и представляет собой 8-ядерное Ryzen 1700 первого поколения. С тех пор я перезапустил машину, и она работает нормально, но я не уверен, что вызвало это в первую очередь, и хочу избежать повторения.

11

kernel lockup scheduler watchdog

Источник

Greg 01 фев '19 в 04:36

1 ответ

Другие вопросы по тегам kernel lockup scheduler watchdog

WinEunuuchs2Unix 16 фев '19 в 17:25 2019-02-16 17:25 · Answer 1 · 2019-02-16 17:25

From: О чем все эти сообщения "Bug: soft lockup"?

ситуация
В системном журнале (/var/log/messages или journalctl) выводится множество следующих сообщений.
May 25 07:23:59 XXXXXXX kernel: [13445315.881356] BUG: soft lockup - CPU#16 stuck for 23s! [yyyyyyy:81602]
сопровождаемый различными следами стека. Этот документ пытается объяснить, что означают сообщения мягкой блокировки.

Само сообщение об ошибке не говорит вам, что является причиной проблемы.

причина
"Мягкая блокировка" определяется как ошибка, которая заставляет ядро зацикливаться в режиме ядра более 20 секунд, не давая другим задачам возможности для запуска. Демон watchdog отправит немаскируемое прерывание (NMI) всем процессорам в системе, которые, в свою очередь, напечатают следы стека своих текущих выполняемых задач.

Снижение нагрузки на сервер является нормальным решением:

разрешение
В обычных условиях эти сообщения могут исчезнуть, если нагрузка снизится. Эта "мягкая блокировка" может произойти, если ядро занято, работает с огромным количеством объектов, которые необходимо сканировать, освобождать или распределять соответственно. Стеки этих задач могут дать первое представление о том, что делали эти задачи. Однако, чтобы иметь возможность изучить причину сообщений, потребуется дамп ядра.
Вы не можете отключить эти сообщения, однако в некоторых ситуациях увеличение времени срабатывания этих программных блокировок может ослабить ситуацию.
Сделайте так, просто увеличьте следующее sysctl параметр: kernel.watchdog_thresh Значение по умолчанию для этого параметра 10 и удвоение значения может быть хорошим началом.