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

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

Не, вариант с "пул блокирующий поэтмоу нагрузка" не подтвердился. Нагрузили машину до 300 кппс и 8 гигабит, все подохло (начался пакетлосс) ровно в тот момент, когда процессор выедался полностью. Так что такая дикая нагрузка точно не норма.

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 - это такой монстр, это целая ОС запущенная на линуксе.

Держат искуственно на 100% даже в простое - что-то замутили для уменьшения задержек.

Share this post


Link to post
Share on other sites

Потихоньку идет использование нетмап для препроцессинга исходящего перед основным шейпером и шейпингом трафика с нескольких внешних сетей.

root@bridge-netmap:/usr/local/etc/rc.d # uptime

12:21AM up 48 days, 3:11, 3 users, load averages: 1.17, 1.18, 1.15

 

Текущий трафик:

826k 0 0 1G 612k 0 115M 0 0

825k 0 0 1G 618k 0 114M 0 0

 

процесс kipfw медленно, но монотонно набирает объем, в данный момент 517Мбайт.

36234 root 102 0 7079M 517M CPU3 3 12:47 100.00% kipfw

 

раз дней в 20-30 он добирается таки до объема порядка 560Мбайт и скидывает трафик вполовину.

Передергивается kipfw и снова поднимаются правила и цикл начинается снова. Мин 10 занимает - от диагностирования проблемы до передергивания, с дальнейшем снижением времени реакции или же подвешиванием watchdog.

Share this post


Link to post
Share on other sites

Используйте монит и самописные скрипты для перезагрузки kipfw.

 

И не забудьте оформить PR.

Share this post


Link to post
Share on other sites

А если завалить процесс kipfw и попробовать посмотреть, что произошло по корке?

Share this post


Link to post
Share on other sites

Потихоньку идет использование нетмап для препроцессинга исходящего перед основным шейпером и шейпингом трафика с нескольких внешних сетей.

root@bridge-netmap:/usr/local/etc/rc.d # uptime

12:21AM up 48 days, 3:11, 3 users, load averages: 1.17, 1.18, 1.15

 

Текущий трафик:

826k 0 0 1G 612k 0 115M 0 0

825k 0 0 1G 618k 0 114M 0 0

 

процесс kipfw медленно, но монотонно набирает объем, в данный момент 517Мбайт.

36234 root 102 0 7079M 517M CPU3 3 12:47 100.00% kipfw

 

раз дней в 20-30 он добирается таки до объема порядка 560Мбайт и скидывает трафик вполовину.

Передергивается kipfw и снова поднимаются правила и цикл начинается снова. Мин 10 занимает - от диагностирования проблемы до передергивания, с дальнейшем снижением времени реакции или же подвешиванием watchdog.

 

А что именно выполняется на pf-netmap? Что именно фильтруете и какие функции используются? Хочу понять, насколько сложно будет сделать работающий прототип подобного на PF_RING/ZC.

Share this post


Link to post
Share on other sites

Используется для назначения на каждый из клиентских ИП адресов (таблицы, dummynet с маской)определенной полосы с определенных внешних ресурсов.

Если это получится, остальное производное от задачи.

Share this post


Link to post
Share on other sites

Придется взять на себя роль того самого гуру и ответить на причину проблемы. Я поставил netmap-ipfw на Linux с картами ixgbe и в принципе воспроизвел проблему с производительностью. Пост очень крупный, поэтому запостил его в блоге: http://www.stableit.ru/2015/03/linux-netmap-ipfw.html

 

Если кратко - то netmap вовсе не виноват. Сам захват пакетов из сетевой в буфер внутри ядра занимает очень мало ресурсов процессора.

 

Чисто захват силами netmap при потоке 7mpps/10GE выглядит вот так:

%Cpu(s):  9.6 us, 15.1 sy

 

Все остальное и это в первую очередь время в user space выедает сам матчинг пакетов и все задачи, что kipfw решает внутри себя. А так как он однопоточный по дизайну - то скоро упирается в производительность ядра и начинает дропать пакеты.

 

Что делать и как жить? Быстрое и дорогое решение - брать топовый процессор отсюда - http://www.cpubenchmark.net/singleThread.html и вырубить гипертрединг. Тогда один процессор в системе будет в силах провернуть решительно больше трафика.

 

Сложное и долгое решение - переписыать kipfw. Вариантов два - внедрять треды либо попробовать запускать по 1 инстансу kipfw под каждую пару очередей аппаратной сетевой и управлять всей связкой воедино. В случае фрагментации вести оно себя будет плохо, если разные куски одного пакета раскидает по разным очередям. Но в целом трафик будет молотить на ура. Есстественно, это приведет к тому, что будет много инстансов сервера и надо будет запатчить тулзу управления ipfw, чтобы обрабатывать каждую очередь.

Share this post


Link to post
Share on other sites

Я предположил еще в середине темы, что основная нагрузка kipfw от него самого (потому что оно выдрано из обычного ipfw, со всеми его чеками/речеками) плюс сколько-то поедает синхронизация буферов и, возможно, спонтанные просыпания poll. Предложил его попрофайлить, но никто особо не расшевелился. Да и никто нигде всерьез это не использует, поэтому нет никаких гуру. Я не хочу вас расстраивать, но данные полученные вами в рамках исследования ничего особо не значат, все это было видно в коде сразу.

Мне хватило раза посмотреть в код и его комменты, дабы понять что я лично не такой профессионал кодинга, чтобы убивать месяцы своего времени на выправление в нем врожденных косяков. Если ничего не изменилось за 3 года, то: сам нетмап однопоточен, он не умеет много очередей от карт. Максимум что можно сделать не колупаясь в кишках нетмапа - распаралелить kipfw и навешать спинлоки на очереди. Что выйдет? Кто знает, но я уверен что копий будет разбито не мало. Дешевле взять код какой-нибудь интересной ноды netgraph и оформить его в виде netmap-ready приложения. Но это тоже не задача нескольких минут, и уж тем более не продакшен грейд.

Share this post


Link to post
Share on other sites

Интересная идея: вынести нетграф в юзерленд через нетмап.

Share this post


Link to post
Share on other sites

нетграф - это конвеерная обработка пакетов.

Конвеер ты сам выстраиваешь из тех кубиков которые есть, можешь свои дописать.

 

Плюсы

- огромная гибкость

- высокая скорость (ибо в ядре)

- очень легко свои ноды кодить

- стабильное апи - можно лет 5 код не трогать и скорее всего он будет работать

 

Минусы

- трудно отлаживать (всё таки ядро - чуть что и паника)

- обрабатывает по одному пакету за раз (нет батчинга) - хотя тут есть нюансы - я вообще не уверен что для нетграфа эта проблема актуальна

- в не бсд слистемах его нет

- года 2 назад ещё был не готов для IPv6 - в том смысле что утилита для общения с нодами из юзерспейса не умела адреса переводить из текста в бинарную форму и обратно

- слышал о костылях в виде глобального лока на топологию (те добавление/удаление нод/хуков происходит с блокировкой) - но вроде на прохождении это не сказывается

- некоторые ноды надо бы переписать :) (ng_swtch или как его там работает только в один поток, естьи другие однопоточные ноды, но их не много)

 

mpd5 - который пппое/впн - это просто демон который рулит нетграфом.

Share this post


Link to post
Share on other sites

Да, netgraph очень крутой! В линуксе ничего похожего даже близко. Конструктор фабрик для процессинга трафика :) Но в контексте netmap точно будут проблемы, потому что он все же zero copy и если мы влезем в пакет, его придется копировать в юзерспейс со всеми вытекающими. Поидее, надо просто сделать ноду для netmap и попробовать собрать саму платформу, ибо сам код платформы должен быть относительно отвязан от Фри. У кого-то есть более серьезное понимание ядра?

 

А по поводу kipfw - сутки под нагрузкой 7mpps прошли, ни мемликов, ни деградации производительности не замечено. В общем-то работает годно, попробую распараллелить и поделюсь опытом.

Share this post


Link to post
Share on other sites

Да, netgraph очень крутой! В линуксе ничего похожего даже близко. Конструктор фабрик для процессинга трафика :) Но в контексте netmap точно будут проблемы, потому что он все же zero copy и если мы влезем в пакет, его придется копировать в юзерспейс со всеми вытекающими. Поидее, надо просто сделать ноду для netmap и попробовать собрать саму платформу, ибо сам код платформы должен быть относительно отвязан от Фри. У кого-то есть более серьезное понимание ядра?

netmap уже в юзерспейсе. Ноды нетграфа, конечно, расчитаны на кернел-спейс. Но смысл был в том, что код у них (у некоторых) простой и понятный, надо просто его взять и прикрутить к нетмапу, просто как конвейер, как процедуры.

Share this post


Link to post
Share on other sites
Но в контексте netmap точно будут проблемы, потому что он все же zero copy и если мы влезем в пакет, его придется копировать в юзерспейс со всеми вытекающими.

Не понял.

Когда ipfw нетмаповкой версии смотрит в заголовок пакета то копирование не требуется?

Нетграф делает тоже самое.

Иногда он и сам может генерить пакеты.

 

Ноды нетграфа, конечно, расчитаны на кернел-спейс.

Там вроде не так уж и много нод завязано на что то кернел специфичное, большинство жуют пакет внутри не дёргая ничего лишнего.

Share this post


Link to post
Share on other sites

Насколько я помню, нетграфу нужен кусок сетевого стэка из ядра, чтобы на нэтмап портировать, по крайней мере все интересное, т.е. уровнем выше ng_ether. И Луиджи ж там занимался этим самым куском стэка, выносил его в юзерспейс в виде библиотеки, не зарелизил пока вроде, не знаю. В общем что-то потихоньку делается, заходите во freebsd-net.

Share this post


Link to post
Share on other sites

freebsd-net - после того как туда фабрикатор начал постить там помойка.

 

Не нужно там ничего особенного, только mbuf и прочая фигня.

В ng_ether пакет попадает сразу же после драйвера, предварительно там обработки почти никакой нет, с десяток проверок, не более.

Share this post


Link to post
Share on other sites

Да, я ж о чем и говорил, ng_ether только и можно, а остальное интересное в нетграфе уже уровнем повыше, после ip_input() и на ng_ether, соответственно, не цепляется.

Share this post


Link to post
Share on other sites

После ip_input() там разве что ng_ipfw и может ещё что то, всем остальным нодам пофик.

Сам ip_input() - простой как три копейки: куча проверок, смещение оффсета, чтобы указывал на л3 заголовок. Все сложности начинаются ближе к концу, если выясняется что траф не транзитный.

Share this post


Link to post
Share on other sites

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

Edited by pavel.odintsov

Share this post


Link to post
Share on other sites

Что у вас поток а что трид?

Я вот только pthread знаю.

Share this post


Link to post
Share on other sites

Что у вас поток а что трид?

Я вот только pthread знаю.

Описался :) Исправил пост)

Share this post


Link to post
Share on other sites

Распараллелился netmap-ipfw, довольно топорно, но нагрузку в 7Mpps на машине с слабющем E5-2407 (2.4Ghz x 4) на Linux/netmap отфильтровал без увеличения латенси :)

 

Карта нагрузки из htop:

 1  [||||||||||||||||||||||||||||||||||||||||||||||||||||||98.6%]     Tasks: 32, 55 thr, 47 kthr; 2 running
 2  [||||||||||||||||||||||||||||||||||||||||||||||||||||||94.5%]     Load average: 3.27 1.71 1.07 
 3  [|||||||||||||||||||||||||||||||||||||||||             68.1%]     Uptime: 9 days, 15:34:40
 4  [||||||||||||||||||||||||||||||||||||||||              67.1%]
 Mem[||||||||                                       1333/32207MB]
 Swp[                                                   0/8190MB]

 

Пинг по каналу, по которому льется 7mpps:

ping -c 20 10.10.10.100
PING 10.10.10.100 (10.10.10.100) 56(84) bytes of data.
64 bytes from 10.10.10.100: icmp_req=1 ttl=64 time=0.257 ms
64 bytes from 10.10.10.100: icmp_req=2 ttl=64 time=0.222 ms
64 bytes from 10.10.10.100: icmp_req=3 ttl=64 time=0.188 ms
64 bytes from 10.10.10.100: icmp_req=4 ttl=64 time=0.222 ms
64 bytes from 10.10.10.100: icmp_req=5 ttl=64 time=0.191 ms
^C
--- 10.10.10.100 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4000ms
rtt min/avg/max/mdev = 0.188/0.216/0.257/0.025 ms

 

Интересны те, кто может протестировать это на FreeBSD, на другом железе и более серьезных потоках, лучше в ЛС/почту, pavel.odintsov собако gmail.com

Edited by pavel.odintsov

Share this post


Link to post
Share on other sites

Всем привет!

 

Итак, хорошая новость, удалось пропатчить и добиться корректной и стабильной работы драйвера ixgbe с SourceForge вместе с патчем от netmap на Linux. Все фичи сорсфорж драйвера в наличии и работают! Можно даже использовать аппаратный дроп трафика: http://www.stableit.ru/2015/03/blog-post.html на ифейсе открытом netmap.

 

Код драйвера брать тут: https://github.com/pavel-odintsov/ixgbe-linux-netmap

Полный гайд, как его совместить с netmap тут: http://www.stableit.ru/2014/10/netmap-debian-7-wheezy-intel-82599.html

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