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)". Здається, віртуалізується із Ксеном.

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) cumul кількість м'яких блокувань.

Наступний приклад показує , гістограма тривалості (як довго господар застряг) тривалість гістограми.


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

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

Відповіді:


11

У мене також є проблема на Xen 4.2 з ядром 3.6 та 3.8 (AlpineLinux).

Я погуляв навколо, додавши Clocksource = jiffies до свого ядра, я його виправив. Замість джиффі ви також можете спробувати "піт".

Також є повідомлення про відключення C-станів у BIOS .


4
Що роблять ці параметри ядра?
Бурхан Алі

2
Тактовий ресурс мені здається досить очевидним, а c-state - це потужність процесора.
Франц Беттаг

+1. Відключення c-станів працювало на мене.
Ендрю Енслі

2

У мене була така ж проблема з моїм Thinkpad T520. Але замість злому ядра я зробив щось більш просте. По-перше, я використовую Centos7, я встановив базову систему, і все працювало чудово. Потім я додав GNOME GUI пізніше, коли я почав отримувати згадані вище проблеми. Зауважую, що багато виробників налаштовано на встановлення Windows. Графічна карта налаштовується зазвичай для Win7 (NVIDIA OPTIMUS). Я скидаю її на інтегрований графічний режим і більше не висить / помилок. Як це зробити? Перезавантажте клавішу F1 або синю кнопку Thinkvantage, щоб потрапити в BIOS. Для переходу до графіки виберіть інтегровану графіку, потім F10, щоб зберегти та вийти. Для цієї картки є 3 налаштування: інтегрована, дискретна та NVIDIA OPTIMUS (лише для Win7?) Сподіваюся, що це економить когось деякий час?


Зітхайте, як і в основному все інше, встановлювати речі окремо - це ні-ні. Назад до
роздутої
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.