heap Опубликовано 23 декабря, 2013 · Жалоба Кто-нибудь использует сабжевые ядра на роутерах с NAT? Периодически (на глазок примерно раз в неделю) ядро валится в панику. Как правило, наблюдается среди прочего в дампе вызов kmem_cache_alloc или kmalloc. В двух случая обратил внимание, что происходила проблема в дереве вызовов conntrack, а именно __nf_conntrack_alloc. Есть еще у кого-то подобные проблемы? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 23 декабря, 2013 · Жалоба Я, работает нормально, причем и 11.x и 12.x. Паник не бывало вообще, нагрузка около гигабита. Все зависит какие features вы используете кроме NAT и каким компилятором собрано ядро. И проверьте память. Китайцы выбросили на рынок как минимум паленые чипы kingston, которые при сильно нагрузке начинают "сыпаться" и на тестах проблема детектится плохо. Уже три раза на эти грабли наступил, причем в одном из случаев память должна была быть ECC и не помогло. В случае десктопной помогла замена на другого производителя. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 23 декабря, 2013 · Жалоба Я, работает нормально, причем и 11.x и 12.x. Паник не бывало вообще, нагрузка около гигабита. Все зависит какие features вы используете кроме NAT и каким компилятором собрано ядро. И проверьте память. Китайцы выбросили на рынок как минимум паленые чипы kingston, которые при сильно нагрузке начинают "сыпаться" и на тестах проблема детектится плохо. Уже три раза на эти грабли наступил, причем в одном из случаев память должна была быть ECC и не помогло. В случае десктопной помогла замена на другого производителя. Да память, конечно, вариант, но сервер не новый - до обновления не замечалось подобного (ранее ездило под 3.0.х). Сейчас откатил на 3.4.х ради эксперимента. А другие фичи - вопрос интересный, но очень смущает что в двух паниках расклад крутился именно вокруг аллокейта для conntrack. Буду наблюдать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 23 декабря, 2013 · Жалоба А что за сетевуха? Может быть драйвер и offloading какой-то. Я всегда делаю: ethtool -K eth0 gso off gro off tso off Сколько соединений в час пик - максимум? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Antares Опубликовано 23 декабря, 2013 · Жалоба Перешёл на 3.11.6 ядро недавно, uptime 24 дня, полёт нормальный. Трафика чуть больше гига к абонентам. Нагрузка на ядра упала с 40 до 15 процентов, но подрос LA, правда не сильно, нозаметно. На 3.0.x LA можно сказать не было вообще Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 23 декабря, 2013 · Жалоба А что за сетевуха? Может быть драйвер и 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? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Antares Опубликовано 23 декабря, 2013 (изменено) · Жалоба нат есть conntrack -C 174961 igb у меня 5.0.5 Изменено 23 декабря, 2013 пользователем Antares Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adnull Опубликовано 23 декабря, 2013 · Жалоба У меня сегодня e1000e на untel 82574L тоже взбрыкнул. Не в корку, но линк опустил на 5 минут. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 23 декабря, 2013 · Жалоба нат есть conntrack -C 174961 igb у меня 5.0.5 Для завершения сравнения - есть ли htb? ipset? police rate? hashing filters? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Antares Опубликовано 23 декабря, 2013 · Жалоба ipset есть, остального нет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 23 декабря, 2013 · Жалоба У меня сегодня e1000e на untel 82574L тоже взбрыкнул. Не в корку, но линк опустил на 5 минут. В dmesg сообщения о reset были? я после того как отключил gso gro tso - все стало ок, а так было на некоторых e1000e подобное. По другим сообщениям: Но sg не стал бы отключать, по производительности может ударить, как и многое другое. Кстати возможно имеет значение какие nat helpers подгружены, я обычно только pptp подгружаю, а остальное - нет. bnx2 я бы на время отключил, чтобы исключить баг в их драйвере. Лично я их избегаю на роутерах из-за низкой эффективности. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adnull Опубликовано 23 декабря, 2013 · Жалоба Ага, вывалило: [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 не отключал, больше не падало. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 23 декабря, 2013 (изменено) · Жалоба По другим сообщениям: Но 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 23 декабря, 2013 · Жалоба Можно ли поподробнее в двух словах об sg. Какой выигрыш в производительности он дает включенный на роутере? Ну вообще scatter gather это векторная обработка массива с пакетами, если это поддерживается драйвером. Если судить по документации - т.е. если драйвер может - он проверяет сколько места в исходящем буфере и заталкивает пакеты туда скопом, а не по одной штуке, в ином случае после каждого пакета проверяет буфер. У меня на e1000e включение-выключение влияния на производительность не оказало, скорее всего именно в этом драйвере только векторная обработка и она не отключается. Вообще tso/gso/gro IMHO надо обязательно отключать если есть шейперы. Т.к. они имеют свойство собирать пакеты в "гигантские" пакеты, а в шейперах все часто заточено на максимальный mtu 1500 или около того. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...