BUG: мягкая блокировка - CPU # завис на x секунд


33

Я видел несколько сообщений об ошибках и вопросы (на stackexchange и в других местах) относительно нытья "BUG: soft lockup - CPU#<n> stuck for <dt>s!". До сих пор я не нашел никакой подсказки относительно того, что делать или пытаться (скорее, подсказки, которые я нашел и следовал, не остановили это). Я также обеспокоен этим, потому что:

  1. частота этих событий в последнее время, по-видимому, медленно росла (более 700 в месяц),
  2. yum update и перезагрузка немного замедлила его, но я видел, что некоторые блокировки снова начинают происходить,
  3. несколько процессов (если не весь хост, это трудно сказать), конечно, включая все мои интерактивные оболочки, заморожены на некоторое время, когда это происходит,
  4. Я не уверен, связано ли это, но я вижу много журналов / сообщений, связанных с тем, что ntpd не может обновить часы.

Ниже приводится выдержка из $(grep 'soft lockup' /var/log/messages*):

Mar 22 10:02:35 localhost kernel: BUG: soft lockup - CPU#15 stuck for 10s! [kjournald:1048]
Mar 22 10:02:36 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:36 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:37 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:37 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:38 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:38 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:39 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:39 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:40 localhost kernel: BUG: soft lockup - CPU#15 stuck for 25s! [swapper:0]
Mar 22 15:42:16 localhost kernel: BUG: soft lockup - CPU#8 stuck for 25s! [kjournald:1048]
Mar 22 18:22:13 localhost kernel: BUG: soft lockup - CPU#15 stuck for 10s! [postgres:21356]
Mar 22 18:22:20 localhost kernel: BUG: soft lockup - CPU#7 stuck for 10s! [java:8653]
Mar 22 18:22:20 localhost kernel: BUG: soft lockup - CPU#8 stuck for 72s! [kjournald:1048]
Mar 22 21:21:37 localhost kernel: BUG: soft lockup - CPU#12 stuck for 29s! [kjournald:1048]
Mar 22 21:22:07 localhost kernel: BUG: soft lockup - CPU#12 stuck for 27s! [kjournald:1048]
Mar 23 02:01:47 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [kblockd/8:276]
Mar 23 02:02:22 localhost kernel: BUG: soft lockup - CPU#8 stuck for 34s! [kblockd/8:276]

Это происходит со случайными процессами и кажется довольно хорошо распределенным по 16 «ядрам» этого виртуального хоста.

Хост является экземпляром AWS EC2 «cc1.4xlarge» с AMI с именем «EC2 CentOS 5.5 GPU HVM AMI (драйвер 260.19.29) (ami-42a2532b)». Кажется, виртуализирован с Xen.

cat /etc/redhat-releaseдоходность CentOS release 5.9 (Final). 'free'сообщает 21G оперативной памяти.

Глава dmesgэто:

Linux version 2.6.18-348.3.1.el5 (mockbuild@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-54)) #1 SMP Mon Mar 11 19:39:25 EDT 2013
Command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet console=tty0 console=ttyS0,115200n8
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000010000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000c0000000 (usable)
 BIOS-e820: 00000000fc000000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 00000005dd800000 (usable)
DMI 2.4 present.
DMI: Xen HVM domU, BIOS 3.4.3-2.6.18 08/29/2012
ACPI: RSDP (v002    Xen                                ) @ 0x00000000000ea020
ACPI: XSDT (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc0062b0
ACPI: FADT (v004    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc005ee0
ACPI: MADT (v002    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc005fe0
ACPI: SRAT (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc0060c0
ACPI: SLIT (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc006240
ACPI: HPET (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc006270
ACPI: DSDT (v002    Xen      HVM 0x00000000 INTL 0x20090220) @ 0x(null)

Следующий пример показывает , кумулятивные счета этих «мягких зависания» в течение недавнего времени (красная линия, когда я сделал последнее yum updateследует reboot) общее количество мягких блокировок.

Следующий пример показывает , гистограмма длительности (как долго хозяин застрял) гистограмма продолжительности.


1
Тонны возможных причин. У меня было это однажды в экземпляре KVM. Причина была в сетевом драйвере хоста (realtek), который делал бы что-то при высоких нагрузках на сеть, которых виртуализация не ожидала, и вуаля вы застряли ЦП в виртуальных машинах. Так что, в основном, ошибка в сетевом драйвере, которая вызвала другие ошибки в будущем. Решением было переключиться на другую версию ядра (на хосте), которая не вызывала это конкретное поведение.
frostschutz

1
Мы получили это сообщение об ошибке, потому что на некоторых виртуальных машинах было настроено больше vcpus, чем физических процессоров на новом сервере, мы перенесли наш хост Xen в.
Йорг Людвиг

Ответы:


11

У меня также есть эта проблема на Xen 4.2 с ядром 3.6 и 3.8 (AlpineLinux).

Я погуглил и, добавив clocksource = jiffies к своему ядру, исправил это. Вместо джиффи можно попробовать «яму».

Есть также сообщения об отключении C-состояний в BIOS .


4
Что делают эти параметры ядра?
Бурхан Али

2
Clocksource кажется мне довольно очевидным, а c-состояния - это состояния питания процессора.
Франц Беттаг

+1. Отключение c-состояний работало на меня.
Эндрю Энсли

2

У меня была та же проблема с моим Thinkpad T520. Но вместо того, чтобы взломать ядро, я сделал что-то более простое. Во-первых, я использую Centos7, я установил базовую систему, все работало нормально. Затем я добавил графический интерфейс GNOME позже, когда у меня начались проблемы, упомянутые выше. Я заметил, что многие производители настроены на установку Windows. Графическая карта обычно настраивается для Win7 (NVIDIA OPTIMUS). Я перевел ее в интегрированный графический режим и больше никаких зависаний / ошибок. Как это сделать? Перезагрузите Thinkpad, нажав F1 или синюю кнопку ThinkVantage, чтобы войти в BIOS. Перейдите к графике, выберите встроенную графику, затем нажмите F10 для сохранения и выхода. Для этой карты есть 3 параметра: Integrated, Discrete и NVIDIA OPTIMUS (только для Win7?). Надеюсь, это сэкономит кому-то время?


Вздох, как и во всем остальном, установка вещей отдельно - нет-нет. Вернемся к раздутой настольной версии с Office и прочей
ерундой
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.