[bokl]

Добрый день.

 

У нас имеется IBM Blade Center H с 2 HX5 лезвиями, хотели попробовать попользоваться ими в качестве NAT.

На лезвиях имеются сетевушки Chelsio T320 10G подключеные к 10G свичу BNT.

 

Вообщем запустили на сервер трафик, все было хорошо пока не превысили предел 600 Kpps(3.5 Gbit/s) на вход и столько же на выход.

Пошли дропы. Ошибки на сетевой и пришлось тесты приостановить. Самое интересное, что CPU и память загружены не были, вообщем то

с этим точно проблем нет т.к. потоки были распаралелены по ядрам и ни одно из ядер не уходило в 100% загрузки(было где-то по 20-30%).

 

 

Если дело в сетевушке, то может есть какие-то более "крутые" сетевушки?

Кто сталкивался с подобной задачей или проблемой, отпишитесь плиз.

 

 

Спасибо.

[avalone]

Тестирование Chelsio T320

 

Судя по всему на 600Kpps у нее насыщение по pps наступает без ТОЕ, с ним на 800Kpps.

 

У вас HX5 стекированны (объеденины) или как отдельные лезвия?

 

У нас просто с набортными гигабитными не упираемся в pps сетевухи.

[bokl]

Тестирование Chelsio T320

 

Судя по всему на 600Kpps у нее насыщение по pps наступает без ТОЕ, с ним на 800Kpps.

 

У вас HX5 стекированны (объеденины) или как отдельные лезвия?

 

У нас просто с набортными гигабитными не упираемся в pps сетевухи.

 

Нет, не стекированы. Вот хотим попробовать соединить и получить 2 интерфейса 10G

[cmhungry]

 

Если дело в сетевушке, то может есть какие-то более "крутые" сетевушки?

Intel X520-SR2, например

[bokl]

 

Если дело в сетевушке, то может есть какие-то более "крутые" сетевушки?

Intel X520-SR2, например

 

помоему это не мезанин...

[bokl]

вообщем провели еще одни тесты и все запротоколировали. кому интересно, результаты следующие:

 

 

 

 

Затык у нас вышел следующий:

 

Драйвер карточки делает по 6 очередей на порт. Так как у нас использовался один порт, то получили всего 6 очередей.

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

все же некоторые ядра начали уходить в 100% загрузки, а некоторые не загрузились и на 50%.

 

Вообщем как то так:(

[shicoy]

я как железятник может и не совсем в теме, но разве производительность подобных схем не упирается в PCI Express 2?

[bokl]

я как железятник может и не совсем в теме, но разве производительность подобных схем не упирается в PCI Express 2?

 

Используемая сетевушка работает на PCIe 1.1 x8 а это 16 Гбит/с в каждую сторону. Не думаю что уперлись в это.

[shicoy]

Драйвер карточки делает по 6 очередей на порт. Так как у нас использовался один порт, то получили всего 6 очередей.

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

все же некоторые ядра начали уходить в 100% загрузки, а некоторые не загрузились и на 50%.

по всей видимости идет неравномерное распределение пакетов по очередям. проблема наверняка в драйвере

[bokl]

Ага....но что тут поделать?

 

Вот кстати информация по PCI

 

07:00.0 Ethernet controller: Chelsio Communications Inc T320 10GbE Dual Port Adapter
       Subsystem: Chelsio Communications Inc Device 0001
       Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- DisINTx+
       Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
       Latency: 0
       Interrupt: pin A routed to IRQ 24
       Region 0: Memory at 98800000 (64-bit, non-prefetchable) [size=4K]
       Region 2: Memory at 98000000 (64-bit, non-prefetchable) [size=8M]
       Region 4: Memory at 98801000 (64-bit, non-prefetchable) [size=4K]
       Expansion ROM at 90100000 [disabled] [size=512K]
       Capabilities: [40] Power Management version 3
               Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
               Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
       Capabilities: [48] MSI: Enable- Count=1/32 Maskable- 64bit+
               Address: 0000000000000000  Data: 0000
       Capabilities: [58] Express (v2) Endpoint, MSI 00
               DevCap: MaxPayload 4096 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
                       ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
               DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ Unsupported-
                       RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
                       MaxPayload 256 bytes, MaxReadReq 4096 bytes
               DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
               LnkCap: Port #0, Speed 2.5GT/s, Width x8, ASPM L0s L1, Latency L0 unlimited, L1 unlimited
                       ClockPM- Surprise- LLActRep- BwNot-
               LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
                       ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
               LnkSta: Speed 2.5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
               DevCap2: Completion Timeout: Range ABC, TimeoutDis-
               DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
               LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
                        Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                        Compliance De-emphasis: -6dB
               LnkSta2: Current De-emphasis Level: -6dB
       Capabilities: [94] Vital Product Data
               Unknown small resource type 00, will not decode more.
       Capabilities: [9c] MSI-X: Enable+ Count=32 Masked-
               Vector table: BAR=4 offset=00000000
               PBA: BAR=4 offset=00000800
       Capabilities: [100 v1] Device Serial Number 00-00-00-01-00-00-00-01
       Capabilities: [300 v1] Advanced Error Reporting
               UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
               UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
               UESvrt: DLP+ SDES+ TLP+ FCP+ CmpltTO+ CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC+ UnsupReq- ACSViol-
               CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
               CEMsk:  RxErr+ BadTLP+ BadDLLP+ Rollover+ Timeout+ NonFatalErr+
               AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
       Kernel driver in use: cxgb3
       Kernel modules: cxgb3

Изменено 14 апреля, 2011 пользователем bokl

[shicoy]

Ага....но что тут поделать?

Как обычно, ждать или писать разработчикам, типа мол хотим прокинуть 5гбит, а вы не можете, чего делать?

[bokl]

Если бы железо было наше, то это был бы возможный выход. А так мы на тест взяли железку, скажем не подошла и попробуем другую))

[Zaqwr]

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

все же некоторые ядра начали уходить в 100% загрузки, а некоторые не загрузились и на 50%.

 

правила iptables покажите, есть подозрение что затык у вас именно там, надо разбить на разные таблички и прерывания тогда разойдутся. да и ещё HT в биосе выключите.

Изменено 15 апреля, 2011 пользователем Zaqwr

[bokl]

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

все же некоторые ядра начали уходить в 100% загрузки, а некоторые не загрузились и на 50%.

 

правила iptables покажите, есть подозрение что затык у вас именно там, надо разбить на разные таблички и прерывания тогда разойдутся. да и ещё HT в биосе выключите.

 

 

[0:0] -A POSTROUTING -s 10.0.0.0/8 -o eth2.861 -m mark --mark 0x355 -j

SNAT --to-source x.x.x.x-y.y.y.y --persistent

*mangle

[0:0] -A PREROUTING -m conntrack --ctstate NEW -j set_out_mark

[0:0] -A PREROUTING -i eth2.861 -m conntrack --ctstate

RELATED,ESTABLISHED -j CONNMARK --restore-mark --nfmask 0xffffffff

--ctmask 0xffffffff

[0:0] -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j CONNMARK

--restore-mark --nfmask 0xffffffff --ctmask 0xffffffff

[0:0] -A set_out_mark -i eth2.853 -j MARK --set-xmark 0x355/0xffffffff

[0:0] -A set_out_mark -i eth2.853 -j CONNMARK --save-mark --nfmask

0xffffffff --ctmask 0xffffffff

 

HT выключен.

[Zaqwr]

попробуйте по сделать пару тройку таблиц и раскидать.

[vitalyb]

Кстати, производительность адаптера можно измерить так: если их два - то соединям их куском провода, а средствами ОС делаем на двух интерфейсах бридж (назначаем адрес и пытаемся кого-го пингануть из той подсети). Получается серьезный ARP шторм, мелкие пакеты, высокая нагрузка. Теперь, если "умерла ОС" на миллионе-другом pps'ов - можно проверить то же, но большим пакетом (прибили статикой арп, и на тот ип отправили большой удп, или каким генератором), если "умер" адаптер... ну, то он умер.

 

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

[SokolovS]

Количество bucket,ов для conntrack настраивали? С дефолтными тяжко.

[bokl]

Количество bucket,ов для conntrack настраивали? С дефолтными тяжко.

 

net.netfilter.nf_conntrack_buckets = 16384

[bokl]

Вообщем кому интересно.

 

Протестировали на HX5 со scaliability kit и карточками Emulex 10G dual port adapter. Получили следующие результаты:

 

Карточка делает по 6 потоков на каждый порт сетевушки(5 на rx и 1 на tx).

однако по факту работают только 3 потока rx и 1 tx. на 2 оставшихся потоках прерывания вызываются но очень редко.

 

Итого опять 8 ядер и 4 Gbit/sec NAT в максимуме. при превышении этого порога наш RH Ent Lin 6.0 уходил в кернел паник.

 

Будем через пару недель тестировать на Cisco UCS с 4 сокетным блейдом и интеловой сетевушкой. надеюсь получим реззультаты получше чем тут.

 

Да и по настройке самого линукса. В идентичной конфигурации на имеющемся серваке мы 2.5 Gbit/s прокачиваем на значительно менее мощном сервере

с 6х1G портами.

[Dark_Angel]

Поздно увидел тему, жаль. Железки наверное уже отдали. Нигде не видно версии ядра. Там в предпоследних 2.6.3х были проблемы с НАТом. Как раз где-то около 4Гбит уходило в панику, а если нагрузка порядка 3Гбит, то уходило в панику в течении суток. Как с последними ядрами - не знаю, но после 2.6.27 сильно поползла вниз производительность сетевой подсистемы. Я жду пока вылижут.

 

Далее не видно профайлера, что именно отъедает на ядре 100% в очереди. Я тоже заметил что загрузка очередей на прием распределяется не равномерно. Видимо тут играет политика распределения драйвера. У меня такого не было, что упирается одна очередь в ядро, но если бы было, я бы написал в лист интелу - думаю они ответили бы оперативно - такие тесты для них интересны.

 

Но в любом случае, если вы ищите решение и это не подходит, то лучше пробовать что-то другое. Обработка напильником может затянуться и не дать нужного результата.

Изменено 1 мая, 2011 пользователем Dark_Angel

[bokl]

Поздно увидел тему, жаль. Железки наверное уже отдали. Нигде не видно версии ядра. Там в предпоследних 2.6.3х были проблемы с НАТом. Как раз где-то около 4Гбит уходило в панику, а если нагрузка порядка 3Гбит, то уходило в панику в течении суток. Как с последними ядрами - не знаю, но после 2.6.27 сильно поползла вниз производительность сетевой подсистемы. Я жду пока вылижут.

 

Далее не видно профайлера, что именно отъедает на ядре 100% в очереди. Я тоже заметил что загрузка очередей на прием распределяется не равномерно. Видимо тут играет политика распределения драйвера. У меня такого не было, что упирается одна очередь в ядро, но если бы было, я бы написал в лист интелу - думаю они ответили бы оперативно - такие тесты для них интересны.

 

Но в любом случае, если вы ищите решение и это не подходит, то лучше пробовать что-то другое. Обработка напильником может затянуться и не дать нужного результата.

 

Оборудование еще не отдали=)

 

Протестировали на Cisco UCS B440 тоже самое. доходит трафик до определенного значения, одно из ядер добирается раньше других до 100% и П*ЗД*Ц.

Пробовали на мезанинах от cisco virtual nic и на intel 10G.

 

Вообщем все совсем плохо похоже с подобными конфигурациями. Усиленно еб*м RIPE :)

[vitalyb]

Так это... пробовали, что вам человек здесь http://forum.nag.ru/forum/index.php?showtopic=65838&view=findpost&p=607579 посоветовал? При этом он спросил на столько само-собой разумеющуюся вещь, что о ней никто другой и не подумал в рамках поставленной задачи.

 

Увеличьте хотя бы до 512К, или даже до 1М.

[bokl]

Так это... пробовали, что вам человек здесь http://forum.nag.ru/forum/index.php?showtopic=65838&view=findpost&p=607579 посоветовал? При этом он спросил на столько само-собой разумеющуюся вещь, что о ней никто другой и не подумал в рамках поставленной задачи.

 

Увеличьте хотя бы до 512К, или даже до 1М.

 

Ну естественно=)

[edgars]

А может ОС сменить?

[bokl]

А может ОС сменить?

 

пробовали редхат. тоже самое.