Jump to content

Recommended Posts

Posted

Имею в наличии 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 индивидуальных конфигов). Поэтому хотелось бы иметь полную уверенность в том, что делаю. Может предварительно покопать что-то еще?

Posted (edited)

Можно так попробовать, 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
Posted (edited)
Можно так попробовать, 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
Posted
дровы от яндекса поставь
А каким образом это сделать? За всю практику ни разу не озабачивался подобным.. :(

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

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

 

Posted
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").

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

Posted
Да, было тоже самое, с родными дровами для интеловских карточек, поставили яндексовские, но появилось вот что:

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"

 

Posted (edited)

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

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

Edited by wsimons
Posted

Кстати, при

net.inet.ip.fastforwarding=1

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

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

 

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

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

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

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

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

Posted
Жаль.. Это не тО.. Хотелось бы реализовать это без 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..

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

 

Posted
с яндексовскими драйверами разумно использовать 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=?) ?

Posted

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

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

 

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

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

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

 

и обновись!

Posted

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

Почему

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

 

 

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

 

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.