Перейти до

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


Рекомендованные сообщения

Всем привет.

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

Спасибо.

Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 154
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Я бы еще хотел добавить керосинчику на это. Собственно если не ПОН, то таки активка. А Активка это уже папандец на  АКБ, ящиках и УПСах. Ну вот давате возмем и посчитаем, просто и примерно.

В 19 то году, когда у 90+ % абонов - роутеры, им по ходу должно быть пофиг пппое или ипое у провайдера...

Тільки за ряду умов - "старий" пров працює геть погано - у нового прова підключення безкоштовне - тарифи у нового прова нижчі

Posted Images

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

Ссылка на сообщение
Поделиться на других сайтах
13 минут назад, Kto To сказал:

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

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

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

Ссылка на сообщение
Поделиться на других сайтах
1 час назад, Baneff сказал:

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

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

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

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах
Только что, a_n_h сказал:

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

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

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

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

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

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

 

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

Ссылка на сообщение
Поделиться на других сайтах
23 минуты назад, l1ght сказал:

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

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

Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, a_n_h сказал:

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

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

Ссылка на сообщение
Поделиться на других сайтах
11 минут назад, Baneff сказал:

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

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

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

 

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

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

Відредаговано ramsess
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
16 минут назад, ramsess сказал:

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

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

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

Відредаговано Baneff
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

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

top -SCHIPz

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

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

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

Ссылка на сообщение
Поделиться на других сайтах
4 минуты назад, sanyadnepr сказал:

Три в одном ?

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

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

 

 

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

Ссылка на сообщение
Поделиться на других сайтах
32 минуты назад, Baneff сказал:

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

 

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

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

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

Ссылка на сообщение
Поделиться на других сайтах
25 минут назад, skreep сказал:

 

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

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах
11 часов назад, skreep сказал:

 

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

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

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

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

 

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

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

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від mac
      Здається, після оновлення PHP 7.4 до PHP 8.2 feesharvester припинив працювати:
       
      /usr/local/bin/curl "http://127.0.0.1/billing/?module=remoteapi&key={SERIAL}&action=feesharvester" <br /> <b>Fatal error</b>: Uncaught TypeError: Unsupported operand types: string - string in {UBPATH}/billing/api/libs/api.fundsflow.php:570 Stack trace: #0 {UBPATH}/billing/modules/remoteapi/feesharvester.php(22): FundsFlow-&gt;harvestFees('2024-01') ...  
      Невеличке розслідування врешті з'ясувало, що це через наявність пробілу у деяких логінах абонентів. Як так сталося? Тому що інколи був неуважно додан трейлінг пробіл до номеру будинка і цей пробіл потрапив до логіну абоненту. Логін абоненту неможливо змінити ніяким чином штатними засобами. Я не розглядаю створення нового абонента для усунення помілки.

      Був обран такий шлях вирішення проблеми. Заміну функції php explode() знайшов у мережі. Мабуть це станеться в нагоді:

       
      diff api.fundsflow.php.bak api.fundsflow.php.new 559c559 < $eachfee = explode(' ', $eachline); --- > $eachfee = preg_split("~(?<!\\\\)(?:\\\\{2})*'[^'\\\\]*(?:\\\\.[^'\\\\]*)*'(*SKIP)(*F)|\s+~s" , $eachline);  
    • Від FantoM_EscapE
      Хочу перенести свій білінг NODENY із фізичного сервера на віртуальний. Шукаю адміна який зможе допомогти у цьому питанні, так як нашого адміна банально призвали до війська. Вся схема на даний момент робоча, маю доступи до всього. Потрібно проінсталити на новішу версію FREEBSD, бо на моїй 10 річній вже не працюють нові SSL сертифікати. Кого зацікавила дана пропозиція - прошу у приватні повідомлення. обсудимо ціну і строки. або пишіть на будь-який месенджер 0677792091
    • Від rusol
      Добрый вечер.
       
      Есть от провайдера блок реальных адресов, к примеру 100.1.1.192/26
       
      Раньше сеть была в одном влане и записи в /etc/rc.conf были такие:

       
      ifconfig_ix0="inet 192.168.0.1 netmask 255.255.255.0" # Шлюз для пользователей с локальным IP ifconfig_ix0_alias0="inet 100.1.1.193 netmask 255.255.255.192" # Шлюз для пользователей с реальными IP  
      После чего стала задача часть пользователей переводить во вланы тоже с разделением на локальные IP и реальные, первый влан создал где-то пару лет назад и все работает:
       
      ifconfig_vlan1="vlan 1 vlandev ix0 192.168.1.1 netmask 255.255.255.0" # Шлюз для пользователей с локальным IP во Влане 1 ifconfig_vlan1_alias0="inet 100.1.1.248 netmask 255.255.255.248" # Шлюз для пользователей с реальными IP  во Влане 1  
      И вот стоит задача создать еще один влан, делаю по аналогии с вланом 1, только маску смещаю назад:
       
      ifconfig_vlan2="vlan 2 vlandev ix0 192.168.1.1 netmask 255.255.255.0" # Шлюз для пользователей с локальным IP во Влане 2 ifconfig_vlan2_alias0="inet 100.1.1.246 netmask 255.255.255.254" # Шлюз для пользователей с реальными IP во Влане 2  
      Когда я внес это в /etc/rc.conf и прописал команду:
       
      ifconfig vlan2 create  
      Все заработало.
       
      Но как только перезагрузился сервер, перестали работать реальные IP без вланов, в первом влане и во втором. Не пойму что не так делаю, возможно я с маской подсети что-то недопонимаю...
    • Від rusol
      Добрый вечер.
       
      Есть от провайдера блок реальных адресов, к примеру 100.1.1.192/26
       
      Раньше сеть была в одном влане и записи в /etc/rc.conf были такие:

       
      ifconfig_ix0="inet 192.168.0.1 netmask 255.255.255.0" # Шлюз для пользователей с локальным IP ifconfig_ix0_alias0="inet 100.1.1.193 netmask 255.255.255.192" # Шлюз для пользователей с реальными IP  
      После чего стала задача часть пользователей переводить во вланы тоже с разделением на локальные IP и реальные, первый влан создал где-то пару лет назад и все работает:
       
      ifconfig_vlan1="vlan 1 vlandev ix0 192.168.1.1 netmask 255.255.255.0" # Шлюз для пользователей с локальным IP во Влане 1 ifconfig_vlan1_alias0="inet 100.1.1.248 netmask 255.255.255.248" # Шлюз для пользователей с реальными IP  во Влане 1  
      И вот стоит задача создать еще один влан, делаю по аналогии с вланом 1, только маску смещаю назад:
       
      ifconfig_vlan1="vlan 1 vlandev ix0 192.168.1.1 netmask 255.255.255.0" # Шлюз для пользователей с локальным IP во Влане 2 ifconfig_vlan1_alias0="inet 100.1.1.246 netmask 255.255.255.254" # Шлюз для пользователей с реальными IP во Влане 2  
      Когда я вношу это в /etc/rc.conf и прописал команду:
       
      ifconfig vlan2 create  
      Все заработало.
       
      Но как только перезагрузился сервер, перестали работать реальные IP без вланов, в первом влане и во втором. Не пойму что не так делаю, возможно я с маской подсети что-то недопонимаю...
    • Від rusol
      Всем привет.
       
      Прошу помощи, не могу уже больше года побороть одну проблему.
       
      Иногда (раз в неделю, раз в месяц...), в основном в час пик, резко вырастает interrupt на одном из четырех ядер на сервере, на котором FreeBSD 10.1 + Nodeny + IPFW + PF + DHCP, при этом клиенты жалуются, что очень тупит интернету.
       
      Я этот симптом вижу на сервере так через top -SHPi:

       
       
      Так же наблюдаю значительное увеличение пакетов через команду netstat -hdw1 -i ix0
       
      Помогает в таких ситуациях следующее:
       
      1. Выключение на пару секунд и включение всех клиентских портов на центральном коммутаторе.
      2. Выключение по одному порту на центральном коммутаторе, но не всегда этот метод срабатывает.
      3. Иногда помогает перезагрузка сервера (но не всегда).
       
      Подскажите, на что в такой ситуации еще обратить внимание? Я ведь купирую следствие проблемы, но саму проблему не могу определить.
       
      Готов заплатить за помощь.
       

×
×
  • Створити нове...