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

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

Доброго дня, коллеги.

 

Попробовали в работе netmap-ipfw, FreeBSD 10.1

Режим моста, цель - фильтрация/шейпинг. Трафика порядка 7Гбит в одну сторону, 1.2 в другую.

 

на ix1:

674K 0 0 812M 547K 0 118M 0 0

672K 0 0 812M 551K 0 118M 0 0

673K 0 0 811M 546K 0 116M 0 0

657K 0 0 795M 541K 0 116M 0 0

679K 0 0 818M 548K 0 118M 0 0

 

Собственно, суть вопроса к знатокам.

Процесс kipfw даже в режиме "allow ip from any to any" жрет через чур много:

 

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND

660 root 99 0 885M 342M CPU2 2 80.1H 92.68% kipfw

 

Если включить пару реальных правил, например выделить исходящую полосу по маске на каждый IP (порядка 15К адресов),

то процесс мин через 15 бьет в 100% и трафик скидывается с 7Гбит до 2,5. Хотя load averages: 1.25, 1.20, 1.17

По описаниям технологии, должен был бы пережевать такой трафик в реальной работе, что же не так-то ?

 

Еще момент, объем занимаемой памяти не зависит от общего трафика, по крайней мере от ночных 2Гбит до вечерних 7 поле SIZE прибито в 885М (RES 342).

Может быть, где-то в коде задефайнен лимит ? Может быть, отпустить RAM, упадет load на процессоре ? (если вообще есть какая-то связь).

 

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

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


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

10.1-STABLE FreeBSD 10.1-STABLE #4

сетевка обычная DA-520

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


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

похоже в режиме netmap обычные sysctl переменные не влияют на поведение сетевой подсистемы.

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


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

c dev.netmap игрались? ман по netmap читали?

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


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

нет по обоим последним вопросам.

С нетмап-ом ли проблема? kipfw же работает с пакетами, полученными в userspace от netmap модуля?

 

Получилось изменить объем выделяемой памяти под нетмап/kipfw, сейчас с 885М стало:

11366 root 100 0 1029M 93272K CPU1 1 40:44 95.17% kipfw

 

но, на потребление процессора это не сказалось :(

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

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


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

По идеологии netmap приложение должно находиться в постоянном poll'е. В таком положении расход цпу всегда будет высок на вид, ибо нет пустых циклов.

for (;;) {
            poll(&fds, 1, -1);
            while ( (buf = nm_nextpkt(d, &h)) )
                consume_pkt(buf, h->len);
        }

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


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

Казалось бы, машина имеет вагон ресурсов, а kipfw тем не менее при определенных условиях бьет в потолок и привет DoS (отказ от обслуживания), трафик скидывается в 2,5 раза с потерями и ростом задержки.

 

Кстати, текущая версия netmap-ipfw заводится только с

hw.ix.rxd=2048

hw.ix.txd=2048

 

если сделать больше - kipfw не взлетает с ошибкой. Видимо тоже как-то через sysctl или в #define лечится ? если имеет значение в netmap режиме.

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

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


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

если сделать больше - kipfw не взлетает с ошибкой. Видимо тоже как-то через sysctl или в #define лечится ? если имеет значение в netmap режиме.

 

 

В man netmap есть все sysctl что можно крутить. Однако не надо забывать что и kipfw и netmap это скорее научная поделка и в продакшен им не место.

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


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

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

Вот если бы kipfw жрал поменьше, тогда и исходящий шейпинг на него можно было бы вывесить.

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


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

он и будет все время жрать под 100%, почему ? - ответил выше DVM-Avgoor.

поищите может есть крутилки сделать несколько таких процессов да разбить по ядрам, вообще в таких случаях стоит подебажить чем то. Я б сам с удовольствием это сделал но у меня нет железа под рукой для тестов.

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


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

если вы можете дать некий план тестов, то можно дать вам удаленный доступ к моему мосту (скажем после 11 мск). В худшем случае, если упадет/уроните процесс kipfw машина будет работать как обычный мост.

Единственно, перезагрузок делать недопустимо.

 

Сейчас в работе такие правила к исходящему трафику:

00400 deny tcp from table(25) to any dst-port 25

00500 deny tcp from 192.168.0.0/16 to table(26) dst-port 25

00600 pipe 665 udp from 192.168.0.0/16 to any dst-port 6881

00700 pipe 666 tcp from 192.168.0.0/16 to any tcpflags syn

00750 pipe 10 udp from 192.168.0.0/16 to any

00760 pipe 11 tcp from 192.168.0.0/16 to any dst-port 443

 

все пайпы выдают полосу по маске на каждый ип адрес.

порядка 20К адресов.

in / out спецификаторы не работают, назначения red/gred не работают

 

трафика

root@bridge-netmap:/usr/local/netmap-ipfw/ipfw # netstat -bdh -w1 -I ix1

input ix1 output

packets errs idrops bytes packets errs bytes colls drops

675K 0 0 819M 523K 0 103M 0 0

669K 0 0 813M 525K 0 102M 0 0

^C

 

Загрузка:

last pid: 16662; load averages: 1.05, 1.13, 1.15 up 6+00:03:52 01:17:05

108 processes: 6 running, 75 sleeping, 27 waiting

CPU 0: 18.9% user, 0.0% nice, 5.9% system, 2.8% interrupt, 72.4% idle

CPU 1: 15.4% user, 0.0% nice, 6.7% system, 5.1% interrupt, 72.8% idle

CPU 2: 13.4% user, 0.0% nice, 5.9% system, 3.1% interrupt, 77.6% idle

CPU 3: 22.0% user, 0.0% nice, 7.1% system, 2.8% interrupt, 68.1% idle

Mem: 16M Active, 1352M Inact, 1054M Wired, 814M Buf, 5398M Free

Swap: 4096M Total, 4096M Free

 

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND

11366 root 101 0 1053M 159M CPU2 2 395:22 93.65% kipfw

11 root 155 ki31 0K 64K RUN 2 116.6H 76.17% idle{idle: cpu2}

11 root 155 ki31 0K 64K CPU0 0 112.7H 75.29% idle{idle: cpu0}

11 root 155 ki31 0K 64K CPU3 3 116.7H 75.20% idle{idle: cpu3}

11 root 155 ki31 0K 64K RUN 1 116.1H 74.27% idle{idle: cpu1}

12 root -92 - 0K 432K WAIT 2 152:36 1.95% intr{irq266: ix0:que }

12 root -92 - 0K 432K WAIT 1 152:09 1.76% intr{irq265: ix0

 

 

Насчет нескольких процессов kipfw. Как-то сомнительно ?

процесс запускается

/usr/local/netmap-ipfw/kipfw netmap:ix0 netmap:ix1

 

видимо захватывает hw буфера сетевых и делает map в userspace. Как несколько процессов смогут это дело расшарить ?

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


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

netmap не умеет (пока) много очередей в картах которые это умеют. Было бы 4 сетевые карты можно было бы запустить 2 kipfw. Можно поиграть с переносом его на отдельный cpu, однако практической пользы, думаю, не будет. Ну и как бы чудес не бывает, netmap дает только два плюса: короткий стек вызовов между попаданием пакета на сетевую до входа в фильтр и отсутствие переключений контекста между ядерным и прикладным пространством процесса. Это дает местами неплохое ускорение, но если у вас в ipfw куча правил - все это уже особого значения не имеет, плюсы тают. Потому что реальная работа ipfw по поиску правил и применению их уже занимает ощутимо большее время чем накладные расходы на перекладывание пакетов. 2.5Гбит/с собственно и в обычном ipfw вполне достижимо. Чуда не случилось :)

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


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

могу разве что посмотреть.

менять без синтетического теста и полного понимание происходящего, еще и боевую машину, только карму портить.

суня по загрузке процесс прыгает на разные ядра, прибивать к одному (cpuset) не пробовали?

очереди самих сетевух прибиты к ядрам?

проверяли скорость проседает когда начинают работать dummynet-pipe's или когда просто заполняется большая таблица ? (если большая таблица то дело в ipfw_chk, и тут нужно думать дальше, с ходу не скажу что делать)

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

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


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

кстати flow control отключен?

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


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

Чуть раньше задавал вопросы и довел идею до работы, но вот как с freebsd не скажу, в лине работает.

Можно в статический lacp по середине ставить прозрачный bridge, в данном случае можно эту технологию применить для отладки такой штуки.

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


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

fc в 0 по умолчанию взлетает с sysctl.conf

в лоадере

net.isr.maxthreads=4

net.isr.numthreads=4

net.isr.bindthreads=1

 

процесс пробовал прибивать к 1 ядру - он его отжимает в те же 100% и так же скидывает трафик.

Процесс отъедает 100 проц примерно через минуту и скидывает обрабатываемый трафик в 2,5 раза (на приличном трафике) после того, как включается правило типа

ipfw add XXX pipe 20 ip from 192.168.0.0/16 to any

где 20 пайп выдает на каждый IP адрес какую нибудь полосу по маске.

 

Если убрать правило - трафик сразу восстанавливается.

Как-таковой таблицы с большим кол-вом адресов не использую.

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


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

по поводу dummynet pipe какого размера ставили ограничение? т.е. я к тому что если ограничение все же ставится то это логично что трафик падает.

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


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

ну в идеале tablearg довольно таки оптимизирует, но там надо таблицу вида

table 10 list
192.168.0.2 1
192.168.0.3 2
....
192.168.10.5 5012

 

Где агрументы 1,2...,5012 - это номер пайпа.

А правило было б одно

pipe tablearg ip from table\(10\) to any

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


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

По идее выдача полосы идет по маске:

pipe 10 config mask src-ip 0xffffffff bw 4096Kbit/s

 

это ограничение достаточно велико для исходящего трафика, чтобы вдруг упал входящий в 2,5 раза.

На основном мосту падение входящего при применении этого правила было порядка 2-3 процентов.

 

причем, даже если правило выдает 10Мбит/с на каждый ип адрес - все равно происходит срыв входящего потока при упоре в 100 проц. Это дело можно легко продемонстрировать, если хотите. Дам доступ, сами увидите :) Лучше даже в ЧНН - 10 сек потерпятся.

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


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

Что мешает попробовать то что я раньше написал?

Сомневаюсь, что kipfw не умеет tablearg.

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


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

завтра проверю. правда придется заполнять таблицу /16 строками, эт сколько млн.

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


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

завтра проверю. правда придется заполнять таблицу /16 строками, эт сколько млн.

ээээ а вы абонентам по \16 выдаете? И на каждую \16 4 мегабита?

Или всё таки 1 абон - 1 ип, и на 1 ип нарезка скорости?

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


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

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

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


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

Join the conversation

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

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

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

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

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

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

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