a0d75 Опубликовано 14 сентября, 2009 (изменено) · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
a0d75 Опубликовано 14 сентября, 2009 · Жалоба Вот что получилось: 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_ruslan_ Опубликовано 14 сентября, 2009 · Жалоба Так что ты сделал что у тебя не стало ошибок? Ты можешь выложить мне конфиг своего ядра? У меня броадком странно себя вообще ведет и более того почему то у меня в системе более 20к прерываний просто не бываетр у тебя под 65тыс. Что подркутил чтоб так стало? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
a0d75 Опубликовано 15 сентября, 2009 (изменено) · Жалоба Конфиг приаттачил. Что я сделал: 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shicoy Опубликовано 15 сентября, 2009 · Жалоба iptables NOTRACK для всего трафика? а как же NAT? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 15 сентября, 2009 · Жалоба shicoy: вот NAT то как раз сжирает кучу CPU :) Из-за этого стали LIR и перешли полностью на белые адреса, оставили только небольшой пул 128 адресов для трансляции 1 в 1 (без overload). Оборудование дороже обойдется ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 8 октября, 2009 · Жалоба Чтоб не открывать новую тему, подниму мертвяка: 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 8 октября, 2009 · Жалоба Bottom line: We are limited by Packets Per Second processing power.По-моему, это и без космических технологий понятно... А так, весьма любопытно, спасибо. Дуальный квад 10 гиг пережует, так и запишем 8) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 8 октября, 2009 · Жалоба * Intel NIC and CPU Core i7 with 1333MHz DDR3 memory with Quickpath tuned properly (6.4GT/s). Single socket Не дуальный квад, ОДИН проц. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 8 октября, 2009 · Жалоба nuclearcat Да, я видел. А еще там написано: full wire speed on ... dual-interface bidirectional workloads for packet sizes of 1280 bytes or larger... лучше бы сразу в pps'ах писали, в общем, для 10G маловато будет. Это больше на 5 похоже. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 8 октября, 2009 · Жалоба тут подробнее http://vger.kernel.org/netconf2009_slides/...rouer_final.pdf Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 8 октября, 2009 · Жалоба Отличная пдфка =) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 8 октября, 2009 (изменено) · Жалоба Да, хороший доклад. Хотя вроде бы очевидно, что на десктопных матерях с поддержкой SLI значительная часть PCIe-лэйнов будет отдана под графику. Там другие приоритеты. Настораживает следующее утверждение: Beware: Bandwidth shapers break CPU scaling! Изменено 8 октября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 8 октября, 2009 · Жалоба скорее всего из-за того, что нарушают multiqueue... над этим думаю работают Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 8 октября, 2009 · Жалоба Да, наверное дело в том, что сейчас дисциплину можно повесить на интерфейс, а не на одну из аппаратных очередей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 8 октября, 2009 (изменено) · Жалоба тут вроде как описывается проблема с qdisc http://vger.kernel.org/~davem/davem_nyc09.pdf?, и вроде бы есть какой-то патч авторства Миллера который эту проблему решает, но не красиво Изменено 8 октября, 2009 пользователем DemYaN Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 16 октября, 2009 (изменено) · Жалоба Кстати на той же конференции http://vger.kernel.org/netconf2009_slides/ народ активно тестирует двухсокетные матери на Nehalem и получает под 2-3 Mpps. Так что вполне можно их брать под роутинг, я считаю. Изменено 16 октября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 16 октября, 2009 · Жалоба вот только что будет если навешать htb qdisc с парой тысяч классов или conntrack включить, а просто роутинг - не интересно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 16 октября, 2009 · Жалоба Неумеючи можно и в ложке утопится. Вам неинтересно, а всем остальным - интересно. А если делается нат и шейпер - то не на той же машинке, а как положено. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 16 октября, 2009 (изменено) · Жалоба вот только что будет если навешать htb qdisc с парой тысяч классов или conntrack включить, а просто роутинг - не интересно Проблемы с масштабированием есть, но они точно будут решаться в будущих ядрах. Разработчики линуксовой сетевой подсистемы работают во Vyatta, делающей роутеры на PC-шном железе, и поэтому в курсе дела. Это же не OpenBSD со сферической безопасностью в вакууме и полным игнорированием реальных проблем. Изменено 16 октября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 16 октября, 2009 (изменено) · Жалоба не совсем точно выразился - интересно, но ничего нового :) Неумеючи можно и в ложке утопится. Вам неинтересно, а всем остальным - интересно. А если делается нат и шейпер - то не на той же машинке, а как положено.В том то и дело - было бы ОЧЕНЬ интересно видеть результат тестов для задач шейпа/ната (для той другой машинки :) ), потому как таких докладов вообще нет. А доклады по простому роутингу (не напичканного netfilter/tc) были и раньше. В особенности это интересно из-за multicore/multiqueue и ограничений QDSIC связанных с этим. А также как netfilter ведет себя на нескольких ядрах и прочее. Вот этого еще не было. вот только что будет если навешать htb qdisc с парой тысяч классов или conntrack включить, а просто роутинг - не интересноПроблемы с масштабированием есть, но они точно будут решаться в будущих ядрах. Разработчики линуксовой сетевой подсистемы работают во Vyatta, делающей роутеры на PC-шном железе, и поэтому в курсе дела. Это же не OpenBSD со сферической безопасностью в вакууме и полным игнорированием реальных проблем. во, и хотелось бы видеть эти проблемы с масштабированием Изменено 16 октября, 2009 пользователем DemYaN Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 16 октября, 2009 · Жалоба В том то и дело - было бы ОЧЕНЬ интересно видеть результат тестов для задач шейпа/ната (для той другой машинки :) ), потому как таких докладов вообще нет. А доклады по простому роутингу (не напичканного netfilter/tc) были и раньше. В особенности это интересно из-за multicore/multiqueue и ограничений QDSIC связанных с этим. А также как netfilter ведет себя на нескольких ядрах и прочее. Вот этого еще не было. Я приблизительно знаю как. Потому сгружаю все эти задачи на другие юниты, а бордер только роутит и блочит атаки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adron2 Опубликовано 17 октября, 2009 (изменено) · Жалоба В том то и дело - было бы ОЧЕНЬ интересно видеть результат тестов для задач шейпа/ната (для той другой машинки :) ), потому как таких докладов вообще нет. А доклады по простому роутингу (не напичканного netfilter/tc) были и раньше. В особенности это интересно из-за multicore/multiqueue и ограничений QDSIC связанных с этим. А также как netfilter ведет себя на нескольких ядрах и прочее. Вот этого еще не было. Я приблизительно знаю как. Потому сгружаю все эти задачи на другие юниты, а бордер только роутит и блочит атаки. Полностью поддерживаю. У меня на бордере только бгп и пару десятков вланов для жирных клиентов которые берут больше 30 мегабит. У всех реальные ip адреса и поэтому нат вообще не используется. А уже за бордером стоит другая машинка которая натит и шейпит всякую мелочь. Ну и ясное дело что на бордер заводятся свякие IX-ы, пиры и аплинки. Изменено 17 октября, 2009 пользователем adron2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
voron Опубликовано 17 октября, 2009 · Жалоба а бордер только роутит и блочит атаки А блочите чем? Разница например в блоке через ingress qdisc и iptables mangle prerouting - ощутимая. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 17 октября, 2009 · Жалоба именно. еще можно по ip rule поставить правило. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...