Перейти к содержимому
Калькуляторы

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

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

 

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

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

Изменено пользователем GrandPr1de

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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 - в момент проседания трафика.

Изменено пользователем t0ly

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

разница в нагрузке процессора между открытым файром - 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 Мппс на пустом нетмапе

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

1053M 159M CPU2 2 19.2H 99.17% kipfw

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

     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 вы где шейпили?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

если 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Мбайт и все встает колом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

dev.netmap.buf_num: 896000

dev.netmap.buf_curr_num: 896000

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

По идеологии 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.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

См. сообщение №10

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

похоже в режиме 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 это скорее научная поделка и в продакшен им не место.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

 

 

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.