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 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 кто что использует
    • By rusol
      Здравствуйте, голова уже болит, мысли закончились, может кто-то подскажет чего...

      Ситуация такая:

      Клиент жалуется, что c их ftp, который находиться в России, плохая скорость (прыгает от 10 Мбит/с до 30 Мбит/с, по тарифу должна быть 100 Мбит/с), проверили на ftp другого хостинга - все нормально, 100 Мбит.

      Я бы не писал сюда, но есть одно большое НО.. когда я захожу на главный маршрутизатор (FreeBSD + Nodeny 50.32 + IPFW + PF), то с главного сервака скорость отличная, а за серваком (в сети) скорость падает, при этом на другие ftp скорость хорошая с сети...

      То-есть без связки Nodeny + IPFW + PF - скорость отличная (на главном серваке).

      Подставлял реальный IP сервака на локальную машину, думал может ftp по IP что-то ограничивает, эффекта не дало...

      Может кто подскажет куда поглядеть, у меня уже мысли заканчиваются...
×