Jump to content
Local
Baneff

DUMMYNET и все-все-все

Recommended Posts

Всем привет.

Давно использую freebsd + ipfw + dummynet + kernel nat + ещё куча всякого разного и всё на одном серваке. Менять платформу не хочу - старый я уже для этого. Так вот. Нагрузка постепенно растёт, пора как-бы железо менять в очередной раз, но есть проблема. Всё в этой схеме прекрасно параллелится на мультиядерной системе. Всё, кроме старичка DUMMYNET. В очередной раз смотрю на процесс kernel{dummynet} и в очередной раз вижу конкретное узкое место во всй системе. Обойти невозможно, работает только в один поток и когда загрузка превышает 80-90% начинаются естественные проблемы. Все остальное работает с большим запасом по нагрузке. Вот и вопрос: как-то эту проблему удаётся решать? Чем шейпить юзеров, если не дамминетом? Или может появилась возможность как-то его параллелить? Или, возможно, какие-то новые методы позволяют как-то снизить нагрузку на дамминет? В документации появились некие новые варианты настроек CoDel, PIE, FQ-CoDel и FQ-PIE в дополнение к старым, может они помогут? Кто-то пробовал?

Спасибо.

Share this post


Link to post
Share on other sites

Кстати присоединюсь к вопросу - тоже интересует.

Переходить на пингвина нет желания.

Share this post


Link to post
Share on other sites
8 минут назад, Kto To сказал:

Кстати присоединюсь к вопросу - тоже интересует.

Переходить на пингвина нет желания.

 

 

Пока вижу, что выхода нет. Может разве что кто-то из своего опыта подскажет.

 

То есть остаётся только использовать все доступные пассивные методы: оптимизировать правила ipfw дамминета, снижать насколько возможно HZ в ядре, выносить из шейпера всё что можно не шейпить, снижать длину очередей, использовать самые экономные алгоритмы шейпера из возможных - вот вроде и всё. Далее выбираем CPU с максимально возможной производительностью на одно ядро из тех, которые лезут в материнку и вперёд. Кол-во ядер выходит вторично по сравнению с производительностью одного ядра, но, конечно, желательно при этом ядер побольше, чтобы успевать разруливать очереди сетевых карт по прерываниям, kernel nat, ну и остальное там по мелочам, что хорошо параллелится. Ну и запретить Hyper-Threading, тут все рекомендовальщики солидарны. Сответственно, меняем и материнку, если уже стоит макимальный для этой материнки процессор и... А дальше всё. Пока процессоров быстрее 4ггц не изобрели и наверное не изобретут уже, технологические пределы, а мультиядерность нас тут не спасает. Так что дальше уже только добавление следующего сервака в параллель.

 

Для меня пока ещё не ясен вопрос есть ли смысл ставить второй процессор, ну при условии, что материнка позволяет. Работу дамминета второй процессор никак не ускорит. Из многих бегающих в сети рекомендаций следует, что один процессор может в данной ситуации работать даже быстрее, чем два. Из-за того, что банки памяти и шины сетевых карт привязываются к одному процессору, и что медленный обмен между банками памяти и шинами разных процессоров нивелирует прибавку скорости от второго процессора. Как-то так. Но это надо попробовать, вроде что-то похожее на NUMA уже поддерживается на FreeBSD, может второй процессор и сможет уже хотя бы ускорить разгребание очередей сетевых карт по сравнению с однопроцессорной системой.

 

Ну и ещё у меня в планах посмотреть новые методы дамминета, которые только с 12-й ветки появились.

При загрузке FreeBSD-12 собщает теперь, что вместе со старыми методами:

 

load_dn_sched dn_sched FIFO loaded
load_dn_sched dn_sched WF2Q+ loaded
load_dn_sched dn_sched RR loaded
load_dn_sched dn_sched QFQ loaded

 

загружаются ещё и новые:

 

load_dn_sched dn_sched FQ_CODEL loaded
load_dn_sched dn_sched FQ_PIE loaded

load_dn_sched dn_sched PRIO loaded

load_dn_aqm dn_aqm CODEL loaded
load_dn_aqm dn_aqm PIE loaded

 

Надо будет поэкспериментировать как эти новые методы себя покажут в работе, сейчас в работе QFQ, возможно это уже не лучший вариант.

Share this post


Link to post
Share on other sites
13 минут назад, Kto To сказал:

Ну либо качать железо :)

Разгон с охлаждением на жидком азоте?

Для игрового компа - спорно, но допустимо, но гнать сервак - не, я пас. :)

Share this post


Link to post
Share on other sites
1 час назад, Baneff сказал:

Разгон с охлаждением на жидком азоте?

Для игрового компа - спорно, но допустимо, но гнать сервак - не, я пас. :)

Имеется в виду ставить <мощнее> железо

Share this post


Link to post
Share on other sites

на отдельный серв даммик выкинуть и все проблемы

года три-четыре назад так и сделали, когда начали упираться в железо

Share this post


Link to post
Share on other sites

Ну в силу того что дамминет однопоточный - выход один.

Процы с меньшим количеством ядер и большей частотой. Но и там предел тоже будет.

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

Share this post


Link to post
Share on other sites

Как вариант - резать скорость "на доступе".

Share this post


Link to post
Share on other sites
Только что, a_n_h сказал:

Как вариант - резать скорость "на доступе".

все кто так делал рано или поздно отказались от этого

Share this post


Link to post
Share on other sites
1 минуту назад, l1ght сказал:

все кто так делал рано или поздно отказались от этого

а здесь что не так?

Share this post


Link to post
Share on other sites
Только что, a_n_h сказал:

а здесь что не так?

сами то пробовали?

ну потестируйте

потом попробуйте написать обертки для 10 разных свичей на доступе, число которых только растет

потом окажется что ваш тариф в 10 мегабит неправильный, потому что один свич умеет резать только с шагом в 64 кб и придется ещё учитывать погрешность

потом методом тыка вы поймете что для тарифа в 10 мегабит вам нужно нарезать 13.5 с поправкой на 64кб шаг

 

я уже молчу что абоны от такой услуги нихера не в восторге, ибо там полисер крайне тупой

Share this post


Link to post
Share on other sites
23 минуты назад, l1ght сказал:

сами то пробовали?

а что мне пробовать? у меня как раз только один ОЛТ на доступе 😏, 100 МБт им и нарезаю.

Share this post


Link to post
Share on other sites
2 часа назад, a_n_h сказал:

а что мне пробовать? у меня как раз только один ОЛТ на доступе 😏, 100 МБт им и нарезаю.

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

Share this post


Link to post
Share on other sites
11 минут назад, Baneff сказал:

Проверьте как там эта скорость нарезается насамом деле.

проверял на 100 и более, по спидтесту соответствует. Для меня это было решение проблемы:

 на 50 и менее не проверял, работает шейпер. Из любопытства протестирую.

 

Edited by a_n_h

Share this post


Link to post
Share on other sites

Что у вас за версия freebsd ? У меня процесса dummynet нет вааще, а kernel жрет 0.0%, а вот процесс intr кушает ресурсов прилично (но он прекрасно раскидан по ядрам), пайпов в системе дофига. Здается мне что вы курите какието старые как говно мамонтов версии фри.

Edited by ramsess

Share this post


Link to post
Share on other sites
16 минут назад, ramsess сказал:

Что у вас за версия freebsd ? У меня процесса dummynet нет вааще, а kernel жрет 0.0%, а вот процесс intr кушает ресурсов прилично (но он прекрасно раскидан по ядрам), пайпов в системе дофига. Здается мне что вы курите какието старые как говно мамонтов версии фри.

12.0-CURRENT, пока на 13-ку не обновил ещё. Не знаю, как там с говном мамонта, но вроде не такая уж древняя. Может вы не тем или или не там смотрите загрузку CPU процессом? Проблема-то общая, присутствует у всех, кто шейпит больше 2к юзеров дамминетом. Может у вас те пайпы простые полисеры? Какой type у вас используется? Давайте разберёмся, аж самому интересно.

А интр и должен жрать много, тут всё в порядке. Какая у вас скорость каналов суммарная?

Edited by Baneff

Share this post


Link to post
Share on other sites

А вот так, например, пробовали смотреть? Что для kernel{dummynet} показывает?

top -SCHIPz

Edited by Baneff

Share this post


Link to post
Share on other sites

pps до 450k, это если считать пакеты скриптом на интерфейсах.

netstat -dw 1 -q 1 показывает вообще полтора миллиона пакетов в сек, но это как-то не выглядит достоверно по моему.

Share this post


Link to post
Share on other sites

Три в одном ?

Так у Вас пакеты "кругами" ходят.

Масштабируйтесь по горизонтали.

 

 

Share this post


Link to post
Share on other sites
4 минуты назад, sanyadnepr сказал:

Три в одном ?

Так у Вас пакеты "кругами" ходят.

Масштабируйтесь по горизонтали.

 

 

Можно подробнее? Вы можете объяснить разницу в pps на интерфейсах и в нетстате в несколько раз? Что у меня не так?

Share this post


Link to post
Share on other sites
32 минуты назад, Baneff сказал:

Можно подробнее? Вы можете объяснить разницу в pps на интерфейсах и в нетстате в несколько раз? Что у меня не так?

 

якщо дивитись netstat -w1 -h то тут сумарна кількість пакетів що бігають в системі

якщо дивитись netstat -w1 -h -I igb0 тут кількість пакетів на конкретному інтерфейсі

а далі калькулятор по інтерфейсам  має дати сумарне значення в системі

Share this post


Link to post
Share on other sites
25 минут назад, skreep сказал:

 

якщо дивитись netstat -w1 -h то тут сумарна кількість пакетів що бігають в системі

якщо дивитись netstat -w1 -h -I igb0 тут кількість пакетів на конкретному інтерфейсі

а далі калькулятор по інтерфейсам  має дати сумарне значення в системі

Саме так і мало би бути. Проте в реальності загальний pps в системі в мене завжди в 3.4 рази більше ніж сума pps по інтерфейсах і це мене дуже непокоїть.

Як таке можливе взагалі? Можливо десь тут і приховані мої проблеми з високим завантаженням kernel{dummynet} ?

Share this post


Link to post
Share on other sites
11 часов назад, skreep сказал:

 

якщо дивитись netstat -w1 -h то тут сумарна кількість пакетів що бігають в системі

якщо дивитись netstat -w1 -h -I igb0 тут кількість пакетів на конкретному інтерфейсі

а далі калькулятор по інтерфейсам  має дати сумарне значення в системі

Дякую, ви наштовхнули мене на рішення цієї тяжкої арифметичної задачі. Виявилося, що кількість пакетів, що проходять через фізичні інтерфейси, тобто які фізично влітають і вилітають в/з бокса - це з точки зору netstat не є загальна сума пакетів, що проходить через систему. Насправді netstat рахує всі пакети по всіх інтерфейсах, як фізичних, так і віртуальних. Тобто, якщо в системі є lagg, bridge, vlan і таке інше віртуальні інтерфейси, то netstat порахує і пакети, що проходять крізь ці інтерфейси теж, хоча фактично ці пакети вже пораховані на фізичних інтерфейсах. Виходить подвійна, потрійна і так далі арифметика і тому власне в мене і виходили такі дивні результати при підрахунках.

 

Хоча це і не по темі топіка, проте мене тепер зацікавило додатково ще одне питання. Якщо netstat враховує однаково пакети на реальних і віртуальних інтерфейсах, то що це? Помилка автора програми netstat чи то так і має бути? І якщо останнє вірно, то що, віртуальні інтерфейси навантажують систему так само як і реальні фізичні? Що, додавання кожного vlan-ну в систему реально піднімає загальний PPS і реальне навантаження на CPU ?

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

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Kto To
      Сегодня вечером словил странный глюк на следующей связке.
      FreeBSD 11.2-RELEASE-p9
      MPD version: 5.8
      Клиенты подключаются по PPPOE.
      Онлайна на машине в районе 1600 абонентов
       
      Стали звонить под вечер клиенты с проблемой на неработающий интернет. Причем некоторые.
      Стали разбираться
      В результате выяснился странный глюк
       
      [] show sessions ip 10.10.0.9 ng1865 10.10.0.9 C-1866 7956732-C-1866 vlan60-1137 1137 7956732-vlan60-1137 vova 54:e6:fc:fe:5d:53 ng2233 10.10.0.9 C-2234 7959914-C-2234 vlan60-2290 2290 7959914-vlan60-2290 vova 54:e6:fc:fe:5d:53 ng2151 10.10.0.9 C-2152 7960268-C-2152 vlan60-2298 2298 7960268-vlan60-2298 vova 54:e6:fc:fe:5d:53 ng2112 10.10.0.9 C-2113 7960073-C-2113 vlan60-2299 2299 7960073-vlan60-2299 vova 54:e6:fc:fe:5d:53 [] show sessions ip 10.10.51.184 ng1710 10.10.51.184 C-1711 7933915-C-1711 vlan63-468 468 7933915-vlan63-468 051184 00:30:67:f9:8b:87 ng608 10.10.51.184 C-609 7879576-C-609 vlan63-727 727 7879576-vlan63-727 051184 00:30:67:f9:8b:87 ng883 10.10.51.184 C-884 7933023-C-884 vlan63-1028 1028 7933023-vlan63-1028 051184 00:30:67:f9:8b:87 ng1071 10.10.51.184 C-1072 7932679-C-1072 vlan63-1177 1177 7932679-vlan63-1177 051184 00:30:67:f9:8b:87 ng1643 10.10.51.184 C-1644 7933515-C-1644 vlan63-1714 1714 7933515-vlan63-1714 051184 00:30:67:f9:8b:87 ng1671 10.10.51.184 C-1672 7928866-C-1672 vlan63-1751 1751 7928866-vlan63-1751 051184 00:30:67:f9:8b:87 ng1701 10.10.51.184 C-1702 7931011-C-1702 vlan63-1769 1769 7931011-vlan63-1769 051184 00:30:67:f9:8b:87 ng1709 10.10.51.184 C-1710 7932364-C-1710 vlan63-1777 1777 7932364-vlan63-1777 051184 00:30:67:f9:8b:87 ng2269 10.10.51.184 C-2270 7961076-C-2270 vlan63-2050 2050 7961076-vlan63-2050 051184 00:30:67:f9:8b:87 ng2229 10.10.51.184 C-2230 7960448-C-2230 vlan63-2273 2273 7960448-vlan63-2273 051184 00:30:67:f9:8b:87 ng1425 10.10.51.184 C-1426 7959795-C-1426 vlan63-2280 2280 7959795-vlan63-2280 051184 00:30:67:f9:8b:87 ng2216 10.10.51.184 C-2217 7960721-C-2217 vlan63-2287 2287 7960721-vlan63-2287 051184 00:30:67:f9:8b:87 ng2252 10.10.51.184 C-2253 7960944-C-2253 vlan63-2301 2301 7960944-vlan63-2301 051184 00:30:67:f9:8b:87 ng2236 10.10.51.184 C-2237 7960217-C-2237 vlan63-2302 2302 7960217-vlan63-2302 051184 00:30:67:f9:8b:87 ng2270 10.10.51.184 C-2271 7961240-C-2271 vlan63-2313 2313 7961240-vlan63-2313 051184 00:30:67:f9:8b:87 ng2248 10.10.51.184 C-2249 7960285-C-2249 vlan63-2318 2318 7960285-vlan63-2318 051184 00:30:67:f9:8b:87 ng1899 10.10.51.184 C-1900 7962171-C-1900 vlan63-2347 2347 7962171-vlan63-2347 051184 00:30:67:f9:8b:87 ng2299 10.10.51.184 C-2300 7962389-C-2300 vlan63-2363 2363 7962389-vlan63-2363 051184 00:30:67:f9:8b:87 ng194 10.10.51.184 C-195 7962428-C-195 vlan63-2373 2373 7962428-vlan63-2373 051184 00:30:67:f9:8b:87 ng2260 10.10.51.184 C-2261 7960890-C-2261 vlan63-2378 2378 7960890-vlan63-2378 051184 00:30:67:f9:8b:87 и так далее Почему-то перестали удаляться старые неактивные сессии клиентов. Руками удаляю все сессии - клиент подключается и работает но я так думаю это до следующего реконнекта.
       
      Вот конфиг мпд (может там что-то довписать надо, хотя конфиг переносится от сервака к серваку уже долгие годы)
      pppoe_server: create bundle template C set bundle disable encryption set bundle disable compression set ccp disable mppc set ipcp dns 8.8.8.8 1.1.1.1 set ipcp range a.b.c.d/32 0.0.0.0/0 set iface enable tcpmssfix create link template oe pppoe set link action bundle C set link disable chap pap eap set link enable pap chap set link enable peer-as-calling load radius create link template vlan2 oe set link max-children 1000 set pppoe iface vlan2 set pppoe service "*" set link enable incoming ...... Почему мпд создает ng интерфейс с тем же ип если уже такой существует? Ну и почему не удаляются старые сессии?
       
      Подскажите может сталкивался кто и как побороть.
    • By Impulsee
      День добрый!
      Есть Связка Ubilling+NAS на freebsd. 
      Настроена на Виртуалке VMware. 
      Без VLAN все работает идеально. Трафик бегает, IP раздается, Денюжка зачисляется и т.д.
      Появилась потребность поднять 3 VLAN на локальном интерфейсе для Абонов. 
      Сделал: /etc/rc.conf
       
      Вывод /etc/firewall.conf 
       
       
      Сети, шаблоны NAS, в биллинге прописал. Абоны IP получают через VLAN. Интернет есть....
       
      НО:
       
      При отрицательном балансе на em1 все отключается мгновенно, и отправляет в кабинет. 
      А на VLAN сетях Интернет есть. 
       
      Кусок /var/stargazer/allconnect.log

       
      кусок /var/log/stargazer.log
       
       
      Подскажите, плиз, в какую сторону копать?
       
    • By Nejron
      Всем здрям! ))
      Изложу суть :
      Имеется некий сервис (в данном случае IPTV личного производства)
      Хотелось бы контролировать с билинга доступ к нему.
      В профиле пользователя создал дополнительное поле с типом "TRIGGER".
       
      А вот дальше хочу спросить как правильно заполнить свою таблицу для ipfw?
      Добавлять/удалять от туда ip клиентов и возможно еще что то посоветуете.
      Возможно кто то что то подобное делал,
      не оставте начинающего админа без совета 😉
       
    • By Oleg2018
      Посоветуйте ,такая ситуация при сканировании хоста с биллингом во внешней сети открытые порты 5555 (stargazer), и 80 (apache). Если их нужно наверное спрятать от внешней сети, то как правильно написать правило ipfw ,касательно этих портов.Все остальное что вылезло после установки я закрыл, а здесь не получается никак. Спаибо заранее. 
    • By Новичок я тут
      Доброго вечера, хотел бы услышать мнение знающих людей, какой фаервол выбрать для ната что удобней, производительней ? ipfw или pf кто что использует
×