 зависание Linux, rcu_sched detected stalls on CPUs/tasks, SMP,  maxnetstat, 02-Окт-18, 11:43 [смотреть все]Добрый день!
Прошу помощи в решении проблемы.
Сам уже более недели не могу с ней справится.Столкнулся с проблемой периодического подвисания сервера. #---------------
Данные о железе:
CPU: Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz (8 ядер)
MotherBoard: SuperMicro X11SSL-F
RAM: 8GB DDR4-2400 ECC Unbuffered Supermicro certified for Intel C232, C236 chipsets
Сеть: Intel 82599 10 Gigabit Network Connection
driver: ixgbe
version: 3.15.1-k #---------------
Данные об ОС:
Debian 7.2
kernel 3.12.6 #---------------
Краткое описание сферы использования сервера:
Сервер используется как маршрутизатор (Quagga),
нагрузка на него сейчас небольшая - порядка 500-600 Мбит/с.
Планируется довести до 4-5 Гбит/с. #---------------
Симптомы подвисания сервера:
Перестает отвечать на ICMP запросы и отдавать данные по SNMP (это со стороны системы мониторинга).
Также прекращает маршрутизировать трафик, BGP сессии, которые висят на нем также отваливаются.
Через 3-5 минут сервер "приходит в себя" и продолжает работать, при это периодически давая на себя задержки. В dmesg в эти моменты вижу большое количество сообщений типа: kernel: [283813.064128] INFO: rcu_sched detected stalls on CPUs/tasks: { 1} (detected by 2, t=5252 jiffies, g=22131346, c=22131345, q=6300)
kernel: [283813.064332] sending NMI to all CPUs:
kernel: [283813.064335] NMI backtrace for cpu 2
kernel: [283813.064337] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 3.12.6.ipset-amd64 #3
kernel: [283813.064337] Hardware name: Supermicro Super Server/X11SSL-F, BIOS 2.2 05/23/2018
kernel: [283813.064339] task: ffff88026e0fc7e0 ti: ffff88026e12e000 task.ti: ffff88026e12e000
kernel: [283813.064340] RIP: 0010:[<ffffffff811b8008>] [<ffffffff811b8008>] kasprintf+0x43/0x43
kernel: [283813.064343] RSP: 0018:ffff880277883cc8 EFLAGS: 00000046
kernel: [283813.064344] RAX: 0000000000000000 RBX: 0000000000002710 RCX: 0000000000000007
kernel: [283813.064345] RDX: 0000000000000006 RSI: 0000000000000200 RDI: ffffffff8167b570
kernel: [283813.064346] RBP: ffff88027788db00 R08: 0000000000000002 R09: 0000000000000000
kernel: [283813.064347] R10: 0000000000000000 R11: 0000000000002710 R12: ffffffff8163a600
kernel: [283813.064347] R13: 0000000000000001 R14: ffff88026e12e000 R15: ffffffff8163a6c0
kernel: [283813.064349] FS: 0000000000000000(0000) GS:ffff880277880000(0000) knlGS:0000000000000000
kernel: [283813.064349] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: [283813.064350] CR2: 00007fa7748bd6f0 CR3: 000000000160b000 CR4: 00000000003407e0
kernel: [283813.064351] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
kernel: [283813.064352] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
kernel: [283813.064352] Stack:
kernel: [283813.064353] ffffffff810245d2 ffffffff8163a600 ffffffff8109ca5f 00000000ffffffc0
kernel: [283813.064355] 000000000000189c 0000000000000083 0000000000000002 0000000000000000
kernel: [283813.064356] ffff88026e0fc7e0 0000000000000000 0000000000000002 ffff88027788d0f0
kernel: [283813.064357] Call Trace:
kernel: [283813.064358] <IRQ>
kernel: [283813.064358] [<ffffffff810245d2>] ? arch_trigger_all_cpu_backtrace+0x5e/0x80
kernel: [283813.064364] [<ffffffff8109ca5f>] ? rcu_check_callbacks+0x3e4/0x4c3
kernel: [283813.064366] [<ffffffff81079df2>] ? tick_sched_do_timer+0x25/0x25
kernel: [283813.064368] [<ffffffff8103f55c>] ? update_process_times+0x31/0x5c
kernel: [283813.064370] [<ffffffff81079b4a>] ? tick_sched_handle+0x32/0x3d
kernel: [283813.064371] [<ffffffff81079e22>] ? tick_sched_timer+0x30/0x4c
kernel: [283813.064373] [<ffffffff81051119>] ? __run_hrtimer+0xab/0x152
kernel: [283813.064375] [<ffffffff81051747>] ? hrtimer_interrupt+0xc5/0x1a7
kernel: [283813.064377] [<ffffffff810238d6>] ? smp_apic_timer_interrupt+0x27/0x37
kernel: [283813.064379] [<ffffffff81354fca>] ? apic_timer_interrupt+0x6a/0x70
kernel: [283813.064381] [<ffffffff81038c15>] ? __do_softirq+0x8a/0x201
kernel: [283813.064382] [<ffffffff81355a9c>] ? call_softirq+0x1c/0x30
kernel: [283813.064384] [<ffffffff81003b7c>] ? do_softirq+0x2c/0x60
kernel: [283813.064385] [<ffffffff81038e51>] ? irq_exit+0x3b/0x7f
kernel: [283813.064387] [<ffffffff81003803>] ? do_IRQ+0x81/0x98
kernel: [283813.064388] [<ffffffff8134e6aa>] ? common_interrupt+0x6a/0x6a
kernel: [283813.064389] <EOI>
kernel: [283813.064390] [<ffffffff812764b5>] ? cpuidle_enter_state+0x43/0xa6
kernel: [283813.064393] [<ffffffff812764ae>] ? cpuidle_enter_state+0x3c/0xa6
kernel: [283813.064397] [<ffffffff812765ea>] ? cpuidle_idle_call+0xd2/0x142
kernel: [283813.064399] [<ffffffff81008fdd>] ? arch_cpu_idle+0x6/0x17
kernel: [283813.064401] [<ffffffff8106d526>] ? cpu_startup_entry+0x11e/0x194
kernel: [283813.064402] [<ffffffff8134e354>] ? _raw_spin_unlock_irqrestore+0x6/0x7
kernel: [283813.064404] [<ffffffff8102232d>] ? start_secondary+0x1df/0x1e5
Насколько я понимаю, ядра периодически "стопорятся".
Прочитав: https://www.kernel.org/doc/Documentation/RCU/stallwarn.txt
решил что проблема в работе функций энергосбережения процессора. и поэтому я сделал:
- отключал в BIOS функции управления энергопотребления C-STATE, P-STATE.
- выгружал модуль acpi_cpufreq Никакого результата это не принесло.
Пробовал разнести прерывания таким образом, чтобы eth0 работал на одном ядре, но также не помогло. В итоге загрузил систему с опцией nosmp. Прошли сутки, с сервером проблем нет, но я теперь обладатель одноядерного процессора вместо 8 ядер.
на данный момент мне и 1 ядра хватает, но ведь это не решение проблемы... Может кто-то с чем-то подобным сталкивался?
Могут ли подобные симптомы возникнуть по вине оперативной памяти?
|
- зависание Linux, rcu_sched detected stalls on CPUs/tasks, SMP, eRIC, 07:19 , 03-Окт-18 (1)
> kernel: [283813.064128] INFO: rcu_sched detected stalls on CPUs/tasks: { 1} (detected by
> 2, t=5252 jiffies, g=22131346, c=22131345, q=6300)
> kernel: [283813.064332] sending NMI to all CPUs:
> kernel: [283813.064335] NMI backtrace for cpu 2 многие обходили эту панику через отключение ipv6 или nosmp. если есть возможность забустрапить свежий Debian и проверить на новом ядре, ну и свежим Quagga поиграть
- зависание Linux, rcu_sched detected stalls on CPUs/tasks, SMP, maxnetstat, 10:03 , 03-Окт-18 (2)
>> kernel: [283813.064128] INFO: rcu_sched detected stalls on CPUs/tasks: { 1} (detected by
>> 2, t=5252 jiffies, g=22131346, c=22131345, q=6300)
>> kernel: [283813.064332] sending NMI to all CPUs:
>> kernel: [283813.064335] NMI backtrace for cpu 2
> многие обходили эту панику через отключение ipv6 или nosmp. если есть возможность
> забустрапить свежий Debian и проверить на новом ядре, ну и свежим
> Quagga поиграть Спасибо за ответ:)
smp я отключил. но получил в итоге 1 ядро вместо 8.
ipv6 также отключен через sysctl. Обновить теоретически возможно, но на практике проблема в том,
что ОС уже подготовлена, обкатана в качестве маршрутизатора.
Данное решение используется на нескольких серверах, и обновление одного из них повлечет
ситуацию, когда одинаковые по функционалу сервера будут на разных версия ОС.
А это проблема, ведь они перестают быть взаимозаменяемыми и потребуется обновление всех
серверов :)
Возможно и стоит этим в итоге заняться, но подобные вещи должны планироваться, а на это времени пока нет.
Да и не принесет в целом профита. Того что есть с головой достаточно.
К тому же, такая же система установлена на другом сервере с процессором Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz, и там подобных проблем нет. Думаю попробовать сменить оперативную память (установлена DDR4-2400 ECC Unbuffered), т.к. натыкался в инете на то, что замена памяти решила проблему.
Но это уже скорее от того, что варианты "лечения" системы подходят к концу :)
- зависание Linux, rcu_sched detected stalls on CPUs/tasks, SMP, eRIC, 20:05 , 03-Окт-18 (3)
> Обновить теоретически возможно, но на практике проблема в том,
> что ОС уже подготовлена, обкатана в качестве маршрутизатора.
> Данное решение используется на нескольких серверах, и обновление одного из них повлечет
> серверов :) я не про обычное обновление всей системы писал, а про утилиту Debootstrap. посмотрите на утилиту эту на досуге, очень эффективная вещь в хозяйстве. > Думаю попробовать сменить оперативную память (установлена DDR4-2400 ECC Unbuffered),
> т.к. натыкался в инете на то, что замена памяти решила проблему. возможно, будем ждать ваших результатов ;)
- зависание Linux, rcu_sched detected stalls on CPUs/tasks, SMP, maxnetstat, 08:40 , 04-Окт-18 (4)
> я не про обычное обновление всей системы писал, а про утилиту Debootstrap.
> посмотрите на утилиту эту на досуге, очень эффективная вещь в хозяйстве. Знаю о ней, но никогда не использовал. Посмотрю, спасибо :) >> Думаю попробовать сменить оперативную память (установлена DDR4-2400 ECC Unbuffered),
>> т.к. натыкался в инете на то, что замена памяти решила проблему.
> возможно, будем ждать ваших результатов ;) К сожалению, пока нечем заменить память. Вчера мне подсказали отключить HyperThreading, но ее отключение не привело к положительным изменения.
Описываю все свои действия, вдруг кому пригодится:)
- зависание Linux, rcu_sched detected stalls on CPUs/tasks, SMP, asdmkw, 21:17 , 29-Апр-21 (6)
>> я не про обычное обновление всей системы писал, а про утилиту Debootstrap.
>> посмотрите на утилиту эту на досуге, очень эффективная вещь в хозяйстве.
> Знаю о ней, но никогда не использовал. Посмотрю, спасибо :)
>>> Думаю попробовать сменить оперативную память (установлена DDR4-2400 ECC Unbuffered),
>>> т.к. натыкался в инете на то, что замена памяти решила проблему.
>> возможно, будем ждать ваших результатов ;)
> К сожалению, пока нечем заменить память.
> Вчера мне подсказали отключить HyperThreading, но ее отключение не привело к положительным
> изменения.
> Описываю все свои действия, вдруг кому пригодится:) C-state отключен? Max performace, в bios, влючен?
Отключение powersave mode+throttling:
intel_idle.max_cstate=0 processor.max_cstate=0 intel_pstate=disable acpi=force powersaved=off(старье) Отключение watchdog-в и проверок, которые могут давать фризы:
mce=ignore_ce nmi_watchdog=0 nowatchdog Если отключен HT, то можно включить
idle=poll #температура будет повыше, но снижает задержки
cpuidle.off=1 Можно разобраться с балансировкой прерывайний, отключить динамику
acpi_irq_nobalance Отключить динамические прерывания, перейдя на старый режим
nohz=off Если хочется выжать максимум, то отключить фиксы безопасности:
mitigations=off (для >=4)
norandmaps(sysctl.conf: kernel.randomize_va_space = 0)
noibrs noibpb nopti nospectre_v1 nospectre_v2 l1tf=off spectre_v2_user=off nospec_store_bypass_disable no_stf_barrier mds=off spectre_v2=off Дальше уже тюнить параметры сетевухи через ethtool, распределять их по ядрам(numa etc). Посмотреть в сторону busy pools:
#net.core.busy_poll = 100
#net.core.busy_read = 100
- зависание Linux, rcu_sched detected stalls on CPUs/tasks, SMP, maxnetstat, 11:14 , 30-Апр-21 (7)
>[оверквотинг удален]
> nohz=off
> Если хочется выжать максимум, то отключить фиксы безопасности:
> mitigations=off (для >=4)
> norandmaps(sysctl.conf: kernel.randomize_va_space = 0)
> noibrs noibpb nopti nospectre_v1 nospectre_v2 l1tf=off spectre_v2_user=off nospec_store_bypass_disable
> no_stf_barrier mds=off spectre_v2=off
> Дальше уже тюнить параметры сетевухи через ethtool, распределять их по ядрам(numa etc).
> Посмотреть в сторону busy pools:
> #net.core.busy_poll = 100
> #net.core.busy_read = 100 Спасибо за информацию!
Добавлю в закладки и в случае необходимости опробую ваши советы!
на данный момент проблема решена переходом на аппаратные маршрутизаторы (не из-за этой проблемы)
|
Версия для распечатки
