[a0d75]

a0d75

то есть у тебя не было проблемы?

Нет, у меня была проблема только с ошибками на бродкомах eth0 и eth1. Теперь все замечательно работает, ошибок нет, процессоры загружены всего на 30%. Было так сначала:

 

sar -n DEV 1
Linux 2.6.28-hardened-r9 (peer)         09.09.2009      i686  (4 CPU)

22:41:52        IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s  txcmp/s  rxmcst/s
22:41:53           lo      0,00      0,00      0,00      0,00      0,00     0,00      0,00
22:41:53         eth2  70018,81  56774,26  78251,12  42309,03      0,00     0,00      0,99
22:41:53         eth3  60036,63  49616,83  66420,76  24430,99      0,00     0,00      0,99
22:41:53         eth0  69968,32  86043,56  43968,65  95298,16      0,00     0,00     14,85
22:41:53         eth1  30875,25  38429,70  18985,35  42520,22      0,00     0,00      0,00
22:41:53        bond0 130055,45 106391,09 144671,88  66740,02      0,00    0,00      1,98
22:41:53      vlan257  69968,32  86093,07  43012,05  95372,14      0,00     0,00     12,87
22:41:53       vlan11  30875,25  38310,89  18563,22  42395,66      0,00     0,00     11,88

sar -u ALL 1
Linux 2.6.28-hardened-r9 (peer)         09.09.2009      i686  (4 CPU)

22:42:06        CPU      %usr     %nice      %sys   %iowait    %steal     %irq     %soft    %guest     %idle
22:42:07        all      0,24      0,00      0,00      0,00      0,00     0,24     22,14      0,00     77,38
22:42:08        all      0,00      0,00      0,00      0,00      0,00     0,00     22,44      0,00     77,56
22:42:09        all      0,00      0,00      0,47      0,00      0,00     0,47     20,05      0,00     79,01
22:42:10        all      0,00      0,00      0,00      0,00      0,00     0,49     32,52      0,00     66,99

 

То что сейчас выложу вечером.

 

Кстати, как правильно посчитать pps? Если сложить сумму rxpck/s и txpck/s на eth* то что-то большая тогда цифра получается, около 460000. Вчера вечером вообще было около 700000 по информации cacti.

Изменено 14 сентября, 2009 пользователем a0d75

[a0d75]

Вот что получилось:

peer ~ # sar -n DEV 1
Linux 2.6.28-hardened-r9 (peer)         14.09.2009      _i686_  (4 CPU)

21:53:32        IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
21:53:33           lo      0,00      0,00      0,00      0,00      0,00      0,00      0,00
21:53:33         eth2 106413,00 112700,00 110302,60  96412,92      0,00      0,00      1,00
21:53:33         eth3 107903,00  91277,00 101710,54  69198,38      0,00      0,00      1,00
21:53:33         eth0  93509,00 103459,00  66627,07 105795,08      0,00      0,00     35,00
21:53:33         eth1 107518,00 103126,00  97826,75  95465,74      0,00      0,00      0,00
21:53:33        bond0 214316,00 203977,00 212013,15 165611,30      0,00      0,00      2,00
21:53:33      vlan257  93512,00 103422,00  65351,51 105755,46      0,00      0,00     23,00
21:53:33       vlan11 107518,00 103122,00  96356,78  95462,68      0,00      0,00      0,00

peer ~ # vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
1  0      0  28324 168064 683832    0    0     6     1   18   13  0 13 87  0
0  0      0  28224 168064 683836    0    0     0     0 66678 3077  0 34 66  0
0  0      0  28200 168064 683836    0    0     0     0 65448 2975  0 31 69  0
0  0      0  28200 168064 683836    0    0     0     0 66067 2946  0 37 63  0
0  0      0  28076 168064 683836    0    0     0     0 65575 2783  0 28 72  0
0  0      0  28076 168064 683836    0    0     0     0 65442 2991  0 36 64  0
0  0      0  28076 168064 683836    0    0     0     0 65444 2914  0 31 69  0

peer ~ # sar -u ALL 1
Linux 2.6.28-hardened-r9 (peer)         14.09.2009      _i686_  (4 CPU)

21:54:03        CPU      %usr     %nice      %sys   %iowait    %steal      %irq     %soft    %guest     %idle
21:54:04        all      0,00      0,00      0,00      0,00      0,00      0,80     35,28      0,00     63,93
21:54:05        all      0,00      0,00      0,00      0,00      0,00      1,78     29,44      0,00     68,78
21:54:06        all      0,00      0,00      0,00      0,00      0,00      1,06     33,51      0,00     65,44
21:54:07        all      0,00      0,00      0,00      0,00      0,00      1,21     32,77      0,00     66,02

 

[_ruslan_]

Так что ты сделал что у тебя не стало ошибок?

Ты можешь выложить мне конфиг своего ядра?

 

У меня броадком странно себя вообще ведет и более того почему то у меня в системе более 20к прерываний просто не бываетр у тебя под 65тыс.

Что подркутил чтоб так стало?

 

 

[a0d75]

Конфиг приаттачил. Что я сделал:

1. ethtool -G broadcom rx 4096 tx 4096

2. Запустил irqbalance

3. iptables NOTRACK на трафик, который проходит через маршрутизатор

 

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

kernel_config_x86_2.6.28_hardened_r9.txt

Изменено 15 сентября, 2009 пользователем a0d75

[shicoy]

iptables NOTRACK для всего трафика? а как же NAT?

[SokolovS]

shicoy: вот NAT то как раз сжирает кучу CPU :) Из-за этого стали LIR и перешли полностью на белые адреса, оставили только небольшой пул 128 адресов для трансляции 1 в 1 (без overload). Оборудование дороже обойдется ;)

[nuclearcat]

Чтоб не открывать новую тему, подниму мертвяка:

http://vger.kernel.org/netconf2009_notes_1.html

Jesper Dangaard Brouer: 10Gb bi-directional routing

 

Summary:

 

Jesper described ComX'es (Danish ISP) use of a Linux box as a 10Gbit/s Internet router as an alternative to a proprietary solution that is an order of magnitude more costly. Jesper's testing achieved full wire speed on dual-interface unidirectional workloads for packet sizes of 420 bytes or larger, and on dual-interface bidirectional workloads for packet sizes of 1280 bytes or larger. Also showed good results on Robert Olsson's internet-traffic benchmark.

 

Perhaps needless to say, careful choice of hardware and careful tuning are required to achieve these results.

 

Bottom line findings are: 10Gbit/s bi-directional routing is possible, but we are limited by the packet per second processing power, there is still memory bandwidth available.

 

Details:

 

* Short summary: Linux Network stack scales with CPUs.

 

* ComX Networks A/S: Danish Fiber Broadband provider. Motivation: 10x cheaper solution with Linux.

 

"Normal" Internet router. 2-port 10 Gbit/s router. Bidirectional, total of 40Gb/s through the interfaces. Can't use jumbo frames. Must withstand small-packet DoS attacks.

 

PCI-Express marketing numbers looked good: 160Gb/s. But in reality, only get about 54Gb/s.

* 20% encoding overhead (8b/10b encoding). But PCIe generation 2 does 4Gbit/s. 128 byte packets, which means 16% addtional overhead. 26.88Gbit/s. In addition, have PCI traffic to set up DMA addresses, things round up to cache-line sizes...

* Budgetary issues forced low-end approach: gaming hardware rather than server-class hardware.

 

CPU: Core i7 (920) vs. Phenom II X4 (940) RAM: DDR3 vs. DDR2

 

Raw memory bandwidth sufficient in all cases.

 

Network cards:

o Sun Neptune: only 16Gb/s -> 13.44Gb/s real life.

o SMC Networks: hardware queue issues, cannot parallelize.

o Intel 82599 (ixgbe): very fast!!! HotLava 6-port 10GbE doesn't require external power! 12-port 1GbE card requires external power, plus exceeds PCIe power limitations... So HotLava systems take their name seriously...

* Intel NIC and CPU Core i7 with 1333MHz DDR3 memory with Quickpath tuned properly (6.4GT/s). Single socket

* AMD did one-way 10Gb/s. Suspect HyperTransport limitations, as varying HT clock frequency varied performance.

* To achieve these results:

o Distribute load across CPUs

o Enable "multiqueue" with separate irq per queue, rx & tx. Uses -lots- of irqs.

o RX path: NIC computes hash: RSS (receive-side scaling)

o Lots of TX qdisc API hack, backwards compatible. Each TX queue gets its own qdisc to avoid qdisc scalability issues.

 

[discussion of solving serialization issue with bw shapers, applying per-CPU value-caching tricks to allow scalable traffic shaping. 1Mb/s at 1500 byte packets give 83 interactions per Mb. So hand out (say) 10 as requested. Vary based on number of CPUs and size of share.]

o Affinity irqs to spread load over CPUs.

 

Use "mpstat -A -P ALL" to validate irq spreading.

 

Make sure that corresponding RX and TX queues are on same CPU.

+ Three usage cases, for staying on same CPU

+ Forwarding (RXq to TXq other NIC): record RX queue number and use it at TX queue.

+ Server (RXq to TXq): cache socket info (thanks to Eric Dumazet).

+ Client (TXq to RXq): Hard!!! Need to use the flow director in the 10GbE Intel 82599 NIC.

o Be skeptic about generators: First runs unidirectional at wire speed for packet sizes of 768 bytes or larger. But limited by generator! Note that pktgen has some known limitations -- want to run with delay zero, otherwise pktgen does per-frame gettimeofday(). Also need faster NICs on the packet-generating systems. Stephen Hemminger is looking into optimizing pktgen.

 

With faster packet generators, generators get close to wire speed -- at wire speed for 420-byte packets and larger.

 

Some limitations due to memory bandwidth -- may need more NUMA-awareness in drivers and possibly also the network stack... Will need API from driver to give preferred buffer/queue layout in memory.

o The bidirectional throughput hits wirespeed at 1280-byte packets. Gracefully degrades for smaller packet sizes. Hitting 60,000 interrupts per second when tuned. >200,000 interrupts per seconds if untuned...

o Also tried Robert Olsson's internet traffic pattern. ("Open-source routing at 10Gb/s")

 

9.4-9.5Gb/s uni-directional.

 

11.6 Gb/s bi-directional. Preferentially dropping large packets. ;-)

 

Chipset issues result in artifacts due to cacheline size.

o At 64 byte packets achived 3.8Mpps forwarding!!! (pps = Packets Per Seconds)

o Bottom line: We are limited by Packets Per Second processing power.

o Future: use more queues than CPUs to implement QoS. Even better, use per-socket queues -- but need thousands, or even millions of queues.

[vitalyb]

Bottom line: We are limited by Packets Per Second processing power.

По-моему, это и без космических технологий понятно...

 

А так, весьма любопытно, спасибо. Дуальный квад 10 гиг пережует, так и запишем 8)

 

[nuclearcat]

* Intel NIC and CPU Core i7 with 1333MHz DDR3 memory with Quickpath tuned properly (6.4GT/s). Single socket

 

Не дуальный квад, ОДИН проц.

[vitalyb]

nuclearcat

Да, я видел. А еще там написано:

full wire speed on ... dual-interface bidirectional workloads for packet sizes of 1280 bytes or larger

... лучше бы сразу в pps'ах писали, в общем, для 10G маловато будет. Это больше на 5 похоже.

[DemYaN]

тут подробнее http://vger.kernel.org/netconf2009_slides/...rouer_final.pdf

[Max P]

Отличная пдфка =)

[photon]

Да, хороший доклад. Хотя вроде бы очевидно, что на десктопных матерях с поддержкой SLI значительная часть PCIe-лэйнов будет отдана под графику. Там другие приоритеты. Настораживает следующее утверждение: Beware: Bandwidth shapers break CPU scaling!

Изменено 8 октября, 2009 пользователем photon

[nuclearcat]

скорее всего из-за того, что нарушают multiqueue... над этим думаю работают

[photon]

Да, наверное дело в том, что сейчас дисциплину можно повесить на интерфейс, а не на одну из аппаратных очередей.

[DemYaN]

тут вроде как описывается проблема с qdisc http://vger.kernel.org/~davem/davem_nyc09.pdf?, и вроде бы есть какой-то патч авторства Миллера который эту проблему решает, но не красиво

Изменено 8 октября, 2009 пользователем DemYaN

[photon]

Кстати на той же конференции http://vger.kernel.org/netconf2009_slides/ народ активно тестирует двухсокетные матери на Nehalem и получает под 2-3 Mpps. Так что вполне можно их брать под роутинг, я считаю.

Изменено 16 октября, 2009 пользователем photon

[DemYaN]

вот только что будет если навешать htb qdisc с парой тысяч классов или conntrack включить, а просто роутинг - не интересно

[nuclearcat]

Неумеючи можно и в ложке утопится. Вам неинтересно, а всем остальным - интересно. А если делается нат и шейпер - то не на той же машинке, а как положено.

[photon]

вот только что будет если навешать htb qdisc с парой тысяч классов или conntrack включить, а просто роутинг - не интересно

Проблемы с масштабированием есть, но они точно будут решаться в будущих ядрах. Разработчики линуксовой сетевой подсистемы работают во Vyatta, делающей роутеры на PC-шном железе, и поэтому в курсе дела. Это же не OpenBSD со сферической безопасностью в вакууме и полным игнорированием реальных проблем.

Изменено 16 октября, 2009 пользователем photon

[DemYaN]

не совсем точно выразился - интересно, но ничего нового :)

 

Неумеючи можно и в ложке утопится. Вам неинтересно, а всем остальным - интересно. А если делается нат и шейпер - то не на той же машинке, а как положено.

В том то и дело - было бы ОЧЕНЬ интересно видеть результат тестов для задач шейпа/ната (для той другой машинки :) ), потому как таких докладов вообще нет. А доклады по простому роутингу (не напичканного netfilter/tc) были и раньше.

В особенности это интересно из-за multicore/multiqueue и ограничений QDSIC связанных с этим. А также как netfilter ведет себя на нескольких ядрах и прочее. Вот этого еще не было.

 

вот только что будет если навешать htb qdisc с парой тысяч классов или conntrack включить, а просто роутинг - не интересно

Проблемы с масштабированием есть, но они точно будут решаться в будущих ядрах. Разработчики линуксовой сетевой подсистемы работают во Vyatta, делающей роутеры на PC-шном железе, и поэтому в курсе дела. Это же не OpenBSD со сферической безопасностью в вакууме и полным игнорированием реальных проблем.

во, и хотелось бы видеть эти проблемы с масштабированием

Изменено 16 октября, 2009 пользователем DemYaN

[nuclearcat]

В том то и дело - было бы ОЧЕНЬ интересно видеть результат тестов для задач шейпа/ната (для той другой машинки :) ), потому как таких докладов вообще нет. А доклады по простому роутингу (не напичканного netfilter/tc) были и раньше.

В особенности это интересно из-за multicore/multiqueue и ограничений QDSIC связанных с этим. А также как netfilter ведет себя на нескольких ядрах и прочее. Вот этого еще не было.

Я приблизительно знаю как. Потому сгружаю все эти задачи на другие юниты, а бордер только роутит и блочит атаки.

 

 

[adron2]

В том то и дело - было бы ОЧЕНЬ интересно видеть результат тестов для задач шейпа/ната (для той другой машинки :) ), потому как таких докладов вообще нет. А доклады по простому роутингу (не напичканного netfilter/tc) были и раньше.

В особенности это интересно из-за multicore/multiqueue и ограничений QDSIC связанных с этим. А также как netfilter ведет себя на нескольких ядрах и прочее. Вот этого еще не было.

Я приблизительно знаю как. Потому сгружаю все эти задачи на другие юниты, а бордер только роутит и блочит атаки.

Полностью поддерживаю. У меня на бордере только бгп и пару десятков вланов для жирных клиентов которые берут больше 30 мегабит. У всех реальные ip адреса и поэтому нат вообще не используется. А уже за бордером стоит другая машинка которая натит и шейпит всякую мелочь.

 

Ну и ясное дело что на бордер заводятся свякие IX-ы, пиры и аплинки.

Изменено 17 октября, 2009 пользователем adron2

[voron]

а бордер только роутит и блочит атаки

А блочите чем? Разница например в блоке через ingress qdisc и iptables mangle prerouting - ощутимая.

[nuclearcat]

именно. еще можно по ip rule поставить правило.