bokl Posted April 13, 2011 · Report post Добрый день. У нас имеется IBM Blade Center H с 2 HX5 лезвиями, хотели попробовать попользоваться ими в качестве NAT. На лезвиях имеются сетевушки Chelsio T320 10G подключеные к 10G свичу BNT. Вообщем запустили на сервер трафик, все было хорошо пока не превысили предел 600 Kpps(3.5 Gbit/s) на вход и столько же на выход. Пошли дропы. Ошибки на сетевой и пришлось тесты приостановить. Самое интересное, что CPU и память загружены не были, вообщем то с этим точно проблем нет т.к. потоки были распаралелены по ядрам и ни одно из ядер не уходило в 100% загрузки(было где-то по 20-30%). Если дело в сетевушке, то может есть какие-то более "крутые" сетевушки? Кто сталкивался с подобной задачей или проблемой, отпишитесь плиз. Спасибо. Share this post Link to post Share on other sites
avalone Posted April 13, 2011 · Report post Тестирование Chelsio T320 Судя по всему на 600Kpps у нее насыщение по pps наступает без ТОЕ, с ним на 800Kpps. У вас HX5 стекированны (объеденины) или как отдельные лезвия? У нас просто с набортными гигабитными не упираемся в pps сетевухи. Share this post Link to post Share on other sites
bokl Posted April 13, 2011 · Report post Тестирование Chelsio T320 Судя по всему на 600Kpps у нее насыщение по pps наступает без ТОЕ, с ним на 800Kpps. У вас HX5 стекированны (объеденины) или как отдельные лезвия? У нас просто с набортными гигабитными не упираемся в pps сетевухи. Нет, не стекированы. Вот хотим попробовать соединить и получить 2 интерфейса 10G Share this post Link to post Share on other sites
cmhungry Posted April 13, 2011 · Report post Если дело в сетевушке, то может есть какие-то более "крутые" сетевушки? Intel X520-SR2, например Share this post Link to post Share on other sites
bokl Posted April 13, 2011 · Report post Если дело в сетевушке, то может есть какие-то более "крутые" сетевушки? Intel X520-SR2, например помоему это не мезанин... Share this post Link to post Share on other sites
bokl Posted April 14, 2011 · Report post вообщем провели еще одни тесты и все запротоколировали. кому интересно, результаты следующие: Затык у нас вышел следующий: Драйвер карточки делает по 6 очередей на порт. Так как у нас использовался один порт, то получили всего 6 очередей. Однако, нагрузка по очередям распределялась не равномерно. Хотя у нас на каждую очередь и выделялось отдельное ядро, все же некоторые ядра начали уходить в 100% загрузки, а некоторые не загрузились и на 50%. Вообщем как то так:( Share this post Link to post Share on other sites
shicoy Posted April 14, 2011 · Report post я как железятник может и не совсем в теме, но разве производительность подобных схем не упирается в PCI Express 2? Share this post Link to post Share on other sites
bokl Posted April 14, 2011 · Report post я как железятник может и не совсем в теме, но разве производительность подобных схем не упирается в PCI Express 2? Используемая сетевушка работает на PCIe 1.1 x8 а это 16 Гбит/с в каждую сторону. Не думаю что уперлись в это. Share this post Link to post Share on other sites
shicoy Posted April 14, 2011 · Report post Драйвер карточки делает по 6 очередей на порт. Так как у нас использовался один порт, то получили всего 6 очередей. Однако, нагрузка по очередям распределялась не равномерно. Хотя у нас на каждую очередь и выделялось отдельное ядро, все же некоторые ядра начали уходить в 100% загрузки, а некоторые не загрузились и на 50%. по всей видимости идет неравномерное распределение пакетов по очередям. проблема наверняка в драйвере Share this post Link to post Share on other sites
bokl Posted April 14, 2011 (edited) · Report post Ага....но что тут поделать? Вот кстати информация по 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 Edited April 14, 2011 by bokl Share this post Link to post Share on other sites
shicoy Posted April 14, 2011 · Report post Ага....но что тут поделать? Как обычно, ждать или писать разработчикам, типа мол хотим прокинуть 5гбит, а вы не можете, чего делать? Share this post Link to post Share on other sites
bokl Posted April 14, 2011 · Report post Если бы железо было наше, то это был бы возможный выход. А так мы на тест взяли железку, скажем не подошла и попробуем другую)) Share this post Link to post Share on other sites
Zaqwr Posted April 15, 2011 (edited) · Report post Однако, нагрузка по очередям распределялась не равномерно. Хотя у нас на каждую очередь и выделялось отдельное ядро, все же некоторые ядра начали уходить в 100% загрузки, а некоторые не загрузились и на 50%. правила iptables покажите, есть подозрение что затык у вас именно там, надо разбить на разные таблички и прерывания тогда разойдутся. да и ещё HT в биосе выключите. Edited April 15, 2011 by Zaqwr Share this post Link to post Share on other sites
bokl Posted April 15, 2011 · Report post Однако, нагрузка по очередям распределялась не равномерно. Хотя у нас на каждую очередь и выделялось отдельное ядро, все же некоторые ядра начали уходить в 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 выключен. Share this post Link to post Share on other sites
Zaqwr Posted April 15, 2011 · Report post попробуйте по сделать пару тройку таблиц и раскидать. Share this post Link to post Share on other sites
vitalyb Posted April 17, 2011 · Report post Кстати, производительность адаптера можно измерить так: если их два - то соединям их куском провода, а средствами ОС делаем на двух интерфейсах бридж (назначаем адрес и пытаемся кого-го пингануть из той подсети). Получается серьезный ARP шторм, мелкие пакеты, высокая нагрузка. Теперь, если "умерла ОС" на миллионе-другом pps'ов - можно проверить то же, но большим пакетом (прибили статикой арп, и на тот ип отправили большой удп, или каким генератором), если "умер" адаптер... ну, то он умер. Когда порт один, прийдется делать два влана и использовать коммутатор. Share this post Link to post Share on other sites
SokolovS Posted April 17, 2011 · Report post Количество bucket,ов для conntrack настраивали? С дефолтными тяжко. Share this post Link to post Share on other sites
bokl Posted April 19, 2011 · Report post Количество bucket,ов для conntrack настраивали? С дефолтными тяжко. net.netfilter.nf_conntrack_buckets = 16384 Share this post Link to post Share on other sites
bokl Posted April 27, 2011 · Report post Вообщем кому интересно. Протестировали на 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 портами. Share this post Link to post Share on other sites
Dark_Angel Posted May 1, 2011 (edited) · Report post Поздно увидел тему, жаль. Железки наверное уже отдали. Нигде не видно версии ядра. Там в предпоследних 2.6.3х были проблемы с НАТом. Как раз где-то около 4Гбит уходило в панику, а если нагрузка порядка 3Гбит, то уходило в панику в течении суток. Как с последними ядрами - не знаю, но после 2.6.27 сильно поползла вниз производительность сетевой подсистемы. Я жду пока вылижут. Далее не видно профайлера, что именно отъедает на ядре 100% в очереди. Я тоже заметил что загрузка очередей на прием распределяется не равномерно. Видимо тут играет политика распределения драйвера. У меня такого не было, что упирается одна очередь в ядро, но если бы было, я бы написал в лист интелу - думаю они ответили бы оперативно - такие тесты для них интересны. Но в любом случае, если вы ищите решение и это не подходит, то лучше пробовать что-то другое. Обработка напильником может затянуться и не дать нужного результата. Edited May 1, 2011 by Dark_Angel Share this post Link to post Share on other sites
bokl Posted May 18, 2011 · Report post Поздно увидел тему, жаль. Железки наверное уже отдали. Нигде не видно версии ядра. Там в предпоследних 2.6.3х были проблемы с НАТом. Как раз где-то около 4Гбит уходило в панику, а если нагрузка порядка 3Гбит, то уходило в панику в течении суток. Как с последними ядрами - не знаю, но после 2.6.27 сильно поползла вниз производительность сетевой подсистемы. Я жду пока вылижут. Далее не видно профайлера, что именно отъедает на ядре 100% в очереди. Я тоже заметил что загрузка очередей на прием распределяется не равномерно. Видимо тут играет политика распределения драйвера. У меня такого не было, что упирается одна очередь в ядро, но если бы было, я бы написал в лист интелу - думаю они ответили бы оперативно - такие тесты для них интересны. Но в любом случае, если вы ищите решение и это не подходит, то лучше пробовать что-то другое. Обработка напильником может затянуться и не дать нужного результата. Оборудование еще не отдали=) Протестировали на Cisco UCS B440 тоже самое. доходит трафик до определенного значения, одно из ядер добирается раньше других до 100% и П*ЗД*Ц. Пробовали на мезанинах от cisco virtual nic и на intel 10G. Вообщем все совсем плохо похоже с подобными конфигурациями. Усиленно еб*м RIPE :) Share this post Link to post Share on other sites
vitalyb Posted May 18, 2011 · Report post Так это... пробовали, что вам человек здесь http://forum.nag.ru/forum/index.php?showtopic=65838&view=findpost&p=607579 посоветовал? При этом он спросил на столько само-собой разумеющуюся вещь, что о ней никто другой и не подумал в рамках поставленной задачи. Увеличьте хотя бы до 512К, или даже до 1М. Share this post Link to post Share on other sites
bokl Posted May 19, 2011 · Report post Так это... пробовали, что вам человек здесь http://forum.nag.ru/forum/index.php?showtopic=65838&view=findpost&p=607579 посоветовал? При этом он спросил на столько само-собой разумеющуюся вещь, что о ней никто другой и не подумал в рамках поставленной задачи. Увеличьте хотя бы до 512К, или даже до 1М. Ну естественно=) Share this post Link to post Share on other sites
edgars Posted May 19, 2011 · Report post А может ОС сменить? Share this post Link to post Share on other sites
bokl Posted May 20, 2011 · Report post А может ОС сменить? пробовали редхат. тоже самое. Share this post Link to post Share on other sites
