Приветствую.Есть некоторая сеть довольно больших размеров, клиентский трафик сейчас шейпится ipfw, на общем потоке 400 мбит р4 2.8 уже начинает не хватать (шейперов около 100). Топ показывает в среднем около 50% загрузки, если шейперы снять, то 10-15 (при трафике возросшем до 600-700 мбит).
Так вот, дошли слухи, что ipfw работает только на первом процессоре и покупка мощного многокаменного тазика его счастливым не сделает. Религия не запрещает перейти на pf, но интересно, как он с этим дружит.
Да и вообще - поделитесь опытом шейпинга больших потоков на ipfw и pf.
ЗЫ: таблицы не использую, шейпинг по направлениям сделан на основе ядерных таблиц роутинга: бгпой разные направления трафика разнесены по вланам и правила выглядят так:
${ipfw} pipe 14020 config bw 5Mbit/s
${ipfw} pipe 14021 config bw 5Mbit/s
${ipfw} pipe 14022 config bw 15Mbit/s
${ipfw} pipe 14023 config bw 15Mbit/s
${ipfw} add 14020 pipe 14020 ip from any to any recv vlan402 xmit vlan200
${ipfw} add 14021 pipe 14021 ip from any to any recv vlan200 xmit vlan402
${ipfw} add 14022 pipe 14022 ip from any to any recv vlan402 xmit vlan201
${ipfw} add 14023 pipe 14023 ip from any to any recv vlan201 xmit vlan402
${ipfw} add 14024 pass ip from any to any via vlan402ЗЫЫ: Трафик считать не надо.
IPFW шейпит траффик через DUMMYNET, а это SOFTWARE Shayper довольно приметивный, а PF шейпит траффик через ALTQ, а это уже HARDWARE Sheyper, и работает он через выходную очередь сетевой карты, то есть ты не можешь на одной карточке шейпить входной и выходной траффик как в IPFW+DUMMYNET, для этого тебе нужно иметь две карточки в рутору на вход и на выход, штука мощная но уже давно небыло нового релиза. Скорее в твоем случаетебе может помочь сетёвки с подержкой POLLING и не IPFW а IPFW2, и тонкий тюнинг ядра, основываясь на количестве прираваний, MBUF, загрузки проца на SYSTEM, INTERUPT, USER CPU utilisation, я задавался таким вопросом но это дело проб и ошибок инфы об этом не много.
AltQ - хардварный? Пардон, как? Насколько знаю, к железу он не привязан, т.к. реализован не в микросхемах (даже уровня поганого реалтека), а в коде pf. А если не умеет воспринимать влан как отдельный интерфейс, то совсем глупый.Естественно, фаервол второй, поллинг включен, ядро затюнено. Тонкое место - именно шейпер. Потому и спрашиваю, кто как режет большие потоки.
ALTQ - заточен под определёные карточки на определёные драйвера сетёвок. Это решение для сетевых карточек это больше не софт решение.А вообще для таких объёмов используют железяки вроде Алои или что нибудь похожее
>Естественно, фаервол второй, поллинг включен, ядро затюнено. Тонкое место - именно шейпер.
>Потому и спрашиваю, кто как режет большие потоки.Озвучьте uname -a
>Озвучьте uname -aFreeBSD 6.2-RELEASE #0
Почему #0 - туда нормально ставится патч для ipfw, который учит его натить большие потоки.
>>Озвучьте uname -a
>
>FreeBSD 6.2-RELEASE #0
>
>Почему #0 - туда нормально ставится патч для ipfw, который учит его
>натить большие потоки.Ссылочку можно?
>>Почему #0 - туда нормально ставится патч для ipfw, который учит его
>>натить большие потоки.
>
>Ссылочку можно?Пожалуйста: http://lists.freebsd.org/pipermail/freebsd-ipfw/2006-April/0...
>работает он через выходную очередь сетевой карты, то есть ты не
>можешь на одной карточке шейпить входной и выходной траффик как в
>IPFW+DUMMYNET, для этого тебе нужно иметь две карточки в рутору на
>вход и на выходВ случае с вланами в этом проблем нет. Трафик роутиться насквозь.. И поэтому режется в обе стороны. Есть множество машин где такое работает... НО. к вопросу о производительности.. На неособо загруженных узлах проблем нет...
А вот где 5 minute input rate 30272000 bits/sec, 10013 packets/sec нефиговый рутер не справляется. Валится по интераптам...
Или 5 minute input rate 12239000 bits/sec, 3580 packets/sec средненькая машинка валится просто на лопатки...
>[оверквотинг удален]
>>вход и на выход
>
>В случае с вланами в этом проблем нет. Трафик роутиться насквозь.. И
>поэтому режется в обе стороны. Есть множество машин где такое работает...
>НО. к вопросу о производительности.. На неособо загруженных узлах проблем нет...
>
>А вот где 5 minute input rate 30272000 bits/sec, 10013 packets/sec нефиговый
>рутер не справляется. Валится по интераптам...
>Или 5 minute input rate 12239000 bits/sec, 3580 packets/sec средненькая машинка валится
>просто на лопатки...Кстати попробую тогда поднять этот вопрос....
Кто нить тюнил каким либо образом PF чтоб он хоть не проигрывал ipfw в вопросах производительности..
>А вот где 5 minute input rate 30272000 bits/sec, 10013 packets/sec нефиговый
>рутер не справляется. Валится по интераптам...
>Или 5 minute input rate 12239000 bits/sec, 3580 packets/sec средненькая машинка валится
>просто на лопатки...Кстати, чем снимали статистику? Попробую свою привести.
>Кстати, чем снимали статистику? Попробую свою привести.Да просто на цисковском свиче sh int fa0/??
>>А вот где 5 minute input rate 30272000 bits/sec, 10013 packets/sec нефиговый
>>рутер не справляется. Валится по интераптам...
>>Или 5 minute input rate 12239000 bits/sec, 3580 packets/sec средненькая машинка валится
>>просто на лопатки...
>
>Кстати, чем снимали статистику? Попробую свою привести.Судя по выводу, похоже на кошку. Моя говорит так:
5 minute input rate 173037000 bits/sec, 19113 packets/sec
5 minute output rate 179100000 bits/sec, 25659 packets/sec
>Судя по выводу, похоже на кошку. Моя говорит так:
>
>5 minute input rate 173037000 bits/sec, 19113 packets/sec
>5 minute output rate 179100000 bits/sec, 25659 packets/secНу... Что я вам скажу...
Исходя из моего опыта, не могу представить машинку способную выдержать это:))))
Но думаю есть какие то нюансы способные эту ситуацию поправить... Просто я пока решения ещё не нашёл.:( Есть опция в ядро для ALTQ_NOPCC для многопроцессорных машинок.. Может она поможет.
>А вот где 5 minute input rate 30272000 bits/sec, 10013 packets/sec нефиговый
>рутер не справляется. Валится по интераптам...По каким таким интераптам? По интераптам из-за забивания очередей на вход/выход и как следствие из-за нехватки памяти в ядре под сетевую обработку во времена коротких, резких скачков вверх потока? А если памяти ядру на сеть добавить, мегабайт 500? Может сгладяться пики? Просто я знаю сумашедших админов, которые потоки в районе 70-80 Мб/с через фрибсд пускали и проблемы у них были другого плана.
> А если памяти ядру на
>сеть добавить, мегабайт 500? Может сгладяться пики?как конкретно это сделать??
если не секрет
>> А если памяти ядру на
>>сеть добавить, мегабайт 500? Может сгладяться пики?
>
>как конкретно это сделать??
>если не секретВы сначала проверте в этом ли проблема с помощью, netstat -m, параметра два в sysctl
kern.ipc.nmbclusters и kern.ipc.nsfbufs.The NMBCLUSTERS kernel configuration option dictates the amount of network Mbufs available to the system. A heavily-trafficked server with a low number of Mbufs will hinder FreeBSD's ability. Each cluster represents approximately 2 K of memory, so a value of 1024 represents 2 megabytes of kernel memory reserved for network buffers. A simple calculation can be done to figure out how many are needed. If you have a web server which maxes out at 1000 simultaneous connections, and each connection eats a 16 K receive and 16 K send buffer, you need approximately 32 MB worth of network buffers to cover the web server. A good rule of thumb is to multiply by 2, so 2x32 MB / 2 KB = 64 MB / 2 kB = 32768. We recommend values between 4096 and 32768 for machines with greater amounts of memory. Under no circumstances should you specify an arbitrarily high value for this parameter as it could lead to a boot time crash. The -m option to netstat(1) may be used to observe network cluster use.
kern.ipc.nmbclusters loader tunable should be used to tune this at boot time. Only older versions of FreeBSD will require you to use the NMBCLUSTERS kernel config(8) option.
For busy servers that make extensive use of the sendfile(2) system call, it may be necessary to increase the number of sendfile(2) buffers via the NSFBUFS kernel configuration option or by setting its value in /boot/loader.conf (see loader(8) for details). A common indicator that this parameter needs to be adjusted is when processes are seen in the sfbufa state. The sysctl variable kern.ipc.nsfbufs is a read-only glimpse at the kernel configured variable. This parameter nominally scales with kern.maxusers, however it may be necessary to tune accordingly.
Important: Even though a socket has been marked as non-blocking, calling sendfile(2) on the non-blocking socket may result in the sendfile(2) call blocking until enough struct sf_buf's are made available.