pavel.odintsov Опубликовано 25 февраля, 2015 · Жалоба Не, вариант с "пул блокирующий поэтмоу нагрузка" не подтвердился. Нагрузили машину до 300 кппс и 8 гигабит, все подохло (начался пакетлосс) ровно в тот момент, когда процессор выедался полностью. Так что такая дикая нагрузка точно не норма. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SyJet Опубликовано 25 февраля, 2015 · Жалоба Я долго работаю с PF_RING ZC, он от такой нагрузки на таком железе от силы 1% нагрузки даст (да еще и с обработкой пакетов), хочется ожидать чего-то подобного от netmap.ну тут на форуме где-то было про скат. так вот. он тоже на pf ring и потребление у него точно такое же как у нетмапа: часть процессорных ядер просто лежит в 100% на постоянной обработке.по сути своей и пфринк и нетмап работают одинаково. почему у вас так мало на пфринге, ответ видимо кроется в чем-то другом. Не думаю, что у них PF_RING. PF_RING что в ZC режиме, что в обычном one-copy прогружает ядро ровно пропорционально нагрузке, если ее нету - она нулевая, если 500кппс - процентов 5, если 5 mpps - 50, все ожидаемое и объяснимо. Выкладывает ядра сразу же в полку - DPDK, это его фича, чтобы линуксовый шедулер не мешал его работе. Но DPDK - это такой монстр, это целая ОС запущенная на линуксе. Держат искуственно на 100% даже в простое - что-то замутили для уменьшения задержек. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 26 февраля, 2015 · Жалоба Потихоньку идет использование нетмап для препроцессинга исходящего перед основным шейпером и шейпингом трафика с нескольких внешних сетей. 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 27 февраля, 2015 · Жалоба Используйте монит и самописные скрипты для перезагрузки kipfw. И не забудьте оформить PR. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 27 февраля, 2015 · Жалоба А если завалить процесс kipfw и попробовать посмотреть, что произошло по корке? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 28 февраля, 2015 · Жалоба Потихоньку идет использование нетмап для препроцессинга исходящего перед основным шейпером и шейпингом трафика с нескольких внешних сетей. 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 4 марта, 2015 · Жалоба Используется для назначения на каждый из клиентских ИП адресов (таблицы, dummynet с маской)определенной полосы с определенных внешних ресурсов. Если это получится, остальное производное от задачи. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 4 марта, 2015 · Жалоба Придется взять на себя роль того самого гуру и ответить на причину проблемы. Я поставил 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, чтобы обрабатывать каждую очередь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 4 марта, 2015 · Жалоба Я предположил еще в середине темы, что основная нагрузка kipfw от него самого (потому что оно выдрано из обычного ipfw, со всеми его чеками/речеками) плюс сколько-то поедает синхронизация буферов и, возможно, спонтанные просыпания poll. Предложил его попрофайлить, но никто особо не расшевелился. Да и никто нигде всерьез это не использует, поэтому нет никаких гуру. Я не хочу вас расстраивать, но данные полученные вами в рамках исследования ничего особо не значат, все это было видно в коде сразу. Мне хватило раза посмотреть в код и его комменты, дабы понять что я лично не такой профессионал кодинга, чтобы убивать месяцы своего времени на выправление в нем врожденных косяков. Если ничего не изменилось за 3 года, то: сам нетмап однопоточен, он не умеет много очередей от карт. Максимум что можно сделать не колупаясь в кишках нетмапа - распаралелить kipfw и навешать спинлоки на очереди. Что выйдет? Кто знает, но я уверен что копий будет разбито не мало. Дешевле взять код какой-нибудь интересной ноды netgraph и оформить его в виде netmap-ready приложения. Но это тоже не задача нескольких минут, и уж тем более не продакшен грейд. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 4 марта, 2015 · Жалоба Интересная идея: вынести нетграф в юзерленд через нетмап. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 4 марта, 2015 · Жалоба А что интересного нетграф умеет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 4 марта, 2015 · Жалоба нетграф - это конвеерная обработка пакетов. Конвеер ты сам выстраиваешь из тех кубиков которые есть, можешь свои дописать. Плюсы - огромная гибкость - высокая скорость (ибо в ядре) - очень легко свои ноды кодить - стабильное апи - можно лет 5 код не трогать и скорее всего он будет работать Минусы - трудно отлаживать (всё таки ядро - чуть что и паника) - обрабатывает по одному пакету за раз (нет батчинга) - хотя тут есть нюансы - я вообще не уверен что для нетграфа эта проблема актуальна - в не бсд слистемах его нет - года 2 назад ещё был не готов для IPv6 - в том смысле что утилита для общения с нодами из юзерспейса не умела адреса переводить из текста в бинарную форму и обратно - слышал о костылях в виде глобального лока на топологию (те добавление/удаление нод/хуков происходит с блокировкой) - но вроде на прохождении это не сказывается - некоторые ноды надо бы переписать :) (ng_swtch или как его там работает только в один поток, естьи другие однопоточные ноды, но их не много) mpd5 - который пппое/впн - это просто демон который рулит нетграфом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 5 марта, 2015 · Жалоба Да, netgraph очень крутой! В линуксе ничего похожего даже близко. Конструктор фабрик для процессинга трафика :) Но в контексте netmap точно будут проблемы, потому что он все же zero copy и если мы влезем в пакет, его придется копировать в юзерспейс со всеми вытекающими. Поидее, надо просто сделать ноду для netmap и попробовать собрать саму платформу, ибо сам код платформы должен быть относительно отвязан от Фри. У кого-то есть более серьезное понимание ядра? А по поводу kipfw - сутки под нагрузкой 7mpps прошли, ни мемликов, ни деградации производительности не замечено. В общем-то работает годно, попробую распараллелить и поделюсь опытом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
^rage^ Опубликовано 5 марта, 2015 · Жалоба Пост очень крупный, поэтому запостил его в блоге: 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 5 марта, 2015 · Жалоба Да, netgraph очень крутой! В линуксе ничего похожего даже близко. Конструктор фабрик для процессинга трафика :) Но в контексте netmap точно будут проблемы, потому что он все же zero copy и если мы влезем в пакет, его придется копировать в юзерспейс со всеми вытекающими. Поидее, надо просто сделать ноду для netmap и попробовать собрать саму платформу, ибо сам код платформы должен быть относительно отвязан от Фри. У кого-то есть более серьезное понимание ядра? netmap уже в юзерспейсе. Ноды нетграфа, конечно, расчитаны на кернел-спейс. Но смысл был в том, что код у них (у некоторых) простой и понятный, надо просто его взять и прикрутить к нетмапу, просто как конвейер, как процедуры. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 5 марта, 2015 · Жалоба Но в контексте netmap точно будут проблемы, потому что он все же zero copy и если мы влезем в пакет, его придется копировать в юзерспейс со всеми вытекающими. Не понял. Когда ipfw нетмаповкой версии смотрит в заголовок пакета то копирование не требуется? Нетграф делает тоже самое. Иногда он и сам может генерить пакеты. Ноды нетграфа, конечно, расчитаны на кернел-спейс. Там вроде не так уж и много нод завязано на что то кернел специфичное, большинство жуют пакет внутри не дёргая ничего лишнего. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 7 марта, 2015 · Жалоба Насколько я помню, нетграфу нужен кусок сетевого стэка из ядра, чтобы на нэтмап портировать, по крайней мере все интересное, т.е. уровнем выше ng_ether. И Луиджи ж там занимался этим самым куском стэка, выносил его в юзерспейс в виде библиотеки, не зарелизил пока вроде, не знаю. В общем что-то потихоньку делается, заходите во freebsd-net. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 8 марта, 2015 · Жалоба freebsd-net - после того как туда фабрикатор начал постить там помойка. Не нужно там ничего особенного, только mbuf и прочая фигня. В ng_ether пакет попадает сразу же после драйвера, предварительно там обработки почти никакой нет, с десяток проверок, не более. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 8 марта, 2015 · Жалоба Да, я ж о чем и говорил, ng_ether только и можно, а остальное интересное в нетграфе уже уровнем повыше, после ip_input() и на ng_ether, соответственно, не цепляется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 10 марта, 2015 · Жалоба После ip_input() там разве что ng_ipfw и может ещё что то, всем остальным нодам пофик. Сам ip_input() - простой как три копейки: куча проверок, смещение оффсета, чтобы указывал на л3 заголовок. Все сложности начинаются ближе к концу, если выясняется что траф не транзитный. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 11 марта, 2015 (изменено) · Жалоба Удалось изолировать код многопоточной отработки в netmap и подцепить многопоточную обработку в fastnetmon без особых проблем. Но у меня потоки, а тут похоже придется делать отдельные процессы, надо думать как сделать лучше. Изменено 12 марта, 2015 пользователем pavel.odintsov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 11 марта, 2015 · Жалоба Что у вас поток а что трид? Я вот только pthread знаю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 12 марта, 2015 · Жалоба Что у вас поток а что трид? Я вот только pthread знаю. Описался :) Исправил пост) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 26 марта, 2015 (изменено) · Жалоба Распараллелился 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 Изменено 26 марта, 2015 пользователем pavel.odintsov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 13 апреля, 2015 · Жалоба Всем привет! Итак, хорошая новость, удалось пропатчить и добиться корректной и стабильной работы драйвера 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...