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

FreeBSD - загибается сеть..

Имею в наличии NAS

FreeBSD 6.3-RELEASE #1: Mon Mar 30 11:03:21 MSD 2009     /usr/obj/usr/src/sys/SMP_MPD_PF  amd64
mainboard Intel S5000VSA, сетевые 1G встроенные,
CPU: Intel(R) Xeon(R) CPU            5110  @ 1.60GHz (1603.91-MHz K8-class CPU)
mpd5.3 + ng_car

При порядка 560 pptp сессий и ~75 Mbit/s сеть начинает загибаться, потери на клиентах доходят до 25%.

top -S показывает ужаснейшую картину

 PID USERNAME   THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   14 root         1 -44 -163     0K    16K CPU0   1 623.4H 91.50% swi1: net
   11 root         1 171   52     0K    16K RUN    0 621.3H 35.16% idle: cpu0
   10 root         1 171   52     0K    16K RUN    1 684.5H 31.64% idle: cpu1
   22 root         1 -68 -187     0K    16K WAIT   1  42.0H  3.96% irq18: em0
   23 root         1 -68 -187     0K    16K WAIT   0  35.2H  3.27% irq19: em1

Удалось нагуглить, что загрузку swi1: net создают пакетные фильтры. Но на машине их почти что нет - работают пара десятков правил в pf. Отключать pf пробовал - результат неизменен..

Продолжая мысль о фильтрах, обратил внимание на конфиг mpd. Там по этой теме есть вот что:

# глобальные фильтры
    set global filter 1 add 1 "match dst net 172.16.0.0/12"
    set global filter 1 add 2 "match dst net AAA.BBB.CCC.0/24"
    set global filter 1 add 3 "match dst net 10.0.0.0/8"
    set global filter 1 add 4 "match dst net 192.168.0.0/16"
    set global filter 2 add 1 "match src net 172.16.0.0/12"
    set global filter 2 add 2 "match src net AAA.BBB.CCC.0/24"
    set global filter 2 add 3 "match src net 10.0.0.0/8"
    set global filter 2 add 4 "match src net 192.168.0.0/16"

Не есть ли это причина проблемы? К сожалению, просто так эти фильтры отключить сложно для проверки (придется перепахать порядка 1500 индивидуальных конфигов). Поэтому хотелось бы иметь полную уверенность в том, что делаю. Может предварительно покопать что-то еще?

Share this post


Link to post
Share on other sites

Можно так попробовать, 6.3 старовата и встроенные сетевухи зло:

 

sysctl.conf

net.isr.direct=0            # Enable direct dispatch // Interrupt handling via multiple CPU, but with context switch.
net.inet.ip.fastforwarding=1    # packets are forwarded directly to the appropriate network interface with a min validity checking, which greatly improves the throughput
dev.em.0.rx_kthreads=2        # 
dev.em.0.rx_int_delay=250        # 
dev.em.0.tx_int_delay=250        # 
dev.em.0.rx_abs_int_delay=250    # 
dev.em.0.tx_abs_int_delay=250    # 
dev.em.0.rx_processing_limit=2048    #

 

 

loader.conf

kern.ipc.maxpipekva="32000000"    # 
net.isr.bindthreads=1        # Bind netisr threads to CPUs
net.isr.maxthreads=2            # Use at most this many CPUs for netisr processing
net.graph.maxdata="512"        # 
net.graph.maxalloc="4096"        # Maximum number of queue items to allocate
net.graph.maxdgram="128000"        # 
net.graph.recvspace="128000"    #

Edited by Ivan_83

Share this post


Link to post
Share on other sites
Можно так попробовать, 6.3 старовата и встроенные сетевухи зло:
Ну вообщем-то все так, но все равно странно для таких мелких нагрузок (12-14kpps и 80Mbit/s аплинка). Неужели для этого железа оно неподъемно? Что-то не верится..
sysctl.conf

net.isr.direct=0            # Enable direct dispatch // Interrupt handling via multiple CPU, but with context switch.
net.inet.ip.fastforwarding=1    # packets are forwarded directly to the appropriate network interface with a min validity checking, which greatly improves the throughput
dev.em.0.rx_kthreads=2        # 
dev.em.0.rx_int_delay=250        # 
dev.em.0.tx_int_delay=250        # 
dev.em.0.rx_abs_int_delay=250    # 
dev.em.0.tx_abs_int_delay=250    # 
dev.em.0.rx_processing_limit=2048    #

попробую подкрутить.

 

loader.conf

kern.ipc.maxpipekva="32000000"    # 
net.isr.bindthreads=1        # Bind netisr threads to CPUs
net.isr.maxthreads=2            # Use at most this many CPUs for netisr processing
net.graph.maxdata="512"        # 
net.graph.maxalloc="4096"        # Maximum number of queue items to allocate
net.graph.maxdgram="128000"        # 
net.graph.recvspace="128000"    #

А эти параметры можно как-то поправить, не перегружая сервер? Ну также, как sysctl.

 

P.S. А не тут ли собака порылась? На рутере uTP у меня дропается, но вот как не пустить эту заразу в туннели, понятия не имею.. :(

 

P.P.S. Кстати, вот этих двух параметров

dev.em.0.rx_kthreads=2        #
dev.em.0.rx_processing_limit=2048

у меня почему-то нет. Есть только вот это

sysctl dev.em.0
dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.7.2
dev.em.0.%driver: em
dev.em.0.%location: slot=0 function=0
dev.em.0.%pnpinfo: vendor=0x8086 device=0x1096 subvendor=0x8086 subdevice=0x3484 class=0x020000
dev.em.0.%parent: pci5
dev.em.0.debug: -1
dev.em.0.stats: -1
dev.em.0.rx_int_delay: 0
dev.em.0.tx_int_delay: 66
dev.em.0.rx_abs_int_delay: 66
dev.em.0.tx_abs_int_delay: 66

Edited by AlKov

Share this post


Link to post
Share on other sites

дровы от яндекса поставь

 

сколько ядер в проце?

Edited by AntonS

Share this post


Link to post
Share on other sites
дровы от яндекса поставь
А каким образом это сделать? За всю практику ни разу не озабачивался подобным.. :(

Погуглю, конечно, но может быть ссылочку на материал подскажете?

сколько ядер в проце?
Два

 

Share this post


Link to post
Share on other sites
http://people.yandex-team.ru/~wawa/

 

а сколько процов?

С драйверами разобрался.. Только вот что-то гложет сомнение, что проблема в них.. Плюс ко всему, полазив по http://people.yandex-team.ru/~wawa и сопоставив содержимое фтп с вот этим
em0: <Intel® PRO/1000 Network Connection Version - 6.7.2> port 0x2020-0x203f mem 0xb8820000-0xb883ffff,0xb8400000-0xb87fffff irq 18 at device 0.0 on pci5
что-то подсказывает, а не одно и то же оно??

Наверное, сначала все же попробую убрать фильтры в нетграфе. Скорее всего из-за мелких пакетов грёбаного uTP затыкаются фильтры и шейпер.. Хуже чем есть, оно точно не станет.

А если дело действительно в uTP, то боюсь придется перекраивать шейпинг в полисинг... :(

а сколько процов?
Один.

 

P.S. Плюс ко всему заглючил радиус (начал начислять бредовые суммы на пометровых тарифах), скорее всего, после установки net.inet.ip.fastforwarding=1, вернул в дефолт ("0").

Вообщем, "веселье" по-полной.. :(

Share this post


Link to post
Share on other sites
Да, было тоже самое, с родными дровами для интеловских карточек, поставили яндексовские, но появилось вот что:

http://forum.nag.ru/forum/index.php?showtopic=55764

Я правильно Вас понимаю, что до смены драйверов наблюдалась аналогичная моей картина? При тех же параметрах (кол-во pps, трафика и он-лайн pptp)? А после замены дров, прежняя проблема ушла, но появилась новая?

И еще - не совсем понял, на чем у Вас реализован шейпер? И какой версии mpd, есть ли подобные моим глобальные фильтры?

У меня шейпер реализован следующим образом - загружаю radius-ом для каждой mdp ноды подобную конструкцию

mpd-limit +="in#1#Loc=flt1 deny", mpd-limit +="in#2#Ext=all shape 1024000 192000 pass", mpd-limit +="out#1#Loc=flt2 deny", mpd-limit +="out#2#Ext=all shape 1024000 192000 pass", mpd-input-acct +="Ext", mpd-output-acct +="Ext"

 

Share this post


Link to post
Share on other sites

Да, именно такая-же проблема была.

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

Edited by wsimons

Share this post


Link to post
Share on other sites

Кстати, при

net.inet.ip.fastforwarding=1

наблюдается вот что:

после ребута (или отключения и последующего включения), на машине вылазиет kernel panic с ошибкой "имя интерфейса": discard frame w/o packet header. Лечилось отключением линка сетевой карточки (или карточки) до полного запуска машины (т.е. когда вот сервачок полностью запустился, тогда и можно включать линк :)).

 

Share this post


Link to post
Share on other sites
Да, именно такая-же проблема была.

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

А примером фильтра для uTP не поделитесь?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

вставлю свои 5 копеек.

 

а поллинг включен?

Share this post


Link to post
Share on other sites
вставлю свои 5 копеек.

 

а поллинг включен?

Отключен

Share this post


Link to post
Share on other sites

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

Так Вы фильтр не на ng_car что ли делали? На ipfw?

Share this post


Link to post
Share on other sites
Жаль.. Это не тО.. Хотелось бы реализовать это без ipfw на mpd фильтрах (наподобие set global filter 1 add 1 "match dst net 172.16.0.0/12"). Но скорее всего, mpd такое не умеет..

 

P.S. По теме - зашел в полный тупик.. :( Все шаманства с фильтрами mpd (удалил), замена shape на rate-limit и прочие "подкручивания" sysctl ничего не дали. Решил все же махнуть шашкой и поставить драйвера от яндекса. Скомпилил в ядро, запустился и... Ничего не могу понять.. При почти 500 он-лайн картинка top-а

last pid: 96303;  load averages:  2.64,  2.49,  2.49                                                                                 up 0+04:16:03  22:22:47
383 processes: 5 running, 362 sleeping, 16 waiting
CPU states:  2.8% user,  0.0% nice, 10.3% system, 53.4% interrupt, 33.5% idle
Mem: 161M Active, 1547M Inact, 259M Wired, 48K Cache, 214M Buf, 1886M Free
Swap: 8192M Total, 8192M Free

  PID USERNAME   THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   14 root         1 -44 -163     0K    16K CPU0   1 229:20 99.95% swi1: net
   11 root         1 171   52     0K    16K RUN    0  89:42 34.03% idle: cpu0
   10 root         1 171   52     0K    16K RUN    1  90:14 24.12% idle: cpu1
   12 root         1 -32 -151     0K    16K WAIT   1  19:39  5.52% swi4: clock sio
   24 root         1  43    0     0K    16K WAIT   1   5:35  2.29% em0_rx_kthread_0
   28 root         1  43    0     0K    16K WAIT   1   4:47  1.90% em1_rx_kthread_0
   25 root         1  43    0     0K    16K WAIT   1   5:35  1.86% em0_rx_kthread_1
   29 root         1  43    0     0K    16K WAIT   1   4:47  1.86% em1_rx_kthread_1

и практически полное отсутствие дропов.

Заметно вырос аплинк и соотв. кол-во pps, субъективно все забегало, как бывало. И все это при 99.95% swi1: net и 54% interrupts..

И чему теперь верить?? Ушел в аут.......

 

Share this post


Link to post
Share on other sites

с яндексовскими драйверами разумно использовать net.isr.direct=1

Share this post


Link to post
Share on other sites
с яндексовскими драйверами разумно использовать net.isr.direct=1
Я в курсе, читал в readme.yandex. Но по этому поводу есть сомнения.. Изначально так и установил (net.isr.direct=1), но через пару минут после ребута сервер зашел в непонятный ступор - сеть отвалилась, комп. отвечал только на клавиатуру, не выполняя команд (просто выводил на консоль символы нажатых клавиш), не реагировал даже на ctrl-alt-del. Ребутнул "reset-ом", остановил mpd и radius (чтобы трафик не шел), вернул net.isr.direct=0, запустился - работает уже почти сутки..

НО! Не уверен, что дело именно в net.isr.direct=1, т.к. одновременно отключил еще один "подозрительный" параметр - net.inet.ip.fastforwarding=1, поставил "0". Возможно, дело в нем, но пока проверить нет возможности. Итак уже народ возмущается частыми отключениями, подожду чуток, пока успокоятся. ;)

Кстати, вот тут уже отмечали, что драйвера от yandex в сочетании с ng_car (а у меня именно так!) дают непредсказуемый результат.

wsimons, а у Вас что по этому поводу (net.isr.direct=? и net.inet.ip.fastforwarding=?) ?

Share this post


Link to post
Share on other sites

1. NAT с тачки убери

2. net.inet.ip.fastforwarding=1 нельзя юзать с NAT

 

увы пока с имеющимися граблями не совертую мешать

нат дамминет и ng_car

разнеси по тачкам и все будет нормуль

 

и обновись!

Share this post


Link to post
Share on other sites

2. net.inet.ip.fastforwarding=1 нельзя юзать с NAT

причина?

Share this post


Link to post
Share on other sites

в свое время были проблемы с ipnat

может и с другими тоже есть грабли

 

Share this post


Link to post
Share on other sites

Дизельное топливо нельзя заливать в машину

Почему

Были проблемы с ВАЗ2101. Наверное и у других проблемы..

 

 

Например с pf nat проблем связанных с net.inet.ip.fastforwarding=1 не замечено.

 

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