[zlolotus]

Коллеги, Доброго времени суток.

 

Подскажите, кто нибудь держит бордер на freebsd 9.3 с платой x520-da2

 

Если не сложно поделитесь опытом(cpu, обьем трафика etc ) , sysctl.conf loader.conf

 

top -SPH и netstat -hw 1

[catalist]

Поддерживаю вопрос.

[kosmich7]

zlolotus тут обсуждалось.

Какой объем трафика, на каком "уровне" железа вас интересует ?

Есть на 9.3 с da2, от 2 до 5Гбит, от 350 NAT до 500-600Кппс, i5-i7 нагрузка ~50%.

 

У меня другой вопрос, сколько прерываний будет у x520 с двумя 8 ядерными процами и 16 потоками и как это скажется на производительности бордера в целом в сравнении с i7-5960x ?

[Ivan_83]

Количество прерываний зависит от тюнинга дров через лоадер/сисцтл и от пакетрейта.

Лучше подробности в мане или исходниках посмотреть.

[roysbike]

Под freebsd еще на 9.0 или 9.1 (не помню точно) и x520 в своем время у меня с NAT больше 1.5Гбит были серьезные проблемы. Поставил linux и все отлично, 3-й год уже и 6-7 Гбит натит без проблем.

Edited November 24, 2015 by roysbike

[kosmich7]

Под freebsd еще на 9.0 или 9.1 (не помню точно) и x520 в своем время у меня с NAT больше 1.5Гбит были серьезные проблемы.

Расскажите подробней, на каком железе, какие именно были проблемы ?

[rdc]

У меня были проблемы с ipfw nat - у некоторых юзеров было какое-то нереальное количество коннектов.

Сделал лимит в 2000 коннектов на рыло - с тех пор много лет всё хорошо.

[apm]

Сделал лимит в 2000 коннектов на рыло - с тех пор много лет всё хорошо.

В каком месте этот лисит сделали?

[vlad11]

Сделал лимит в 2000 коннектов на рыло - с тех пор много лет всё хорошо.

В каком месте этот лисит сделали?

 

Наверное,

ipfw ... limit src-addr 2000

 

Главное, не перепутать направления и интерфейсы!

[roysbike]

Под freebsd еще на 9.0 или 9.1 (не помню точно) и x520 в своем время у меня с NAT больше 1.5Гбит были серьезные проблемы.

Расскажите подробней, на каком железе, какие именно были проблемы ?

ProLiant DL360e Gen8 part 668815-421 (Intel® Xeon® CPU E5-2430 0 @ 2.20GHz всего 12ядер)

 

NAT был на pf. После 1 гбит ната , резко взлетал cpu на всех прерываниях сетевухи, load average доходило до 40. До 1 гбит/с было все хорошо, но на cpu была высокая нагрузка (30-40% на ядро). Тюниг делал, но не было много времени разбираться, в срочном порядка перешел на linux и забыл. Как бы я не любил freebsd , я скажу от себя- для роутинга и nat используйте linux.

Edited November 24, 2015 by roysbike

[kosmich7]

Под freebsd еще на 9.0 или 9.1 (не помню точно) и x520 в своем время у меня с NAT больше 1.5Гбит были серьезные проблемы.

Расскажите подробней, на каком железе, какие именно были проблемы ?

ProLiant DL360e Gen8 part 668815-421 (Intel® Xeon® CPU E5-2430 0 @ 2.20GHz всего 12ядер)

 

NAT был на pf. После 1 гбит ната , резко взлетал cpu на всех прерываниях сетевухи, load average доходило до 40. До 1 гбит/с было все хорошо, но на cpu была высокая нагрузка (30-40% на ядро). Тюниг делал, но не было много времени разбираться, в срочном порядка перешел на linux и забыл. Как бы я не любил freebsd , я скажу от себя- для роутинга и nat используйте linux.

Странно...сейчас 9.3 десктопный бордер i7 жует с натом 2G/300Кpps, прерывания растут в линейной зависимости от пакетов.

А как были распределены прерывания по ядрам/камням, сколько физических интерфейсов ?

[roysbike]

Под freebsd еще на 9.0 или 9.1 (не помню точно) и x520 в своем время у меня с NAT больше 1.5Гбит были серьезные проблемы.

Расскажите подробней, на каком железе, какие именно были проблемы ?

ProLiant DL360e Gen8 part 668815-421 (Intel® Xeon® CPU E5-2430 0 @ 2.20GHz всего 12ядер)

 

NAT был на pf. После 1 гбит ната , резко взлетал cpu на всех прерываниях сетевухи, load average доходило до 40. До 1 гбит/с было все хорошо, но на cpu была высокая нагрузка (30-40% на ядро). Тюниг делал, но не было много времени разбираться, в срочном порядка перешел на linux и забыл. Как бы я не любил freebsd , я скажу от себя- для роутинга и nat используйте linux.

Странно...сейчас 9.3 десктопный бордер i7 жует с натом 2G/300Кpps, прерывания растут в линейной зависимости от пакетов.

А как были распределены прерывания по ядрам/камням, сколько физических интерфейсов ?

 

Сейчас 2 порта sfp+ по 12 очередй на ядро. Сейчас молотит почти 7 гбит, по ядра не больше 40% , пакетов уже 1 млн

[rdc]

В каком месте этот лимит сделали?

/usr/src/sys/netinet/libalias/alias_db.c

AddLink()

 

добавил

 

switch (link_type) {
case LINK_ICMP:
       if(la->icmpLinkCount > 100) return (NULL);
       break;
case LINK_UDP:
       if(la->udpLinkCount > 2000) return (NULL);
       break;
case LINK_TCP:
       if(la->tcpLinkCount > 2000) return (NULL);
       break;
default:
       if(la->protoLinkCount > 100) return (NULL);
       break;
}

[vlad11]

Под freebsd еще на 9.0 или 9.1 (не помню точно) и x520 в своем время у меня с NAT больше 1.5Гбит были серьезные проблемы.

Расскажите подробней, на каком железе, какие именно были проблемы ?

ProLiant DL360e Gen8 part 668815-421 (Intel® Xeon® CPU E5-2430 0 @ 2.20GHz всего 12ядер)

 

NAT был на pf. После 1 гбит ната , резко взлетал cpu на всех прерываниях сетевухи, load average доходило до 40. До 1 гбит/с было все хорошо, но на cpu была высокая нагрузка (30-40% на ядро). Тюниг делал, но не было много времени разбираться, в срочном порядка перешел на linux и забыл.

 

Поздравляю, вы словили бродкаст-шторм внутри сети. Учитесь тюнинговать систему и коммутаторы.

[roysbike]

Под freebsd еще на 9.0 или 9.1 (не помню точно) и x520 в своем время у меня с NAT больше 1.5Гбит были серьезные проблемы.

Расскажите подробней, на каком железе, какие именно были проблемы ?

ProLiant DL360e Gen8 part 668815-421 (Intel® Xeon® CPU E5-2430 0 @ 2.20GHz всего 12ядер)

 

NAT был на pf. После 1 гбит ната , резко взлетал cpu на всех прерываниях сетевухи, load average доходило до 40. До 1 гбит/с было все хорошо, но на cpu была высокая нагрузка (30-40% на ядро). Тюниг делал, но не было много времени разбираться, в срочном порядка перешел на linux и забыл.

 

Поздравляю, вы словили бродкаст-шторм внутри сети. Учитесь тюнинговать систему и коммутаторы.

Нет. шторма быть впринципе не могло. Сервер в качестве бордера и nat, клинты включены в bras, Да и в сети vlan per user поймать шторм надо постараться. Если конечно свичи не настроены. По графиками было четко видно, как только перехлынуло за 1 гбит, сразу улетал cpu. как только снимжается, все ок. Наверное где то нужно было подтюнить. Но bras на freebsd без nat, роутил 3 гбит не напрягась.

[rdc]

pf в те времена не умел параллелиться - он мог упереться в одно ядро, а дрова сетевухи тупо ждали, когда он освободится

точнее не скажу - не пользуюсь pf

 

на ipfw таких проблем нет, параллелится прекрасно

[kosmich7]

Количество прерываний зависит от тюнинга дров через лоадер/сисцтл и от пакетрейта.

Лучше подробности в мане или исходниках посмотреть.

Подскажите пожалуйста на что именно стоит обратить внимание ? Посмотреть в исходниках - не силен.

Столкнулся с ситуацией, неполучается распределить прерывания на 16/32 ядра, макисмально получаются дефолтные 8 прерываний на каждый порт 520-DA2 карте которые вешаются на первые 8 ядер и "затыки"(80.58% intr{irq269: ix0:que }) в двухпроцессорной ситеме, рост пинга, в топе периодический рост нагрузки до(60.00% kernel{ix0 que} 8/16 потоков) и выше загрузка ядер.

Прерывания двух портов на первых восьми ядрах, system(kernel) на последних 16 ядрах из 32. Вышеописанное происходит примерно при гигабите трафа, начинается где то с 500 мбит, kernel{ix0 que} поднимается циклически до 5-10%, через некоторое время 1%, на предыдущих системах/процах такого не наблюдалось в принципе.

9.3-STABLE FreeBSD 9.3-STABLE #1: Wed Dec  9 10:16:31 EET 2015 amd64

На 10.2 вообще плачевно, очереди kernel со старта 100%, второй проц все ядра в полке, работает как старый калькулятор.

Тюнинг минимально необходимый, можно сказать что его нет, i5-i7 работает здесь же как часы, 50% максимум нагрузка.

[zlolotus]

Расскажите у вас там чисто bgp, или нат ?

 

Или что вообще?

 

так бы не мешало бы показать sysctl.conf И loader.conf

[kosmich7]

Расскажите у вас там чисто bgp, или нат ?

У нас там чисто конретно :-) и то и то.

 

Там пару строк, нечего там показывать.

[rdc]

Можно вместо распределения прерываний сетевухой, распределить обработку трафика по ядрам настройками net.isr.

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

[Ivan_83]

Столкнулся с ситуацией, неполучается распределить прерывания на 16/32 ядра, макисмально получаются дефолтные 8 прерываний на каждый порт 520-DA2 карте которые вешаются на первые 8 ядер и "затыки"(80.58% intr{irq269: ix0:que }) в двухпроцессорной ситеме, рост пинга, в топе периодический рост нагрузки до(60.00% kernel{ix0 que} 8/16 потоков) и выше загрузка ядер.

Я не интересовался как там прерывания биндятся, и вообще последний раз копался ещё в 9х ядре в сетевой части.

Количество прерываний от сетевухи - скорее всего её аппаратное ограничение.

То что они вешаются на первые 8 ядер в принципе логично: на таких конфигурациях как ни делай всё равно плохо будет.

 

Если просто то: не используйте многопроцессорные тазики для сетевых задач.

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

Те даже если прерывания равномерно размазать по ядрам разных процов руками это вовсе не значит что ситуация изменится, они (процы) вероятнее всего лочатся/получают пенальти при осуществлении NAT, баскетов мало или ещё какая то особенность реализации.

Чтобы как улучшить ситуацию есть flowid, привязка руками прерываний, netisr, использование нескольких раздельных nat (например: несколько ng_nat) и тп, но это требует времени и квалификации, проще поставить однопроцовый тазик.

 

Вот так можно посмотреть где затыки:

kldload hwpmc

pmcstat -TS instructions -w1

[kosmich7]

rdc спасибо, попробую.

 

То что они вешаются на первые 8 ядер в принципе логично: на таких конфигурациях как ни делай всё равно плохо будет.

А как же это прекрасно работает на двухпроцессорных 4/8 ядра 8/16 потоков платформах ?!

Разнести NAT не проблема, хотелось немного 10G портов сэкономить, поэтому такая реализация.

 

Спасибо. Попробую еще поэксперементировать.

 

В FreeBSD 9.3-RELEASE-p9 #4: Thu Jan 29 11:52:53 EET 2015 amd64 эта проблема проявляется существенно меньше,

после FreeBSD 9.3-STABLE #1: Wed Dec 9 10:16:31 EET 2015 amd64 более ярко выражена.

[kayot]

kosmich7

У разных платформ NUMA-ноды организованы по разному. Плюс, что в данном случае даже важнее - где-то PCI-e контроллер расположен в чипсете, где-то - в CPU.

Во втором случае начинается печаль, двухголовая сетевка висит на PCIe контроллере встроенном в CPU1, а обработка прерываний от второго порта отправлена на CPU2 - каждый пакет несколько раз копируется между CPU, что грустно с точки зрения производительности. Intel рекомендует использовать одноголовые сетевки, вставляя их в слоты принадлежащие нужному CPU.

А для двухголовой сетевки бывает выгоднее вообще второй CPU в такой конфигурации не задействовать..

[kosmich7]

А для двухголовой сетевки бывает выгоднее вообще второй CPU в такой конфигурации не задействовать..

Это план Б.

[kayot]

А платформа какая? 2011?

Тогда план А должен быть - замена сетевки на 2е одноголовые.