Jump to content
Калькуляторы

Ядра Linux 3.10.x, 3.12.x NAT kernel panic

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

ethtool -K eth0 gso off gro off tso off

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Может быть драйвер и 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?

Share this post


Link to post
Share on other sites

нат есть

conntrack -C

174961

igb у меня 5.0.5

Edited by Antares

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

нат есть

conntrack -C

174961

igb у меня 5.0.5

 

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

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

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

Share this post


Link to post
Share on other sites

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

[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 не отключал, больше не падало.

Share this post


Link to post
Share on other sites

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

Но 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 соврал. Уже есть, которые собираются.

Edited by heap

Share this post


Link to post
Share on other sites

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

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

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

 

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

 

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this