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

[Baneff 29]

Всем привет.

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

Спасибо.

[Kto To 530]

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

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

[Baneff 29]

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, возможно это уже не лучший вариант.

[Kto To 530]

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

[Baneff 29]

13 минут назад, Kto To сказал:

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

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

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

[boroda 6]

1 час назад, Baneff сказал:

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

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

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

[rtrt 14]

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

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

[l1ght 279]

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

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

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

[a_n_h 257]

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

[l1ght 279]

Только что, a_n_h сказал:

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

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

[a_n_h 257]

1 минуту назад, l1ght сказал:

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

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

[l1ght 279]

Только что, a_n_h сказал:

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

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

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

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

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

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

 

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

[a_n_h 257]

23 минуты назад, l1ght сказал:

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

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

[Baneff 29]

2 часа назад, a_n_h сказал:

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

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

[a_n_h 257]

11 минут назад, Baneff сказал:

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

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

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

 

Edited 2019-02-17 19:51:11 by a_n_h

[ramsess 140]

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

Edited 2019-02-17 20:07:47 by ramsess

[Baneff 29]

16 минут назад, ramsess сказал:

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

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

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

Edited 2019-02-17 20:23:28 by Baneff

[Baneff 29]

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

top -SCHIPz

Edited 2019-02-17 20:28:42 by Baneff

[sanyadnepr 253]

А сколько у Вас трафика и пакетов ? Что 80-90% бывает.

[Baneff 29]

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

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

[sanyadnepr 253]

Три в одном ?

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

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

 

 

[Baneff 29]

4 минуты назад, sanyadnepr сказал:

Три в одном ?

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

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

 

 

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

[skreep 1]

32 минуты назад, Baneff сказал:

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

 

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

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

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

[Baneff 29]

25 минут назад, skreep сказал:

 

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

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

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

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

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

[Baneff 29]

11 часов назад, skreep сказал:

 

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

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

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

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

 

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