[BETEPAH]

Пытаюсь ввести в строй новый сервер такого состава:

Материнка: MBD-X9DRH-IF-O Supermicro - 1шт.

Проц: Intel Xeon E5-2680W - 2 шт.

Сетевые: Intel x540-T1 - 2 шт.

Centos 6.3 x64, роутер, шейпинг и доступ клиентов в инет через iptables.

 

С дровами которые шли из коробки 3.6.7 отработал час, потом кернел паник. Скачал с интела последние дрова под сетевухи 3.12.

Отработал часов 5 и опять кернел паник. Потом только увидел, что в реадми написано, что надо отключить LRO и GRO.

Отключил. Опять отработал около 5 часов и опять кернел паник. Сфоткал на всякий случай, что при этом написано.

Я в этом ничего не понимаю.

Помогите, меня клиенты съедят. Может и не в сетевухах дело.

Пробовал нагружать в пару потоков iperf. Больше суток отработал нормально. Всё-таки не та нагрузка, которую

создают пара тысяч человек. Мемтестом сутки гонял - тоже ничего не выявил. Даже не знаю что делать. :(

Edited February 6, 2013 by BETEPAH

[replicant]

Менять ядро. Собирать самому и искать стабильное по данное железо. Такое бывает не только с шейпингом, а и просто при форвардинге трафика.

 

Стабильными себя показали в этом вопросы 3.2.х, 3.7.х.

 

И что характерно в тестах ничего уронить тоже не удавалось и высер ядра в консоль выглядел практически как в Вашем случае.

Edited February 6, 2013 by replicant

[zurz]

возможен косяк с криво прописанным APIC на супермикре, который от сетевухи не зависит в принципе.

[BETEPAH]

replicant

Спасибо за наводку. Никогда бы не подумал, у меня на старом роутере ядро 2.6.18 работало и никаких проблем.

 

Поставил 3.7.6, аптайм уже 11 часов, вроде не падает. Посмотрим дальше.

[replicant]

возможен косяк с криво прописанным APIC на супермикре, который от сетевухи не зависит в принципе.

Мимо денег. К тому же сетевухи отдельные вроде как.

[replicant]

replicant

Спасибо за наводку. Никогда бы не подумал, у меня на старом роутере ядро 2.6.18 работало и никаких проблем.

Аналогично и мы работали на 2.6.32.х, но заметил одну особенность. Они стабильны были на старом железе. Т.е. если какой-то Intel Core Quad Q9400 и мамка под него на socket 775 и старым чипсетом, то проблем никаких.

 

Как только ушли на E3-E5 Xeon и новые чипы С202-602, то началось массовое помешательство, хотя справедливости ради замечу, что у меня периодичность вывалов была где-то 10-20 дней, но все равно неприятно. Причем сервера типа web/mysql и др. на 2.6.32.х, где нет огромных потоков трафика от сотен и тысяч разных IP адресов, стабильны уже не один год, хотя железо там тоже обновлялось.

Edited February 8, 2013 by replicant

[BETEPAH]

Рано обрадовался. Аптайм 4 дня, кернел паник нету. Но непонятно почему прерывания загружают два 8-ядерника в полку, даже счас утром, когда нагрузка никакая. На старом роутере один 4-ядерник только ночью загружен в 100%, конфигурация шейперов и iptables абсолютно одинаковая. Куда дальше копать? Ядро попробовал 3.0.62 поставить. То же самое, 5 минут нормальной работы и загрузка процов процентов 5-10. Потом резко ksoftirqd все 16 ядер кладёт в полку.

Edited February 11, 2013 by BETEPAH

[NiTr0]

oprofile

[martini]

а что там крутится ? нат, фаервол, шейпер ?... хоть чтото опиши

[micol]

Acpi вырубить в ядре пересборкой, intelовские приблуды типа турбо и прочих регуляторов частоты и экономии энергии выключать в биосе

 

Но это все тюнинг, у меня было нечто подобное. Если память не изменяет проблема была в кривой поддержке mq qdisc в tc

Остался на 2.6.39 кастомно-собранном.

[BETEPAH]

martini

я в самом начале описал, tc + iptables, без ната, просто форвардинг

 

 

 

CPU: Intel Sandy Bridge microarchitecture, speed 2700.23 MHz (estimated)

Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000

CPU_CLK_UNHALT...|

samples| %|

------------------

1982293 99.8246 no-vmlinux

1143 0.0576 libc-2.12.so

724 0.0365 libdns.so.81.4.1

379 0.0191 oprofiled

331 0.0167 ld-2.12.so

287 0.0145 libisc.so.83.0.3

260 0.0131 bash

111 0.0056 named

CPU_CLK_UNHALT...|

samples| %|

------------------

106 95.4955 named

5 4.5045 [vdso] (tgid:1822 range:0x7fff531b7000-0x7fff531b8000)

108 0.0054 libpthread-2.12.so

42 0.0021 grep

36 0.0018 tc

14 7.1e-04 gawk

6 3.0e-04 sshd

4 2.0e-04 libc-2.12.so

4 2.0e-04 sudo

4 2.0e-04 ntpd

3 1.5e-04 ld-2.12.so

3 1.5e-04 libdl-2.12.so

3 1.5e-04 libcrypto.so.1.0.0

2 1.0e-04 libipset.so.2.0.0

1 5.0e-05 ls

1 5.0e-05 sleep

1 5.0e-05 libpthread-2.12.so

1 5.0e-05 libaudit.so.1.0.0

1 5.0e-05 libpam.so.0.82.2

1 5.0e-05 libpcre.so.0.0.1

1 5.0e-05 libplc4.so

1 5.0e-05 libresolv-2.12.so

1 5.0e-05 libselinux.so.1

1 5.0e-05 pam_env.so

1 5.0e-05 utm5_rfw

CPU_CLK_UNHALT...|

samples| %|

------------------

1 100.000 [vdso] (tgid:2230 range:0xf77c3000-0xf77c4000)

1 5.0e-05 rsyslogd

1 5.0e-05 ophelp

1 5.0e-05 tr

1 5.0e-05 libgmp.so.3.5.0

1 5.0e-05 libnetsnmpagent.so.20.0.0

1 5.0e-05 libnss3.so

1 5.0e-05 dhcrelay

1 5.0e-05 ipset

Edited February 12, 2013 by BETEPAH

[BETEPAH]

удалось кое как установить perf, вот что он показал:

и что с этим _raw_spin_lock делать?

[replicant]

Что-то между процессорами неладно. Это как бы отсылает нас в RCU. У меня было что-то похожее, но сервак не вис, а просто сыпал багами. Помогла замена ядра на 3.7.5 и 3.7.6, а уже вышло 3.7.7.

 

А прерывания сетевых точно развешены на ядра корректно?

 

cat /proc/interrupts что показывает?

[BETEPAH]

Для прерываний брал скрипт отсюда: http://forum.nag.ru/forum/index.php?showtopic=81814&view=findpost&p=798171, распределились

прерывания как в этом же посте в примере.

 

Самое интересное, что счас в качестве эксперимента, снял один камень, память соотвественно на 1 проц переставил,

сетевухи тоже обе повесил на канал pci-e от этого проца, картина совершенно не изменилась, этот _raw_spin_lock опять в топе.

Edited February 12, 2013 by BETEPAH

[BETEPAH]

В четверг, когда только обновился на 3.7.6 и аптайм был почти 4 часа картина была такая:

 

top - 14:12:52 up  3:53,  2 users,  load average: 0.05, 0.12, 0.08
Tasks: 177 total,   1 running, 176 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us,  0.0%sy,  0.0%ni, 95.1%id,  0.0%wa,  0.0%hi,  4.9%si,  0.0%st
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni, 95.7%id,  0.0%wa,  0.0%hi,  4.3%si,  0.0%st
Cpu2  :  0.5%us,  0.0%sy,  0.0%ni, 92.7%id,  0.0%wa,  0.0%hi,  6.8%si,  0.0%st
Cpu3  :  0.0%us,  0.0%sy,  0.0%ni, 94.7%id,  0.0%wa,  0.0%hi,  5.3%si,  0.0%st
Cpu4  :  0.4%us,  0.0%sy,  0.0%ni, 93.4%id,  0.0%wa,  0.0%hi,  6.1%si,  0.0%st
Cpu5  :  0.4%us,  0.0%sy,  0.0%ni, 94.1%id,  0.0%wa,  0.0%hi,  5.5%si,  0.0%st
Cpu6  :  0.4%us,  0.0%sy,  0.0%ni, 95.4%id,  0.0%wa,  0.0%hi,  4.1%si,  0.0%st
Cpu7  :  0.4%us,  0.0%sy,  0.0%ni, 95.1%id,  0.0%wa,  0.0%hi,  4.5%si,  0.0%st
Cpu8  :  0.0%us,  3.3%sy,  0.0%ni, 90.1%id,  0.0%wa,  0.0%hi,  6.6%si,  0.0%st
Cpu9  :  0.4%us,  0.0%sy,  0.0%ni, 94.5%id,  0.0%wa,  0.0%hi,  5.1%si,  0.0%st
Cpu10 :  0.5%us,  0.0%sy,  0.0%ni, 93.6%id,  0.0%wa,  0.0%hi,  5.9%si,  0.0%st
Cpu11 :  0.4%us,  0.0%sy,  0.0%ni, 93.8%id,  0.0%wa,  0.0%hi,  5.7%si,  0.0%st
Cpu12 :  0.4%us,  0.0%sy,  0.0%ni, 94.2%id,  0.0%wa,  0.0%hi,  5.3%si,  0.0%st
Cpu13 :  0.0%us,  0.0%sy,  0.0%ni, 94.8%id,  0.0%wa,  0.0%hi,  5.2%si,  0.0%st
Cpu14 :  0.0%us,  0.9%sy,  0.0%ni, 91.7%id,  0.0%wa,  0.0%hi,  7.4%si,  0.0%st
Cpu15 :  0.0%us,  0.0%sy,  0.0%ni, 95.1%id,  0.0%wa,  0.0%hi,  4.9%si,  0.0%st
Mem:  16505204k total,   677956k used, 15827248k free,    17856k buffers
Swap:  8388604k total,        0k used,  8388604k free,   183484k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
29875 root      20   0 15072 1384  996 S  4.3  0.0   6:46.56 top
1857 named     20   0 1257m  42m 2724 S  4.0  0.3   1:40.04 named
  48 root      20   0     0    0    0 S  1.0  0.0   0:45.85 ksoftirqd/8
  23 root      20   0     0    0    0 S  0.3  0.0   0:27.77 ksoftirqd/3
  28 root      20   0     0    0    0 S  0.3  0.0   0:19.50 ksoftirqd/4
  49 root      RT   0     0    0    0 S  0.3  0.0   0:15.59 migration/8
  68 root      20   0     0    0    0 S  0.3  0.0   0:17.77 ksoftirqd/12
  73 root      20   0     0    0    0 S  0.3  0.0   0:16.40 ksoftirqd/13
  98 root      20   0     0    0    0 S  0.3  0.0   0:02.90 kworker/1:1
   1 root      20   0 19276 1528 1256 S  0.0  0.0   0:01.64 init
   2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd
   3 root      20   0     0    0    0 S  0.0  0.0   0:12.16 ksoftirqd/0
   5 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 kworker/0:0H
   7 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 kworker/u:0H

 

14:13:22        IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
14:13:23         eth0  75407,79 102315,58  27497,33 118698,11      0,00      0,00      0,00
14:13:23         eth1 102989,61  75506,49 119686,62  27473,74      0,00      0,00      0,00
14:13:23           lo      0,00      0,00      0,00      0,00      0,00      0,00      0,00

 

 

Этот сервер просто постоял в работе и начал через пару суток тупить. А теперь такая хрень, сразу после загрузки. :(

Edited February 12, 2013 by BETEPAH

[replicant]

Как совет. Вдруг поможет.

 

Отключите HT (hyper threading) в BIOS. Понятно что кол-во ядер уменьшится вдвое, но с чего-то надо начинать искать.

 

Второй процессор при этом верните физически на место. У себя на двухпроцессорных конфигурациях (правда процы под s1366) отключаю HT.

Edited February 12, 2013 by replicant

[BETEPAH]

первым делом отключил, прежде чем даже линух установил

[kayot]

Contrack отключен(выгрузкой модуля или просто -j NOTRACK)?

Кучи линейных правил в iptables нет?

Для tc конфигурация нормальная, с хешами?

 

IMHO ksoftirqd выжирающий ресурсы - всегда явное указание на проблемы с софтом, начиная с какого-то pps пакет просто не успевает обрабатываться фаерволом и шейпером до момента приема следующего, сетевая система переходит в режим поллинга и идет лавинообразный рост загрузки. Именно из-за этого у вас и не поменялась картина после замены 4ех ядерного CPU на 8/16, система захлебывается точно так же, но на(к примеру) 20% большем трафике.

Edited February 12, 2013 by kayot

[BETEPAH]

kayot

я не понимаю одного, почему сервер отработал какое-то количество времени не тормозя, пару постами выше я показал загрузку после 4 часов работы, а потом начал тупить?

[kayot]

BETEPAH

Ну если contrack не выкошен - возможно таблица выросла до сотен тысяч и внесла свой вклад.

[replicant]

BETEPAH

Ну если contrack не выкошен - возможно таблица выросла до сотен тысяч и внесла свой вклад.

Conntrack-то тут причем. Он при простом роутинге вообще не при делах, даже если несколько тысяч там будет в count. NAT на сервере отсутствует.

 

Конечно проверить sysctl -a | grep conntrack_count, но как-то навряд ли это оно.

 

Между прочим -j NOTRACK на маршрутизирующих девайсах как бы не стоит делать на все подряд. Для какого-нибудь web-сервера оно самое то, если какой-то умник там ipv4 forwarding включил, но не для форвардинга трафика.

------------------

 

Допустим у меня есть машина, которая стоит без NAT и даже без tc и просто форвардит сети через себя с интерфейса на интерфейс в обе стороны. Есс-но включен ipv4 forwarding.

 

В iptables в цепочке FORWARD действие по умолчанию ACCEPT.

 

Т.е. в iptables может вообще не быть никаких правил, чтобы такая конфигурация работала. Для очистки совести можете ввести

 

iptables -I FORWARD -m state --state INVALID -j DROP, чтобы инвалиды дропались на форварде.

 

Зачем тут -j NOTRACK и в какое место его вставлять?

Edited February 12, 2013 by replicant

[BETEPAH]

conntrack_count максимум я видел около 300 тысяч, conntrack_max установлен в 1.5 миллионов записей

я тоже думаю, что это непричём, такое ощущение, что где-то на уровне железа глюки

 

если есть сомнения в iptables, то вчера ipset прикрутил и теперь выглядит вот-так

# Generated by iptables-save v1.4.7 on Tue Feb 12 15:05:28 2013
*mangle
:PREROUTING ACCEPT [94551138:130281272469]
:INPUT ACCEPT [411:46229]
:FORWARD ACCEPT [94550727:130281226240]
:OUTPUT ACCEPT [399:32616]
:POSTROUTING ACCEPT [94551126:130281258856]
COMMIT
# Completed on Tue Feb 12 15:05:28 2013
# Generated by iptables-save v1.4.7 on Tue Feb 12 15:05:28 2013
*filter
:INPUT ACCEPT [410:46177]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [291:26136]
:bad_tcp_packets - [0:0]
:icmp_packets - [0:0]
-A INPUT -p tcp -j bad_tcp_packets
-A INPUT -p icmp -j icmp_packets
-A FORWARD -p icmp -j icmp_packets
-A FORWARD -p tcp -j bad_tcp_packets
-A FORWARD -m set --match-set USERS src -j ACCEPT
-A FORWARD -m set --match-set USERS dst -j ACCEPT
-A OUTPUT -p tcp -j bad_tcp_packets
-A bad_tcp_packets -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset
-A bad_tcp_packets -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A bad_tcp_packets -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 2/sec -j ACCEPT
-A bad_tcp_packets -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j ACCEPT
-A icmp_packets -p icmp -m length --length 530:65535 -j DROP
-A icmp_packets -p icmp -m icmp --icmp-type 8 -m limit --limit 2/sec -j ACCEPT
-A icmp_packets -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A icmp_packets -p icmp -m icmp --icmp-type 11 -j ACCEPT
COMMIT
# Completed on Tue Feb 12 15:05:28 2013

[kayot]

Ну если до этого был линейный просмотр юзерских ip в iptables - то после замены на ipset картина должна разительно поменяться.

А по контраку таки не согласен, любой маршрутизатор при его использовании раза в 2-3 больше ресурсов кушает(даже банальный модуль state как у ТСа, при больших размераз контрака это зло).

[Dark_Angel]

Разрешите встрять в ваш разбор: мне кажется, что дело в шейпере. Судя по перфу - классификатор вылез на второе место. Это не есть хорошо, "при хешах такого не было"(с). Ну и попробуйте следующую стратегию по диагностике проблемы: начинает тупить, начинайте отключать сервисами: шейпер, фаер. Полностью. И ждите минуту примерно, потому что как заметили верно ранее - машина накапливает снежный ком и чтобы выйти из состоянния softirq нужно какое-то время. То есть в ту же секунду может не полегчать.

 

Если будет тупить на простом роутинге, то надо менять ядро. Потому что первый в топе у перфа - _raw_spin_lock - это код ядра, который и является в вашем случае бутилочным горлышком. А вот кто зовет этот код - это вопрос, который, кстати, можно снова таки профайлером посмотреть.

 

У меня как-то такое было на супер-глючном 2.6.32 ядре, которое такое вытворяло на 1-2 Мбит/с трафика в при использовании IPSec. Но в моем случае по профайлеру сразу стало ясно откуда ноги растут. После смены на 3.2.23 - всё стало замечательно. Новым ядрам старше - я пока не верю. Там какое-то феерическое количество граблей для роутеров.

[BETEPAH]

Прикрутил хеши. Аптайм 10 часов. Вроде всё нормально.

Только я одного понять не могу. Да, не было ipset, но правила группировались. Шейпер был линейным. НО старый сервер в несколько раз слабее нового и в принципе справлялся, а тут та же конфигурация правил, но при копеечной загрузке канала, процы в полку. Я бы ещё понял, если бы в perf вылазил бы в топ iptables или u32, а тут какой-то _raw_spin_lock. И появилась эта хрень не сразу, а спустя время.

 

P.S.: зато наконец-то руки дошли до хешей :)