GrandPr1de Опубликовано 6 января, 2015 (изменено) · Жалоба интересно-интересно, ну проще сприптом с циклом нагенерить конечно, тогда не геморно :) в целях тестирования на каждого из /16 выдаю по 4Мбит исходящей. Будет таки 64К строк в таблице ну \16 это агрегированый вид? у вас же нет такого броадкаст домена? :) Изменено 6 января, 2015 пользователем GrandPr1de Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 6 января, 2015 · Жалоба vlan на /24 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
t0ly Опубликовано 6 января, 2015 (изменено) · Жалоба в таком раскладе динамические пайпы все же должны быть эффективнее. интересно что будет если сделать 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 - в момент проседания трафика. Изменено 6 января, 2015 пользователем t0ly Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 6 января, 2015 · Жалоба Можно натравить профайлер на kipfw, да увидеть. Но я более чем уверен что основные расходы в нем это матчинг пакетов и пайпы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 6 января, 2015 · Жалоба разница в нагрузке процессора между открытым файром - 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 Мппс на пустом нетмапе Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 6 января, 2015 · Жалоба Динамические пайпы на /16 в любом состоянии ресурсоемки, так делать нехорошо о чем я писал ранее. Тут магия netmap не сможет побороть тяжелый дизайн вашей таблицы правил. Для уменьшения количества проходов поиска используются вполне логичные и древние технологии, например, - ветвление. Идея в том, чтобы уменьшить линейность поиска по правилам (да, динамические пайпы внутри тоже правила, только не вписанные руками). Поэтому обычно в условиях большого кол-ва правил применяется или tablearg (простое ветвление за счет поиска по дереву) или ручные skipto. Сколько у вас всего работающих ip? Нужен реальный порядок цифр, а не /16. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 6 января, 2015 · Жалоба 25K реально ожидаемых IP Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 6 января, 2015 · Жалоба Много. Я бы попробовал tablearg, но не на такое кол-во записей, надо как-то хитро придумать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 6 января, 2015 · Жалоба может быть ему опять мало памяти ? я изменил dev.netmap.buf_curr_num до 256000, было порядка 140К, объем занимаемой памяти вырос с 885М до 1053М 1053M 159M CPU2 2 19.2H 99.17% kipfw Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 6 января, 2015 · Жалоба 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 вы где шейпили? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 6 января, 2015 · Жалоба обычным dummynet, основной мост на нем и работает. Сейчас мост-в-мост подключены, на первом нетмап и вынос обработки исходящего при нетронутом входящем, а на втором шейпинг входящих полос с пропуском исходящего. На одной машине все было близко к окончанию ресурсов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
t0ly Опубликовано 8 января, 2015 · Жалоба у меня пока на тестовом стенде (виртуалка или локально через vale ) kipfw перестают свитчить пакеты просто через какое то время Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
t0ly Опубликовано 8 января, 2015 · Жалоба мой стандартный конфиг шейпера сожрал 6Гб оперативки и с ходу я получил 320кппс, что примерно в 3 раза больше чем есть сейчас. Завтра попробую ковырнуть пакет генератор, так что бы он генерировал пакеты которые будут проходить через шейпера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 9 января, 2015 · Жалоба мы визуально доковырялись до такого триггера : если 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Мбайт и все встает колом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 10 января, 2015 · Жалоба dev.netmap.buf_num: 896000 dev.netmap.buf_curr_num: 896000 В теории, это должно означать что у вас 0 свободных буферов. Не очень нормальная ситуация, как мне кажется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 10 января, 2015 · Жалоба в какой-то момент при хаотических изменениях sysctl переменных вылезла строка: netmap_config_obj_allocator requested objtotal 1024000 out of range [4,1000000] похоже, что в момент когда кол-во dev.netmap.buf_num делал 1024000, поэтому откатился на поменьше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 12 февраля, 2015 · Жалоба По идеологии 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 12 февраля, 2015 · Жалоба Очень занятно, ибо я уже года как жалуюсь в трекер netmap тем, что он жрет совершенно все мои ресурсы - https://code.google....es/detail?id=30 При 100kpps на мощном i7 у меня система сходу уходит в 30% system, что вообще говоря плохая тема. Так уж он устроен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 12 февраля, 2015 · Жалоба Очень занятно, ибо я уже года как жалуюсь в трекер netmap тем, что он жрет совершенно все мои ресурсы - https://code.google....es/detail?id=30 При 100kpps на мощном i7 у меня система сходу уходит в 30% system, что вообще говоря плохая тема. Так уж он устроен. Ну это ведь не дело, как нагрузку оценивать-то :/ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 12 февраля, 2015 · Жалоба Ну это ведь не дело, как нагрузку оценивать-то :/ См. сообщение №10 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 12 февраля, 2015 · Жалоба Вообще poll _блокирующий_ вызов, и в теории, если на сетевую карту ничего приходить не будет, нетмап не будет ничего потреблять. Однако синхронизация буферов нетмапа и ядра будет происходить так или иначе, если мне не изменяет память, проверить можете в коде ядра. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pfexec Опубликовано 12 февраля, 2015 · Жалоба Я долго работаю с PF_RING ZC, он от такой нагрузки на таком железе от силы 1% нагрузки даст (да еще и с обработкой пакетов), хочется ожидать чего-то подобного от netmap.ну тут на форуме где-то было про скат. так вот. он тоже на pf ring и потребление у него точно такое же как у нетмапа: часть процессорных ядер просто лежит в 100% на постоянной обработке.по сути своей и пфринк и нетмап работают одинаково. почему у вас так мало на пфринге, ответ видимо кроется в чем-то другом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 13 февраля, 2015 · Жалоба Я долго работаю с PF_RING ZC, он от такой нагрузки на таком железе от силы 1% нагрузки даст (да еще и с обработкой пакетов), хочется ожидать чего-то подобного от netmap.ну тут на форуме где-то было про скат. так вот. он тоже на pf ring и потребление у него точно такое же как у нетмапа: часть процессорных ядер просто лежит в 100% на постоянной обработке.по сути своей и пфринк и нетмап работают одинаково. почему у вас так мало на пфринге, ответ видимо кроется в чем-то другом. Не думаю, что у них PF_RING. PF_RING что в ZC режиме, что в обычном one-copy прогружает ядро ровно пропорционально нагрузке, если ее нету - она нулевая, если 500кппс - процентов 5, если 5 mpps - 50, все ожидаемое и объяснимо. Выкладывает ядра сразу же в полку - DPDK, это его фича, чтобы линуксовый шедулер не мешал его работе. Но DPDK - это такой монстр, это целая ОС запущенная на линуксе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 25 февраля, 2015 · Жалоба похоже в режиме 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 это скорее научная поделка и в продакшен им не место. Яндекс нетмап юзает уже года полтора в каких то своих целях. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 25 февраля, 2015 · Жалоба poll(&fds, 1, -1); - блокирующий - пока ничего нет он спит. https://www.freebsd....ult&format=html Кэп, об этом дальше и написано :) Вероятно надо было развернуть мысль сразу: когда я пробовал netmap там была такая особенность, что poll "просыпал" поток совершенно без повода, видимо это было побочное действие синхронизации буферов. Не отрицаю, что это могли позже пофиксить, я не следил. Но встретив проблему автора я сразу предположил то, с чем столкнулся сам. Яндекс нетмап юзает уже года полтора в каких то своих целях. В яндексе инсталляций фрибсд сейчас на уровне погрешности измерения, есть мнение. Плюс, я не думаю что всея сеть яндекса выходит через 2 сервера с нетмапом в мир. Все же продакшеном это называть рано. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...