URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 92086
[ Назад ]
Исходное сообщение
"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено mrrc , 09-Авг-11 14:28 
Столкнулся со следующим глюком, вчера развернул сервер под управлением FreeBSD 8.2-RELEASE, сегодня заливал подключившись по ssh файл mysql-базы объемом более трех гигабайт в созданную на сервере mysql-базу (mysql -uroot -ppsw netams < netams.sql), спустя пару минут после начала связь пропала, сервер перестал отвечать на запросы и пинговаться вообще.
Пришлось доехать до объекта, включил терминал, думая увидеть ругательства типа паник и т.д., но все чисто и в логах никой информации по отказу сетевого устройства нет. Но и связи через интерфейс тоже нет, хотя и индикация есть и интерфейс поднят в системе, вроде все в порядке, но он висит.

Пытаясь поэтапно понять корень проблемы попытался опустить интерфейс ifconfig msk0 down и снова поднять, в какой-то момент при такой попытке выдало сообщение: initialization failed: no memory for Rx buffers, что привело к мысли переполнения буферов и возможной необходимости что-то подтюнить в системе, возможно.

Короче ребут сервера все исправил.
Попробовал на терминале залить данные в базу, это действительно приводит к пропаданию сетевой связи через небольшое время после начала, в логах по-прежнему ничего. Базу то я залил, но почему при создаваемой подобной нагрузке пропадает связь - не понятно, вряд ли потребуется проделывать подобное когда сервер встанет на боевое дежурство, но встал вопрос, вдруг это проявиться позднее при активной работе пользователей через squid+drweb или еще при какой-то неспецифической нагрузке.

В остальном все работает, никаких глюков на серваке за сутки замечено не было, хотя инфа прокачивалась по интерфейсу и собиралось много чего еще.

Конфигурация:
FreeBSD 8.2-RELEASE (i386)
ASUS P7F-C/4L <i3420> (4 iface msk)
Core i5 760 2,80GHz
DDR3 4096Mb 2х2
Intel <E1G44ET> Gigabit Adapter Quad Port 2шт. (8 iface igb)

Еще в BIOS-е есть такая фишка, как опция

Memory Remap Feature
PCI MMIO Allocation: 4GB To 3520

Так вот для увеличения доступной системе памяти из 4GB я выставил ее в Disabled, может ли это как-то сказаться на описанное?

Содержание
Сообщения в этом обсуждении
"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено Snaut , 10-Авг-11 15:37 
а у вас памяти реально сколько стоит?

А, увидел. Может стоит поставить amd64 дистрибутив?

"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено lavr , 10-Авг-11 17:00 
> а у вас памяти реально сколько стоит?
> А, увидел. Может стоит поставить amd64 дистрибутив?

большинство Marvell'овских сетевых карт - дрянь, да и с драйвером msk не все гладко

"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено mrrc , 10-Авг-11 18:35 
>> а у вас памяти реально сколько стоит?
>> А, увидел. Может стоит поставить amd64 дистрибутив?
> большинство Marvell'овских сетевых карт - дрянь, да и с драйвером msk не
> все гладко

Сегодня с утра новое подвисание сети того же сервера, произошло после запуска установки mod_perl2 из портов, фактически на пустом месте, впервые за двое суток.

После взял и на точно таком же по конфигурации и ОС сервере, за исключением двух вставленных 4-х портовых сетевух, поставил mysql и залил базу на три с лишним гига - никаких проблем, все выполнилось без отваливания сети.

И вот, что сегодня прояснил опытным путем на проблемном сервере - сеть отваливается, только если подняты одновременно несколько интерфейсов, причем активности через них нет, они просто пока прописаны в /etc/rc.conf

# If
# msk0 - external iface
ifconfig_msk0="inet XXX.XX.XXX.XX netmask 255.255.255.240"

# igb0 - internal iface
ifconfig_igb0="inet 192.168.6.1 netmask 255.255.255.0"

# igb1 - internal iface
ifconfig_igb1="inet 192.168.9.1 netmask 255.255.255.0"
ifconfig_igb1_alias0="inet 192.168.1.1 netmask 255.255.255.0"
ifconfig_igb1_alias1="inet 192.168.10.1 netmask 255.255.255.0"
ifconfig_igb1_alias2="inet 192.168.11.1 netmask 255.255.255.0"
ifconfig_igb1_alias3="inet 192.168.12.1 netmask 255.255.255.0"

# igb2 - internal iface
ifconfig_igb2="inet 192.168.2.1 netmask 255.255.255.0"
ifconfig_igb2_alias0="inet 192.168.4.1 netmask 255.255.255.0"
ifconfig_igb2_alias1="inet 192.168.5.1 netmask 255.255.255.0"

# igb3 - internal iface
ifconfig_igb3="inet 192.168.0.1 netmask 255.255.255.0"
ifconfig_igb3_alias0="inet 192.168.3.1 netmask 255.255.255.0"

# igb4 - internal iface
ifconfig_igb4="inet 192.168.7.1 netmask 255.255.255.0"

# igb5 - internal iface
ifconfig_igb5="inet 192.168.8.1 netmask 255.255.255.0"

Пробовал залить вышеозначенную базу только при одном поднятом интерфейсе, что msk, что igb, проходит стабильно, отказа сети не наблюдается.

Отсюда можно сделать вывод - что-то с дровами устройств и распределением ресурсов в системе, но что подкрутить - я не знаю, т.к. в логах по отваливанию сети нет ничего вообще.
Единственное, что заметил, когда при поднятых шести интерфейсах igb попытался поднять наружную сеть на igb7, интерфейс поднимался, но выдавал Сould not setup receive structures.

Короче, я в растерянности.

"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено mrrc , 10-Авг-11 18:29 
> а у вас памяти реально сколько стоит?
> А, увидел. Может стоит поставить amd64 дистрибутив?

Памяти 4Gb, система (i386) использует соответственно меньше, в зависимости от опции в BIOS Memory Remap Feature
PCI MMIO Allocation: 4GB To 3520

Кстати последнее не влияет на проблему с отваливанием сети, сегодня проверял.
Под amd64, боюсь, многое ПО не смогу найти, которое потребуется для работы, по производительности техники вполне достаточно, главное надежность и стабильность в работе.

"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено EvgenD , 10-Авг-11 22:52 
>> а у вас памяти реально сколько стоит?
>> А, увидел. Может стоит поставить amd64 дистрибутив?
> Памяти 4Gb, система (i386) использует соответственно меньше, в зависимости от опции в
> BIOS Memory Remap Feature
> PCI MMIO Allocation: 4GB To 3520
> Кстати последнее не влияет на проблему с отваливанием сети, сегодня проверял.
> Под amd64, боюсь, многое ПО не смогу найти, которое потребуется для работы,
> по производительности техники вполне достаточно, главное надежность и стабильность в работе.

Память и архитектура скорее всего не причем.
Посмотрите netstat -m на предмет использования буферов во время когда отваливается сеть, и в нормальном состоянии тоже


"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено mrrc , 11-Авг-11 00:03 
> Память и архитектура скорее всего не причем.
> Посмотрите netstat -m на предмет использования буферов во время когда отваливается сеть,
> и в нормальном состоянии тоже

Я тоже так думаю.
Спасибо, завтра проверю показатели.


"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено mrrc , 11-Авг-11 09:17 
Да, еще, на http://dadv.livejournal.com/139170.html наткнулся на статью по тюнингу FreeBSD 8.2, там есть такое:

Цитата:
Через /etc/sysctl.conf отдаём порядка гигабайта ядерной памяти на сетевые буфера, так как нынешняя FreeBSD 8.2 может войти в "клинч" (не падает, но и не обслуживает абонентов) при их переполнении и не выйти из него самостоятельно.

kern.ipc.nmbclusters=400000
kern.ipc.maxsockbuf=83886080

Вроде моя ситуация описывается?

"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено mrrc , 11-Авг-11 15:28 
>[оверквотинг удален]
>>> А, увидел. Может стоит поставить amd64 дистрибутив?
>> Памяти 4Gb, система (i386) использует соответственно меньше, в зависимости от опции в
>> BIOS Memory Remap Feature
>> PCI MMIO Allocation: 4GB To 3520
>> Кстати последнее не влияет на проблему с отваливанием сети, сегодня проверял.
>> Под amd64, боюсь, многое ПО не смогу найти, которое потребуется для работы,
>> по производительности техники вполне достаточно, главное надежность и стабильность в работе.
> Память и архитектура скорее всего не причем.
> Посмотрите netstat -m на предмет использования буферов во время когда отваливается сеть,
> и в нормальном состоянии тоже

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

# netstat -m
25163/952/26115 mbufs in use (current/cache/total)
24832/768/25600/25600 mbuf clusters in use (current/cache/total/max)
24832/379 mbuf+clusters out of packet secondary zone in use (current/cache)
0/44/44/12800 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)
0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
55954K/1950K/57904K bytes allocated to network (current/cache/total)
0/9/4 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/4/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines


# netstat -m
25163/1537/26700 mbufs in use (current/cache/total)
24832/696/25528/25600 mbuf clusters in use (current/cache/total/max)
24832/379 mbuf+clusters out of packet secondary zone in use (current/cache)
0/682/682/12800 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)
0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
55954K/4504K/60459K bytes allocated to network (current/cache/total)
0/9/4 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/4/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines


# netstat -m
25183/1397/26580 mbufs in use (current/cache/total)
24853/747/25600/25600 mbuf clusters in use (current/cache/total/max)
24853/486 mbuf+clusters out of packet secondary zone in use (current/cache)
0/724/724/12800 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)
0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
56001K/4739K/60741K bytes allocated to network (current/cache/total)
0/11289/5644 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/4/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines

"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено gpl77 , 11-Авг-11 16:05 

> Первый и второй выводы в рабочем состоянии сети, последний - когда сеть
> отвалилась.
> # netstat -m
> 25183/1397/26580 mbufs in use (current/cache/total)
> 24853/747/25600/25600 mbuf clusters in use (current/cache/total/max)
> 0/11289/5644 requests for mbufs denied (mbufs/clusters/mbuf+clusters)

ну вот.
увеличьте mbuf

"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено EvgenD , 11-Авг-11 17:45 
>> Первый и второй выводы в рабочем состоянии сети, последний - когда сеть
>> отвалилась.
>> # netstat -m
>> 25183/1397/26580 mbufs in use (current/cache/total)
>> 24853/747/25600/25600 mbuf clusters in use (current/cache/total/max)
>> 0/11289/5644 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
> увеличивайте, тут и думать нечего.
"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено mrrc , 11-Авг-11 22:42 
Ситуация после увеличения kern.ipc.nmbclusters до 65536, заливки вышеописываемой базы mysql и поднятых 9-ти интерфейсов.
Все пока работает стабильно.
Думаю, что-то придется подтюнить еще, когда пойдет реальная нагрузка.

# netstat -m
33355/1730/35085 mbufs in use (current/cache/total)
33024/1526/34550/65536 mbuf clusters in use (current/cache/total/max)
33024/768 mbuf+clusters out of packet secondary zone in use (current/cache)
0/590/590/12800 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)
0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
74386K/5844K/80231K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/13/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
27 requests for I/O initiated by sendfile
0 calls to protocol drain routines

"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено universite , 11-Авг-11 23:04 
> Ситуация после увеличения kern.ipc.nmbclusters до 65536, заливки вышеописываемой базы
> mysql и поднятых 9-ти интерфейсов.
> Все пока работает стабильно.
> Думаю, что-то придется подтюнить еще, когда пойдет реальная нагрузка.

Используйте mbuffer при передачи больших файлов


"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено mrrc , 12-Авг-11 23:37 
Продолжение.
Может кто netams юзает или скорее просто умный.

Наткнулся на какую-то тупость, не могу понять в чем дело, использую Netams на разных серверах и разных платформах многие годы, сегодня перенес всю работающую конфигурацию с FreeBSD 8.1 на этот новый шлюз под 8.2 и не могу понять что происходит, ситуация вот в чем:

Если на шлюзе запущен netams, у пользователей перестают грузиться страницы (либо ооочень медленно что-то небольшое может загрузиться), причем как-то странно, после запроса появляется в названии окна броузера тот же Яндекс, например, а сама страница дальше не грузится, просто висит, обмен данными со шлюзом осуществляется по порту 8080, на котором и работает squid. В access.log ес-но запросы пользователя имеются. Задержки и тормоза замечены и при подключении по ssh от пользователя на шлюз, если подключаться к шлюзу на реальный внешний IP-адрес внешнего интерфейса, если на внутренний, то все быстро прогружается (т.е. например с 192.168.10.50 на 192.168.10.1 - все ОК, как и должно быть). При этом если от пользователя обращаться напрямую в интернет к веб-узлу, то все летает, также нет проблем с прохождением пинга и работы почты по pop3\smtp на внешние почтовые сервера.

Причем эффект наблюдается только при использовании типа data-source ip-traffic source divert (он у всех интерфейсов, смотрящих во внутренние локальные сети), т.е. когда происходит заворот проходящего трафика с помощью ipfw в netams. На внешнем же интерфейсе, где тип data-source используется libpcap, проблем таких
нет.

Что характерно, если руками удалить правило в списке правил ipfw, заворачивающее трафик в netams по конкретному внутреннему интерфейсу, через который идет обращение от пользователя - то у него все сразу начинает работать. Проверено. Т.е. что-то происходит с трафиком к squid и ssh, когда он заворачивается и
попадает в netams.

Что странно, если при запущенном netams на шлюзе попытаться остановить squid (./squid stop в /usr/local/etc/rc.d/), то он на деле не останавливается и продолжает работать, вися в памяти, если же netams не запущен, этого эффекта нет. Вот так.

Сам Netams при этом работает, трафик считает, управляется и отлично администрится через NAWT.

Короче я уже не пойму, в чем может быть дело, помогите своими идеями.
Может подтюнить в системе что еще нужно?

Еще раз, на чем все работает:
CPU: Intel(R) Core(TM) i5 CPU         760  @ 2.80GHz (2822.51-MHz 686-class CPU)
real memory  = 4294967296 (4096 MB)
avail memory = 3598565376 (3431 MB)
FreeBSD 8.2-RELEASE (i386)
netams-3.4.5_1
squid-3.1.14 (также пробовал с 3.0.25_4)
8 igb iface
4 msk iface

Конфиг нетамса:

# cat netams.conf
#NeTAMS 3.4.5 (3490.1)  Tue 09 Aug 2011 08:37:32 +0400
#configuration built Fri Aug 12 18:00:33 2011
#begin
#global variables configuration
debug none
language ru
user oid 07C5E7 name admin real-name ... all
user oid 0750B6 name nobody real-name ... all
#services configuration
service server 0
login local
listen 20001
max-conn 6
service processor
lookup-delay 60
flow-lifetime 180
policy oid 0C09DF name ip_all target proto ip
policy oid 07332D name www target proto tcp port 21 80 81 443 8080 8081 3128
policy oid 088C41 name mail target proto tcp port 25 110
policy oid 05F2AE name dns target proto udp port 53
policy oid 01664C name ssh target proto tcp port 22
policy oid 0F90E6 name icmp target proto icmp
policy oid 07B6A4 name proxy target proto tcp port 8080
policy oid 07B5DF name exclude target file /usr/local/etc/netams/exclude_hosts.txt
policy oid 064CF3 name ip target policy-and ip_all !exclude
restrict all pass local pass
auto-units 1 type user naming prefix2 user_
...
unit user oid 0AB566 name user_12.40 ip 192.168.12.40 description "Поликлиника" parent POLIKLINIKA acct-policy ip proxy mail dns
...
service storage 1
type mysql
user root
password psw
dbname netams
accept all
service data-source 0
type ip-traffic
source divert 199
rule 500 "ip from any to any via igb0"
rule 600 "ip from any to any via igb1"
rule 700 "ip from any to any via igb2"
rule 800 "ip from any to any via igb3"
rule 850 "ip from any to any via igb4"
rule 860 "ip from any to any via igb5"
service data-source 1
type libpcap
source msk0 
rule 11 "ip"
service quota
soft-treshold 75
policy proxy
block-policy !proxy
notify soft owner
notify hard owner 07C5E7
notify return owner
service scheduler
oid 07371D time 5hour action "save"
service login
relogin no

#end

"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено mrrc , 13-Авг-11 15:09 
Смотрите, что сейчас выяснил экспериментальным путем:
Дело не в Netams, это уж точно.
У меня правила для natd выглядят следующим образом:
00900    32     1446 divert 8668 ip from 192.168.0.0/24 to any out via msk0
01000     0        0 divert 8668 ip from 192.168.1.0/24 to any out via msk0
01100     0        0 divert 8668 ip from 192.168.2.0/24 to any out via msk0
01200     0        0 divert 8668 ip from 192.168.3.0/24 to any out via msk0
01300     0        0 divert 8668 ip from 192.168.4.0/24 to any out via msk0
01400     0        0 divert 8668 ip from 192.168.5.0/24 to any out via msk0
01500     0        0 divert 8668 ip from 192.168.6.0/24 to any out via msk0
01600     0        0 divert 8668 ip from 192.168.7.0/24 to any out via msk0
01700     0        0 divert 8668 ip from 192.168.8.0/24 to any out via msk0
01800     0        0 divert 8668 ip from 192.168.9.0/24 to any out via msk0
01900    38     2450 divert 8668 ip from 192.168.10.0/24 to any out via msk0
02100     0        0 divert 8668 ip from 192.168.11.0/24 to any out via msk0
02200     0        0 divert 8668 ip from 192.168.12.0/24 to any out via msk0
02300 18430  6623969 divert 8668 ip from any to EXTERNAL_IP in via msk0

Так вот, при такой постановке правил все летает, стоило мне вместо этих правил сделать одно для natd-а:
${fwcmd} add 2400 divert natd ip from any to any via msk0

Как сразу появились те самые описываемые тормоза!
Т.е. по каким-то причинам divert СЕРВИС ip from any to any via IF приводит к подобному эффекту, будь то natd или netams. Первый раз с подобным сталкиваюсь, явно нужно что-то еще тюнить в системе, может и сами драйвера сетевых интерфейсов..

Кстати надо сказать, если использовать tee (когда пакеты копируются) вместо divert (когда пакеты заворачиваются), то с netams все работает без сетевых тормозов.
Какие будут мысли по решению проблемы?

"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено mrrc , 15-Авг-11 22:38 
Неужели ни у кого нет больше мыслей по причинам и способам решения описанной проблемы?
"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено universite , 21-Авг-11 23:27 

> Так вот, при такой постановке правил все летает, стоило мне вместо этих
> правил сделать одно для natd-а:
> 
${fwcmd} add 2400 divert natd ip from any to any via msk0
> Как сразу появились те самые описываемые тормоза!

а что вы хотите этим добиться?

"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено mrrc , 21-Авг-11 23:56 
>> Так вот, при такой постановке правил все летает, стоило мне вместо этих
>> правил сделать одно для natd-а:
>> 
${fwcmd} add 2400 divert natd ip from any to any via msk0
>> Как сразу появились те самые описываемые тормоза!
> а что вы хотите этим добиться?

Это уже и ряда экспериментов в свете переживаемой проблемы.
А именно этим пытался альтернативно прописать правила для natd-а, которые работают стабильно:

00900    2467     109531 divert 8668 ip from 192.168.0.0/24 to any out via msk0
01000       0          0 divert 8668 ip from 192.168.1.0/24 to any out via msk0
01100       0          0 divert 8668 ip from 192.168.2.0/24 to any out via msk0
01200     311     201187 divert 8668 ip from 192.168.3.0/24 to any out via msk0
01300       0          0 divert 8668 ip from 192.168.4.0/24 to any out via msk0
01400       0          0 divert 8668 ip from 192.168.5.0/24 to any out via msk0
01500      12        589 divert 8668 ip from 192.168.6.0/24 to any out via msk0
01600    3192     129138 divert 8668 ip from 192.168.7.0/24 to any out via msk0
01700      64       3888 divert 8668 ip from 192.168.8.0/24 to any out via msk0
01800       0          0 divert 8668 ip from 192.168.9.0/24 to any out via msk0
01900    1032      60923 divert 8668 ip from 192.168.10.0/24 to any out via msk0
02100       0          0 divert 8668 ip from 192.168.11.0/24 to any out via msk0
02200    1067      52558 divert 8668 ip from 192.168.12.0/24 to any out via msk0
02300       0          0 divert 8668 ip from 192.168.13.0/24 to any out via msk0
02400 4051904 2017666526 divert 8668 ip from any to XXX.XX.XXX.XXX in via msk0

"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено universite , 22-Авг-11 03:05 
вам нужно обязательно через natd соорудить NAT ?
или может, подойдет кернельный NAT ?

>[оверквотинг удален]
> 02100       0    
>      0 divert 8668 ip from 192.168.11.0/24
> to any out via msk0
> 02200    1067      52558 divert
> 8668 ip from 192.168.12.0/24 to any out via msk0
> 02300       0    
>      0 divert 8668 ip from 192.168.13.0/24
> to any out via msk0
> 02400 4051904 2017666526 divert 8668 ip from any to XXX.XX.XXX.XXX in via
> msk0

"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено universite , 16-Авг-11 01:18 
> Ситуация после увеличения kern.ipc.nmbclusters до 65536, заливки вышеописываемой базы
> mysql и поднятых 9-ти интерфейсов.
> Все пока работает стабильно.
> Думаю, что-то придется подтюнить еще, когда пойдет реальная нагрузка.
> # netstat -m
> 33355/1730/35085 mbufs in use (current/cache/total)
> 33024/1526/34550/65536 mbuf clusters in use (current/cache/total/max)
> 33024/768 mbuf+clusters out of packet secondary zone in use (current/cache)
> 74386K/5844K/80231K bytes allocated to network (current/cache/total)

Не хватает mbuf и соответственно мало памяти на сеть
Покажите еще раз ваш тьюнинг в /etc/sysctl.conf и /boot/loader.conf

Я бы еще попробовал сделать бинарный апгрейд на amd64 и вырубил в биосе игры с размером памяти.

"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено mrrc , 16-Авг-11 08:43 
>> Ситуация после увеличения kern.ipc.nmbclusters до 65536, заливки вышеописываемой базы
>> mysql и поднятых 9-ти интерфейсов.
>> Все пока работает стабильно.
>> Думаю, что-то придется подтюнить еще, когда пойдет реальная нагрузка.
>> # netstat -m
>> 33355/1730/35085 mbufs in use (current/cache/total)
>> 33024/1526/34550/65536 mbuf clusters in use (current/cache/total/max)
>> 33024/768 mbuf+clusters out of packet secondary zone in use (current/cache)
>> 74386K/5844K/80231K bytes allocated to network (current/cache/total)
> Не хватает mbuf и соответственно мало памяти на сеть

Да, с этим вопрос решился, все стабильно работает уже и в боевом режиме.

> Покажите еще раз ваш тьюнинг в /etc/sysctl.conf и /boot/loader.conf

Тюнинга более как такового и нет, но на всякий случай все ниже:

# cat /etc/sysctl.conf
kern.ipc.nmbclusters=65536
net.inet.ip.fw.dyn_max=8192

# cat /boot/loader.conf
vm.pmap.shpgperproc=400

На этой странице http://dadv.livejournal.com/139170.html описываются методики оптимизации различных подсистем 8.2, но без четкого понимания необходимости изменения чего-либо я не берусь пробовать, но может наряду с изменением kern.ipc.nmbclusters надо и kern.ipc.maxsockbuf повышать, только на сколько, но это мысли вслух только.

> Я бы еще попробовал сделать бинарный апгрейд на amd64 и вырубил в
> биосе игры с размером памяти.

В таком апдейте на amd64 смысла пока не вижу, разве что только если до конца недели вопрос с моей главной описываемой проблемой не решится, попробую на выходных откатить сервер на 8.1 вообще, но если и там такая же засада окажется, то даже и не знаю тогда.
Есть у меня подозрения на драйвера и поведение самих сетевых интерфейсов, все же igb с MSIX (это две четырех портовые PCI-E платы расширения Intel(R) PRO/1000 Network Connection version) с msk относительно свежие устройства, может их как-то подтюнить нужно, следую инструкциям из man igb и man msk, или что-то изменилось в поведении сетевых служб во FreeBSD 8.2-RELEASE по сравнению с 8.1, где все то же самое работало по такой же схеме, правда всего на шести сетевых интерфейсах реалтек.

А вот про PCI MMIO Allocation: 4GB To 3520 в биосе напомнили, я уже и под забыл про нее, попробую опять в Enabled выставить, но мне кажется дело все же не в этом, но когда природа проблемы не понятна, уже что-то угодно пробовать нужно.

"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено universite , 16-Авг-11 21:13 
>[оверквотинг удален]
> решится, попробую на выходных откатить сервер на 8.1 вообще, но если
> и там такая же засада окажется, то даже и не знаю
> тогда.
> Есть у меня подозрения на драйвера и поведение самих сетевых интерфейсов, все
> же igb с MSIX (это две четырех портовые PCI-E платы расширения
> Intel(R) PRO/1000 Network Connection version) с msk относительно свежие устройства, может
> их как-то подтюнить нужно, следую инструкциям из man igb и man
> msk, или что-то изменилось в поведении сетевых служб во FreeBSD 8.2-RELEASE
> по сравнению с 8.1, где все то же самое работало по
> такой же схеме, правда всего на шести сетевых интерфейсах реалтек.

Засада только в ваших настройках. В первую очередь в кол-ве mbuf
Да, dadv, голова :)

"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено mrrc , 16-Авг-11 22:45 
> Засада только в ваших настройках. В первую очередь в кол-ве mbuf
> Да, dadv, голова :)

Так что именно нужно изменить\откорректировать в моем случае?
Пардон? :)

"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено mrrc , 20-Авг-11 16:29 
Проблема локализована.
Танцы с использованием уже фри 8.1 и прочие ухищрения ни к чему не привели, по прежнему сеть затыкалась у пользователей при завороте трафика в Netams с помощью divert, будь то подняты все интерфейсы или один единственный, фря 8.1-Release или 8.2-STABLE.

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

Отсюда можно сделать вывод - проблема в используемых сетевых интерфейсах msk и igb (в их драйверах, механизмах работы, взаимодействия с ОС или т.д.)! Используя заворот проходящего через них трафика в Netams с помощью divert возникают описанная проблема.

Какие будут соображения по возможному решению проблемы?

"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено universite , 21-Авг-11 22:38 

> Какие будут соображения по возможному решению проблемы?

Накатить свежую 8.2-STABLE

"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено mrrc , 21-Авг-11 22:47 
> Накатить свежую 8.2-STABLE

Да уж куда свежее то - FreeBSD 8.2-STABLE #0: Thu Aug 18 22:27:08 MSD 2011

"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено universite , 21-Авг-11 23:25 
>> Накатить свежую 8.2-STABLE
> Да уж куда свежее то - FreeBSD 8.2-STABLE #0: Thu Aug 18
> 22:27:08 MSD 2011

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

"Странно отвалился сетевой интерфейс во FreeBSD 8.2-RELEASE"
Отправлено mrrc , 21-Авг-11 23:58 
>>> Накатить свежую 8.2-STABLE
>> Да уж куда свежее то - FreeBSD 8.2-STABLE #0: Thu Aug 18
>> 22:27:08 MSD 2011
> В первом посте топика была другая версия указана.

C тех времен много воды утекло, уже и 8.1-R и 8.2-R и 8.2-STABLE пробовались, все безрезультатно.