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

Вопрос к гуру freebsd. Netmap-ipfw шибко прожорливый процесс.

интересно-интересно, ну проще сприптом с циклом нагенерить конечно, тогда не геморно :)

 

в целях тестирования на каждого из /16 выдаю по 4Мбит исходящей. Будет таки 64К строк в таблице

ну \16 это агрегированый вид? у вас же нет такого броадкаст домена? :)

Edited by GrandPr1de

Share this post


Link to post
Share on other sites

vlan на /24

Share this post


Link to post
Share on other sites

в таком раскладе динамические пайпы все же должны быть эффективнее.

интересно что будет если сделать

pipe 10 config mask src-ip 0xffffffff bw 4096Kbit/s buckets 65536

и

pipe 10 config mask src-ip 0x0000ffff bw 4096Kbit/s buckets 65536

и

pipe 10 config mask src-ip 0x0000ffff bw 409600Kbit/s buckets 65536

 

и вообще хотелось бы увидиеть

pipe 10 show - в момент проседания трафика.

Edited by t0ly

Share this post


Link to post
Share on other sites

Можно натравить профайлер на kipfw, да увидеть. Но я более чем уверен что основные расходы в нем это матчинг пакетов и пайпы.

Share this post


Link to post
Share on other sites

разница в нагрузке процессора между открытым файром - allow from any to any

и суммой правил, которая убивает мост до неприемлемого состояния - 6%

 

причем даже сейчас нормально работают 4 пайпа, каждый из которых выдает по маске полосы своему подмножеству ип адресов.

 

А вот если будет всего 2 правила :

1. разрешить весь трафик В СТОРОНУ абонентов

2. навесить НА ИСХОД трафик pipe с выделением полосы по маске:

ipfw add pipe 10 ip from 192.168.0.0/16 to any

 

вот тогда кирдык. Т.е. последнее правило и убивает идею.

 

В чем-то это одно правило более ресурсоемкое чем 4 почти аналогичных правила, применяемых так же ко всей /16 сети.

 

вы можете натравить профайлер на kipfw на моей машине ? Если хоть что то будет полезным - почему не попробовать.

В описании технологии можно ожидать порядка 2,5-3 Мппс в наборе правил и до 14 Мппс на пустом нетмапе

Share this post


Link to post
Share on other sites

Динамические пайпы на /16 в любом состоянии ресурсоемки, так делать нехорошо о чем я писал ранее. Тут магия netmap не сможет побороть тяжелый дизайн вашей таблицы правил.

Для уменьшения количества проходов поиска используются вполне логичные и древние технологии, например, - ветвление. Идея в том, чтобы уменьшить линейность поиска по правилам (да, динамические пайпы внутри тоже правила, только не вписанные руками). Поэтому обычно в условиях большого кол-ва правил применяется или tablearg (простое ветвление за счет поиска по дереву) или ручные skipto. Сколько у вас всего работающих ip? Нужен реальный порядок цифр, а не /16.

Share this post


Link to post
Share on other sites

25K реально ожидаемых IP

Share this post


Link to post
Share on other sites

Много. Я бы попробовал tablearg, но не на такое кол-во записей, надо как-то хитро придумать.

Share this post


Link to post
Share on other sites

может быть ему опять мало памяти ? я изменил dev.netmap.buf_curr_num до 256000, было порядка 140К, объем занимаемой памяти вырос с 885М до 1053М

1053M 159M CPU2 2 19.2H 99.17% kipfw

Share this post


Link to post
Share on other sites

     dev.netmap.buf_curr_num: 0

    dev.netmap.buf_curr_size: 0

    dev.netmap.ring_curr_num: 0

    dev.netmap.ring_curr_size: 0

    dev.netmap.if_curr_num: 0

    dev.netmap.if_curr_size: 0
            Actual values in use.

 

Менять эти sysctl, судя по man netmap, не имеет никакого смысла, т.к. они всего лишь отражают реальное потребление нетмапом.

И да, объем занимаемой памяти у вас как раз 159М, а 1053М это сложная цифра на которую можно не смотреть. Сделать больше памяти конечно можно, но если у вас кол-во реально потребной памяти под буфер не большое, то какой смысл? В общем-то на мой взгляд у вас все вполне закономерно работает. До kipfw вы где шейпили?

Share this post


Link to post
Share on other sites

обычным dummynet, основной мост на нем и работает. Сейчас мост-в-мост подключены, на первом нетмап и вынос обработки исходящего при нетронутом входящем, а на втором шейпинг входящих полос с пропуском исходящего. На одной машине все было близко к окончанию ресурсов.

Share this post


Link to post
Share on other sites

у меня пока на тестовом стенде (виртуалка или локально через vale ) kipfw перестают свитчить пакеты просто через какое то время

Share this post


Link to post
Share on other sites

мой стандартный конфиг шейпера сожрал 6Гб оперативки и с ходу я получил 320кппс, что примерно в 3 раза больше чем есть сейчас. Завтра попробую ковырнуть пакет генератор, так что бы он генерировал пакеты которые будут проходить через шейпера.

Share this post


Link to post
Share on other sites

мы визуально доковырялись до такого триггера :

если RES память пробивает планку в 520Мбайт (может таки 512Мб ?) - то сразу после этого общий трафик через kipfw падает в 2,5 раза.

Сейчас стабильная работа на примерно таких параметрах: (иногда секунд на 20-30 kipfw занимает 100%, но это не сказывается на трафике)

 

853 root 102 0 7071M 382M CPU0 0 147:17 97.17% kipfw

 

Текущий трафик через мост:

input (ix1) output

packets errs idrops bytes packets errs bytes colls drops

712k 0 0 867M 556k 0 110M 0 0

718k 0 0 875M 559k 0 104M 0 0

709k 0 0 864M 554k 0 102M 0 0

716k 0 0 872M 556k 0 103M 0 0

 

 

Причем в одной pdf-ке от Луиджи прочитал, что если netmap (kipfw в нашем случае ?) вращается на 1 ядре - то на пакет тратится примерно 80нс, если на 2 и более - то на пакет уже уходит до 120-130 нс. Мы таки прибили его на 0 ядро.

 

текущие значения sysctl переменных, связанных с netmap:

 

dev.netmap.ring_size: 128000

dev.netmap.ring_curr_size: 128000

dev.netmap.buf_size: 4096

dev.netmap.buf_curr_size: 4096

dev.netmap.buf_num: 896000

dev.netmap.buf_curr_num: 896000

 

еще, чтобы это значило ?

dev.netmap.ix_rx_miss: -38981191

dev.netmap.ix_rx_miss_bufs: -1113920158

 

Итого, что же происходит в недрах kipfw при выходе за 512 Мбайт ?

Если врубить правило по выдаче полосы на IP адреса - RES память начинает довольно небыстро увеличиваться по 1Мбайту в течение нескольких мин до величины примерно 490Мбайт, а потом резко за несколько сек (20 примерно) вырастает за 500 и 540Мбайт и все встает колом.

Share this post


Link to post
Share on other sites

dev.netmap.buf_num: 896000

dev.netmap.buf_curr_num: 896000

 

В теории, это должно означать что у вас 0 свободных буферов. Не очень нормальная ситуация, как мне кажется.

Share this post


Link to post
Share on other sites

в какой-то момент при хаотических изменениях sysctl переменных вылезла строка:

netmap_config_obj_allocator requested objtotal 1024000 out of range [4,1000000]

 

похоже, что в момент когда кол-во dev.netmap.buf_num делал 1024000, поэтому откатился на поменьше.

Share this post


Link to post
Share on other sites

По идеологии netmap приложение должно находиться в постоянном poll'е. В таком положении расход цпу всегда будет высок на вид, ибо нет пустых циклов.

for (;;) {
            poll(&fds, 1, -1);
            while ( (buf = nm_nextpkt(d, &h)) )
                consume_pkt(buf, h->len);
        }

 

Очень занятно, ибо я уже года как жалуюсь в трекер netmap тем, что он жрет совершенно все мои ресурсы - https://code.google.com/p/netmap/issues/detail?id=30 При 100kpps на мощном i7 у меня система сходу уходит в 30% system, что вообще говоря плохая тема.

 

Я долго работаю с PF_RING ZC, он от такой нагрузки на таком железе от силы 1% нагрузки даст (да еще и с обработкой пакетов), хочется ожидать чего-то подобного от netmap.

Share this post


Link to post
Share on other sites

Очень занятно, ибо я уже года как жалуюсь в трекер netmap тем, что он жрет совершенно все мои ресурсы - https://code.google....es/detail?id=30 При 100kpps на мощном i7 у меня система сходу уходит в 30% system, что вообще говоря плохая тема.

 

Так уж он устроен.

Share this post


Link to post
Share on other sites

Очень занятно, ибо я уже года как жалуюсь в трекер netmap тем, что он жрет совершенно все мои ресурсы - https://code.google....es/detail?id=30 При 100kpps на мощном i7 у меня система сходу уходит в 30% system, что вообще говоря плохая тема.

 

Так уж он устроен.

 

Ну это ведь не дело, как нагрузку оценивать-то :/

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Я долго работаю с PF_RING ZC, он от такой нагрузки на таком железе от силы 1% нагрузки даст (да еще и с обработкой пакетов), хочется ожидать чего-то подобного от netmap.
ну тут на форуме где-то было про скат. так вот. он тоже на pf ring и потребление у него точно такое же как у нетмапа: часть процессорных ядер просто лежит в 100% на постоянной обработке.

по сути своей и пфринк и нетмап работают одинаково. почему у вас так мало на пфринге, ответ видимо кроется в чем-то другом.

Share this post


Link to post
Share on other sites
Я долго работаю с PF_RING ZC, он от такой нагрузки на таком железе от силы 1% нагрузки даст (да еще и с обработкой пакетов), хочется ожидать чего-то подобного от netmap.
ну тут на форуме где-то было про скат. так вот. он тоже на pf ring и потребление у него точно такое же как у нетмапа: часть процессорных ядер просто лежит в 100% на постоянной обработке.

по сути своей и пфринк и нетмап работают одинаково. почему у вас так мало на пфринге, ответ видимо кроется в чем-то другом.

 

Не думаю, что у них PF_RING. PF_RING что в ZC режиме, что в обычном one-copy прогружает ядро ровно пропорционально нагрузке, если ее нету - она нулевая, если 500кппс - процентов 5, если 5 mpps - 50, все ожидаемое и объяснимо. Выкладывает ядра сразу же в полку - DPDK, это его фича, чтобы линуксовый шедулер не мешал его работе. Но DPDK - это такой монстр, это целая ОС запущенная на линуксе.

Share this post


Link to post
Share on other sites
похоже в режиме netmap обычные sysctl переменные не влияют на поведение сетевой подсистемы.

Зато на железо влияют.

Как минимум hw нужно смотреть.

 

По идеологии netmap приложение должно находиться в постоянном poll'е. В таком положении расход цпу всегда будет высок на вид, ибо нет пустых циклов.

poll(&fds, 1, -1); - блокирующий - пока ничего нет он спит.

https://www.freebsd.org/cgi/man.cgi?query=poll&apropos=0&sektion=0&manpath=FreeBSD+10.0-stable&arch=default&format=html

 

В man netmap есть все sysctl что можно крутить. Однако не надо забывать что и kipfw и netmap это скорее научная поделка и в продакшен им не место.

Яндекс нетмап юзает уже года полтора в каких то своих целях.

Share this post


Link to post
Share on other sites

poll(&fds, 1, -1); - блокирующий - пока ничего нет он спит.

https://www.freebsd....ult&format=html

 

Кэп, об этом дальше и написано :)

Вероятно надо было развернуть мысль сразу: когда я пробовал netmap там была такая особенность, что poll "просыпал" поток совершенно без повода, видимо это было побочное действие синхронизации буферов. Не отрицаю, что это могли позже пофиксить, я не следил. Но встретив проблему автора я сразу предположил то, с чем столкнулся сам.

 

 

 

Яндекс нетмап юзает уже года полтора в каких то своих целях.

 

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

Все же продакшеном это называть рано.

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