replicant Опубликовано 29 января, 2013 (изменено) · Жалоба Есть несколько серверов, выполняющих задачи авторизации абонентов по 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%. Вопрос: Что делать и куда бежать (а может просто забить)? Изменено 29 января, 2013 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 29 января, 2013 · Жалоба replicant Соберите ядро из последних и попробуйте на нём, 99% что поможет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 29 января, 2013 (изменено) · Жалоба replicant Соберите ядро из последних и попробуйте на нём, 99% что поможет Ну как бы 3.2.37 тоже не старое ядро. Вышло только 2013-01-16. Или 3.7.х предлагаете? Как бы новых глюков на новом ядре не словить. Изменено 29 января, 2013 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 30 января, 2013 · Жалоба replicant Соберите ядро из последних и попробуйте на нём, 99% что поможет Ну как бы 3.2.37 тоже не старое ядро. Вышло только 2013-01-16. Или 3.7.х предлагаете? Как бы новых глюков на новом ядре не словить. Мы же о ванильных ядрах говорим? Ну так в них в старые ветки не портируют все багфиксы и важные изменения, сделанные в новых, это вам не redhat, у которого ядро может называться 2.6.32, а включать в себя самые последние коммиты Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 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.х. Короче говоря буду проверять. Скорее всего придется опытным путем искать источник ошибки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 30 января, 2013 · Жалоба + еще одно наблюдение Все машины, где наблюдается баг имеют Xeon более старых серий на чипсетах i3400 и i5520 и прошли обновление до ядра 3.2.35 или 37, после чего был зафиксирован баг. Такие же машины, где обновление с ядер 3.2.10-14 произведено не было с этим багом замечены не были ни разу. На Xeon E3-E5 и чипсетах C202-602 установка из того же самого образа прошла успешно и такая проблема за более чем 2 месяца работы этих машин не встречалась. Это опять наводит на мысль что баг при использовании ранних моделей CPU-Chipset возник в последних версиях ядра в связи с выходом 3.7.х, если верить changelog. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 30 января, 2013 (изменено) · Жалоба В ядре 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 Или я что-то не так понял? Изменено 30 января, 2013 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...