[heap]

Кто-нибудь использует сабжевые ядра на роутерах с NAT?

Периодически (на глазок примерно раз в неделю) ядро валится в панику. Как правило, наблюдается среди прочего в дампе вызов kmem_cache_alloc или kmalloc. В двух случая обратил внимание, что происходила проблема в дереве вызовов conntrack, а именно __nf_conntrack_alloc. Есть еще у кого-то подобные проблемы?

[nuclearcat]

Я, работает нормально, причем и 11.x и 12.x. Паник не бывало вообще, нагрузка около гигабита.

Все зависит какие features вы используете кроме NAT и каким компилятором собрано ядро.

И проверьте память. Китайцы выбросили на рынок как минимум паленые чипы kingston, которые при сильно нагрузке начинают "сыпаться" и на тестах проблема детектится плохо. Уже три раза на эти грабли наступил, причем в одном из случаев память должна была быть ECC и не помогло. В случае десктопной помогла замена на другого производителя.

[heap]

Я, работает нормально, причем и 11.x и 12.x. Паник не бывало вообще, нагрузка около гигабита.

Все зависит какие features вы используете кроме NAT и каким компилятором собрано ядро.

И проверьте память. Китайцы выбросили на рынок как минимум паленые чипы kingston, которые при сильно нагрузке начинают "сыпаться" и на тестах проблема детектится плохо. Уже три раза на эти грабли наступил, причем в одном из случаев память должна была быть ECC и не помогло. В случае десктопной помогла замена на другого производителя.

 

Да память, конечно, вариант, но сервер не новый - до обновления не замечалось подобного (ранее ездило под 3.0.х). Сейчас откатил на 3.4.х ради эксперимента. А другие фичи - вопрос интересный, но очень смущает что в двух паниках расклад крутился именно вокруг аллокейта для conntrack. Буду наблюдать.

[nuclearcat]

А что за сетевуха?

Может быть драйвер и offloading какой-то.

Я всегда делаю:

ethtool -K eth0 gso off gro off tso off

Сколько соединений в час пик - максимум?

[Antares]

Перешёл на 3.11.6 ядро недавно, uptime 24 дня, полёт нормальный. Трафика чуть больше гига к абонентам. Нагрузка на ядра упала с 40 до 15 процентов, но подрос LA, правда не сильно, нозаметно. На 3.0.x LA можно сказать не было вообще

[heap]

А что за сетевуха?

Может быть драйвер и offloading какой-то.

Я всегда делаю:

ethtool -K eth0 gso off gro off tso off

Сколько соединений в час пик - максимум?

 

При загрузке:

/sbin/ethtool -G eth0 rx 2040
/sbin/ethtool -G eth1 rx 2040
/sbin/ethtool -G eth2 rx 4096 tx 4096
/sbin/ethtool -G eth3 rx 4096 tx 4096
/sbin/ethtool -G eth4 rx 4096 tx 4096
/sbin/ethtool -G eth5 rx 4096 tx 4096

/sbin/ethtool -K eth0 sg off tso off gso off gro off tx-nocache-copy off
/sbin/ethtool -K eth1 sg off tso off gso off gro off tx-nocache-copy off
/sbin/ethtool -K eth2 sg off tso off gso off gro off lro off tx-nocache-copy off
/sbin/ethtool -K eth3 sg off tso off gso off gro off lro off tx-nocache-copy off
/sbin/ethtool -K eth4 sg off tso off gso off gro off lro off tx-nocache-copy off
/sbin/ethtool -K eth5 sg off tso off gso off gro off lro off tx-nocache-copy off

 

Два встроенных бродкома и 4 интела:

# ethtool -i eth0
driver: bnx2
version: 2.2.1
firmware-version: bc 3.5.12 UMP 1.1.8
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
# ethtool -i eth2
driver: igb
version: 5.0.6
firmware-version: 1.5.1
bus-info: 0000:0e:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

 

03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12)
07:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12)
0e:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
0e:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
0f:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
0f:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)

 

Справедливости ради стоит заметить, что ранее бродкомы висели без дела - в бондинге были только интелы попарно. Бондинги собраны по схеме bcm+intel+intel.

 

Перешёл на 3.11.6 ядро недавно, uptime 24 дня, полёт нормальный. Трафика чуть больше гига к абонентам. Нагрузка на ядра упала с 40 до 15 процентов, но подрос LA, правда не сильно, нозаметно. На 3.0.x LA можно сказать не было вообще

 

Эво как. Интересно за счет чего так славно нагрузка упала. NAT есть? Сколько записей в conntrack?

[Antares]

нат есть

conntrack -C

174961

igb у меня 5.0.5

Изменено 23 декабря, 2013 пользователем Antares

[adnull]

У меня сегодня e1000e на untel 82574L тоже взбрыкнул. Не в корку, но линк опустил на 5 минут.

[heap]

нат есть

conntrack -C

174961

igb у меня 5.0.5

 

Для завершения сравнения - есть ли htb? ipset? police rate? hashing filters?

[Antares]

ipset есть, остального нет

[nuclearcat]

У меня сегодня e1000e на untel 82574L тоже взбрыкнул. Не в корку, но линк опустил на 5 минут.

В dmesg сообщения о reset были? я после того как отключил gso gro tso - все стало ок, а так было на некоторых e1000e подобное.

 

По другим сообщениям:

Но sg не стал бы отключать, по производительности может ударить, как и многое другое.

Кстати возможно имеет значение какие nat helpers подгружены, я обычно только pptp подгружаю, а остальное - нет.

bnx2 я бы на время отключил, чтобы исключить баг в их драйвере. Лично я их избегаю на роутерах из-за низкой эффективности.

[adnull]

Ага, вывалило:

[504336.564732] e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
kernel: [504336.564732]   TDH                  <db>
kernel: [504336.564732]   TDT                  <4c>
kernel: [504336.564732]   next_to_use          <4c>
kernel: [504336.564732]   next_to_clean        <d9>
kernel: [504336.564732] buffer_info[next_to_clean]:
kernel: [504336.564732]   time_stamp           <11e0d0712>
kernel: [504336.564732]   next_to_watch        <db>
kernel: [504336.564732]   jiffies              <11e0d2fe5>
kernel: [504336.564732]   next_to_watch.status <0>
kernel: [504336.564732] MAC Status             <40080043>
kernel: [504336.564732] PHY Status             <796d>
kernel: [504336.564732] PHY 1000BASE-T Status  <0>
kernel: [504336.564732] PHY Extended Status    <3000>
kernel: [504336.564732] PCI Status             <10>
kernel: [504336.575561] e1000e 0000:00:19.0 eth0: Reset adapter unexpectedly

 

Бегло погуглил, говорят баг в дровах. Пока выкинул из ядра все кроме e1000e, offloading не отключал, больше не падало.

[heap]

По другим сообщениям:

Но sg не стал бы отключать, по производительности может ударить, как и многое другое.

Кстати возможно имеет значение какие nat helpers подгружены, я обычно только pptp подгружаю, а остальное - нет.

bnx2 я бы на время отключил, чтобы исключить баг в их драйвере. Лично я их избегаю на роутерах из-за низкой эффективности.

 

lsmod среди прочего кажет:

iptable_nat
nf_nat
nf_conntrack_ipv4
nf_conntrack
ip_tables
x_tables
nf_conntrack_ipv4
nf_defrag_ipv4
nf_conntrack

 

То бишь как вроде бы ничего лишнего. Из netfilter есть:

xt_CT
xt_mark
xt_state
xt_tcpudp
xt_hashlimit
xt_set

 

Можно ли поподробнее в двух словах об sg. Какой выигрыш в производительности он дает включенный на роутере?

 

Касательно bnx - драйвер ядерный ездит. Почему-то с оффсайта со свежими ядрами не компилится.

 

Ага, вывалило:

 

Бегло погуглил, говорят баг в дровах. Пока выкинул из ядра все кроме e1000e, offloading не отключал, больше не падало.

 

Ага, на сервачке с e1000e где-то встречалось такое. Не помню приводило ли к дизастеру, но такие сообщения встречались.

 

Про bnx2 соврал. Уже есть, которые собираются.

Изменено 23 декабря, 2013 пользователем heap

[nuclearcat]

Можно ли поподробнее в двух словах об sg. Какой выигрыш в производительности он дает включенный на роутере?

Ну вообще scatter gather это векторная обработка массива с пакетами, если это поддерживается драйвером.

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

 

У меня на e1000e включение-выключение влияния на производительность не оказало, скорее всего именно в этом драйвере только векторная обработка и она не отключается.

 

Вообще tso/gso/gro IMHO надо обязательно отключать если есть шейперы. Т.к. они имеют свойство собирать пакеты в "гигантские" пакеты, а в шейперах все часто заточено на максимальный mtu 1500 или около того.