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

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

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

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


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

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

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

 

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

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

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


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

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

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.

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


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

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

 

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

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


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

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

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


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

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

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.

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


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

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

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

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


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

Придется взять на себя роль того самого гуру и ответить на причину проблемы. Я поставил 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, чтобы обрабатывать каждую очередь.

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


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

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

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

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


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

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

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


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

А что интересного нетграф умеет?

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


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

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

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

 

Плюсы

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

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

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

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

 

Минусы

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

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

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

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

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

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

 

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

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


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

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

 

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

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


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

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

 

неплохо бы сделать:

net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0

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


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

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

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

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


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

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

Не понял.

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

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

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

 

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

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

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


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

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

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


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

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

 

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

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

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


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

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

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


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

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

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

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


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

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

Изменено пользователем pavel.odintsov

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


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

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

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

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


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

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

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

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

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


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

Распараллелился 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

Изменено пользователем pavel.odintsov

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


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

Всем привет!

 

Итак, хорошая новость, удалось пропатчить и добиться корректной и стабильной работы драйвера 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

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


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

Join the conversation

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

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

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

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

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

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

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