replicant Posted January 29, 2013 Posted January 29, 2013 (edited) Есть несколько серверов, выполняющих задачи авторизации абонентов по pptp (accel-ppp), но судя по всему это к делу не относится. Конфиг примерно таков: # lspci (частичная выборка) 00:1a.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05) 00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 (rev 05) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a5) 00:1f.0 ISA bridge: Intel Corporation 3400 Series Chipset LPC Interface Controller (rev 05) 00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 6 port SATA AHCI Controller (rev 05) 00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 05) 01:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) 01:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) 05:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 07:05.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family (rev 10) # uname -a Linux 3.2.37 #1 SMP Sat Jan 26 15:26:53 MSK 2013 x86_64 Intel(R) Xeon(R) CPU X3470 @ 2.93GHz GenuineIntel GNU/Linux Машин таких несколько. Периодически на одной из таких машин возникает такое: [76560.772957] INFO: rcu_sched detected stalls on CPUs/tasks: { 4} (detected by 5, t=60002 jiffies) [76560.772964] Pid: 0, comm: swapper/5 Tainted: G O 3.2.37 #1 [76560.772965] Call Trace: [76560.772966] <IRQ> [<ffffffff810ad9b5>] __rcu_pending+0x415/0x420 [76560.772974] [<ffffffff810addbf>] rcu_check_callbacks+0x7f/0x1c0 [76560.772977] [<ffffffff81060778>] update_process_times+0x48/0x90 [76560.772980] [<ffffffff810824f6>] tick_sched_timer+0x66/0xc0 [76560.772983] [<ffffffff8107562f>] __run_hrtimer+0x7f/0x1c0 [76560.772985] [<ffffffff81082490>] ? tick_nohz_handler+0xf0/0xf0 [76560.772987] [<ffffffff81075fb7>] hrtimer_interrupt+0xf7/0x220 [76560.772991] [<ffffffff81552b79>] smp_apic_timer_interrupt+0x69/0x99 [76560.772993] [<ffffffff8155194b>] apic_timer_interrupt+0x6b/0x70 [76560.772994] <EOI> [<ffffffff812f965a>] ? intel_idle+0xea/0x150 [76560.772998] [<ffffffff812f9638>] ? intel_idle+0xc8/0x150 [76560.773001] [<ffffffff81433759>] cpuidle_idle_call+0xc9/0x230 [76560.773003] [<ffffffff8100096a>] cpu_idle+0xaa/0x110 [76560.773006] [<ffffffff815405ba>] start_secondary+0x1cf/0x1d6 [76560.781953] INFO: rcu_bh detected stalls on CPUs/tasks: { 4} (detected by 7, t=60002 jiffies) [76560.781958] Pid: 0, comm: swapper/7 Tainted: G O 3.2.37 #1 [76560.781961] Call Trace: [76560.781962] <IRQ> [<ffffffff810ad9b5>] __rcu_pending+0x415/0x420 [76560.781968] [<ffffffff810ade0b>] rcu_check_callbacks+0xcb/0x1c0 [76560.781971] [<ffffffff81060778>] update_process_times+0x48/0x90 [76560.781974] [<ffffffff810824f6>] tick_sched_timer+0x66/0xc0 [76560.781977] [<ffffffff8107562f>] __run_hrtimer+0x7f/0x1c0 [76560.781980] [<ffffffff81082490>] ? tick_nohz_handler+0xf0/0xf0 [76560.781982] [<ffffffff81075fb7>] hrtimer_interrupt+0xf7/0x220 [76560.781986] [<ffffffff81552b79>] smp_apic_timer_interrupt+0x69/0x99 [76560.781988] [<ffffffff8155194b>] apic_timer_interrupt+0x6b/0x70 [76560.781990] <EOI> [<ffffffff812f965a>] ? intel_idle+0xea/0x150 [76560.781994] [<ffffffff812f9638>] ? intel_idle+0xc8/0x150 [76560.781997] [<ffffffff81433759>] cpuidle_idle_call+0xc9/0x230 [76560.782000] [<ffffffff8100096a>] cpu_idle+0xaa/0x110 [76560.782002] [<ffffffff815405ba>] start_secondary+0x1cf/0x1d6 При этом машина не падает, не виснет, никак не подает признаков глюка, а просто работает как всегда периодически гадя в dmesg. Абоненты авторизуются, трафик считается, все корректно шейпится и т.п. Ни малейшего признака влияния на что либо. Нагрузка на машину тоже не запредельная. В пиках около 10% CPU. В трафике от 25 до 40 Мбайт/с вход и около 15-25 Мбайт/с выход. Авторизованных абонентов около 500-600. Т.е. ничего подозрительного нет. Курил долго и нудно Гуглы и т.п. Упоминается какой-то патч для ядер 2.6.3х, но это что-то не то. Долго читал документ http://www.kernel.org/doc/Documentation/RCU/stallwarn.txt Что-то понял, но так и не уловил в каком месте в ядре надо что-то включить/выключить, чтобы такого не было вообще или просто не показывалось. Поскольку машин таких несколько, а глюки бывают только на двух из четырех, то диагностировать проблему еще сложнее в силу того факта, что ОС+ПО клонированы с единого первоначального образа, т.е. отличия в конфигурациях ядра и т.п. я даже искать не буду, потому что их нет (кроме нескольких паролей в конфигах и ip адресов интерфейсов). Единственно что отметил - это вялость абонентских коннекций к проблемному серверу. Поясню на примере. Есть зона в DNS в ней несколько A записей на одно имя для нескольких разных IP. Т.е. если абоненты обращаются к серверу по имени, то раскидывание абонентов примерно равномерное. Однако на серверах с подобным мусором в dmesg об ошибках абонентов соединено меньше процентов на 35-40%, что никак нельзя отнести к погрешностям статистического распределения. Однако присоединенные к проблемному серверу абоненты не фиксируют никаких проблем. У них все работает. Почему на проблемный сервер приходит меньше коннекций тоже не понятно. Соответственно на безпроблемных серверах коннекций примерно поровну с некоторой погрешностью 1-2%, но не более и никак не 40%. Вопрос: Что делать и куда бежать (а может просто забить)? Edited January 29, 2013 by replicant Вставить ник Quote
s.lobanov Posted January 29, 2013 Posted January 29, 2013 replicant Соберите ядро из последних и попробуйте на нём, 99% что поможет Вставить ник Quote
replicant Posted January 29, 2013 Author Posted January 29, 2013 (edited) replicant Соберите ядро из последних и попробуйте на нём, 99% что поможет Ну как бы 3.2.37 тоже не старое ядро. Вышло только 2013-01-16. Или 3.7.х предлагаете? Как бы новых глюков на новом ядре не словить. Edited January 29, 2013 by replicant Вставить ник Quote
s.lobanov Posted January 30, 2013 Posted January 30, 2013 replicant Соберите ядро из последних и попробуйте на нём, 99% что поможет Ну как бы 3.2.37 тоже не старое ядро. Вышло только 2013-01-16. Или 3.7.х предлагаете? Как бы новых глюков на новом ядре не словить. Мы же о ванильных ядрах говорим? Ну так в них в старые ветки не портируют все багфиксы и важные изменения, сделанные в новых, это вам не redhat, у которого ядро может называться 2.6.32, а включать в себя самые последние коммиты Вставить ник Quote
replicant Posted January 30, 2013 Author Posted January 30, 2013 Мы же о ванильных ядрах говорим? Ну так в них в старые ветки не портируют все багфиксы и важные изменения, сделанные в новых, это вам не redhat, у которого ядро может называться 2.6.32, а включать в себя самые последние коммиты Это известно, но речь о клонированных системах с единого образа. Две машины не сбоят, а две сбоят. Вот я и думаю что проблема не в версии ядра, а чуть ли даже не в аппаратных различиях, хотя о каких аппаратных различиях можно говорить, если платформа типа SuperMicro 1U 2in1 (т.е. два одинаковых сервака в одном коробке). Я конечно подготовил ядро 3.7.5 и ночью проведу замену, но думается надо копать в другую сторону. Changelog прочитал от ветки 3.2.13 до 3.2.37 и еще по моим наблюдениям 3.2.10-14 с таким багом не сталкивались (стоит в одной из стоек три таких тазика с аптаймом почти год и тишина), а вылез он на 3.2.35 и выше (его могли породить рожая в муках 3.7.х на основе ранних веток). И еще прочитал то же самое от ветки 3.7.1 до 3.7.5, что-то на тему rcu там проскакивало, но это же было и в 3.2.3х. Это я к тому, что 3.7.5 может оказаться не лекарством, а наоборот и откатываться надо вниз по 3.2.х. Короче говоря буду проверять. Скорее всего придется опытным путем искать источник ошибки. Вставить ник Quote
replicant Posted January 30, 2013 Author Posted January 30, 2013 + еще одно наблюдение Все машины, где наблюдается баг имеют Xeon более старых серий на чипсетах i3400 и i5520 и прошли обновление до ядра 3.2.35 или 37, после чего был зафиксирован баг. Такие же машины, где обновление с ядер 3.2.10-14 произведено не было с этим багом замечены не были ни разу. На Xeon E3-E5 и чипсетах C202-602 установка из того же самого образа прошла успешно и такая проблема за более чем 2 месяца работы этих машин не встречалась. Это опять наводит на мысль что баг при использовании ранних моделей CPU-Chipset возник в последних версиях ядра в связи с выходом 3.7.х, если верить changelog. Вставить ник Quote
replicant Posted January 30, 2013 Author Posted January 30, 2013 (edited) В ядре 3.7.х появилось такое предупреждение: [ 6.340945] nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead. Т.е. насколько я понимаю, то скоро придется делать так: iptables -t raw -A OUTPUT -p tcp --dport 21 -j CT --helper ftp или iptables -A PREROUTING -p tcp --dport 6667 -j CT --helper irc iptables -A PREROUTING -p tcp --dport 6566 -j CT --helper sane Или я что-то не так понял? Edited January 30, 2013 by replicant Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.