Justas Опубликовано 14 января, 2011 · Жалоба 3. Проблема известна, но с решением вы поторопились. Даже не знаю что вам теперь делать, учитывая отсутствие возможности масштабирования у pptp. Roundrobin DNS и второй сервер? Видимо, так... И потихоньку отключать шифрование у пользователей. Понятно, что в текущих реалиях оставлять его причин нет. 4. Учтите, что увеличение буфера усугубляет ситуацию. Чем меньше буфер, тем быстрее работает. При вашем трафике однако тут не большой вклад будет. Сразу хотел спросить: ложит ли смена буфера интерфейс или происходит налету? Опускает интерфейс на 6 секунд. Не критично. UPD. Кстати, а откуда это? Этот ксеон может 4Ггц но работает на 1.8? External Clock: 133 MHz Max Speed: 4000 MHz Current Speed: 1866 MHz Если у него 2 ядра, а остальные HT, то HT на роутерах вреден и его надо отключать. С другой стороны, у вас опять-таки не чистый роутер. Core Count: 2 Core Enabled: 2 Thread Count: 2 Судя по спецификам на процессор - http://ark.intel.com/Product.aspx?id=37092...pec-codes=SLBEZ - гипертрединга там нет и в нем 2 ядра. Так что мои 2 процессора и в сумме 4 ядра - они самые настоящие. А вот то, что система показывает о возможности работы на частоте 4 ГГц, наверняка его можно множителями или еще какой фигнёй разогнать. Я тут читал в какой-то теме флейм по этому вопросу (разгон с целью повышения производительности роутера), но я не приверженец таких методов. Надежность важнее. Сейчас час-пик: # vmstat 1 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 0 143232 131980 5643200 0 0 0 0 59275 15101 18 27 55 0 0 3 0 0 143232 131980 5643200 0 0 0 0 60050 14741 20 28 52 0 0 2 0 0 143232 131980 5643200 0 0 0 0 59620 14692 19 34 47 0 0 2 0 0 143108 131980 5643204 0 0 0 0 56969 15738 19 40 41 0 0 4 0 0 142484 131980 5643204 0 0 0 128 60718 15852 23 43 32 3 0 3 0 0 142596 131980 5643208 0 0 0 0 62877 18599 21 37 43 0 0 2 0 0 142620 131980 5643208 0 0 0 0 66078 16573 23 29 48 0 0 3 0 0 142620 131980 5643208 0 0 0 0 62329 16206 21 26 52 0 0 2 0 0 142620 131980 5643208 0 0 0 0 59941 16043 22 30 48 0 0 2 0 0 142496 131984 5643204 0 0 0 132 61145 16039 22 28 48 2 0 2 0 0 142496 131984 5643208 0 0 0 8 60330 15988 22 30 48 0 0 В целом всё красиво. ITR изменю на днях. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Justas Опубликовано 14 января, 2011 · Жалоба Сетевая с e1000 не может нормально раскидывать очереди по ядрам, с одним интерфейсом так и должно быть, одно ядро под планку, на втором чего-то эпизодически, а остальные свободны.Зачем вы такую странную схему придумали, весь трафик через одну сетевку пустить? В этом случае количество трафика через интерфейс еще и удваивается, и через интерфейс бегает (вход + исход) * 2. При ваших '340 мбит в одну сторону' суммарно трафика может получиться и больше гига, тут уже самим сетевкам простым может плохеть)) Перевесьте виланы входящий на eth0, исходящий на eth1, а интерфейс используемый для сбора статистики или повесьте виланом на любой из них, или вообще схему поменяйте. У меня e1000e. Схема такая, потому как всё приходит с опытом. У меня и мысли не возникало, что трафик на виланах сможет настолько сильно деградировать производительность. Сначала поиграюсь с ITR, а на следующей неделе поставлю Intel 1000ET, уберу виланы и разведу очереди по ядрам. Посмотрим, насколько это положительно отразится. Ну, и от шифрования нужно избавляться. Туда льется тот же трафик что и через сервер проходит? Да, но не весь. Часть трафика зеркалируется с другого сервера. Именно поэтому такая схема. Я понимаю вашу идею снимать данные непосредственно с интерфейса, который участвует в маршрутизации, но не в моем случае. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 14 января, 2011 · Жалоба У меня e1000e. Схема такая, потому как всё приходит с опытом. У меня и мысли не возникало, что трафик на виланах сможет настолько сильно деградировать производительность. Сначала поиграюсь с ITR, а на следующей неделе поставлю Intel 1000ET, уберу виланы и разведу очереди по ядрам. Посмотрим, насколько это положительно отразится. Ну, и от шифрования нужно избавляться. В вашем конкретном случае установка ET board решит все проблемы, и шифрование можно будет не трогать. Разделите вход/исход + для самих интерфейсов с msi-x и драйвером IGB очереди раскидаете по ядрам - для pptp нагрузка равномерно распределится на все 4 ядра(2 для одного интерфейса, 2 для другого, очереди на вход/исход лучше совмещенные). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 14 января, 2011 · Жалоба Ну а кроме радикальных методов(добавление сетевок) есть все-таки более простые методы. 1) разбить трафик на 2 физических интерфейса. Vlan10 на eth0, vlan100 на eth1, mirror трафик идущий на eth1 затегировать и лить на любой из интерфейсов, от него нагрузки практически не будет. Загрузка должна поделиться на 2 ядра более-менее равномерно. 2) использовать rss/rfs ядра 2.6.35, по идее можно всю вашу нагрузку разбить на 4 ядра. Оно конечно не столь эффективно как аппаратные очереди ET board, но тоже работает. Останется только перегрузка интерфейса трафиком, но все равно будет лучше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 15 января, 2011 · Жалоба 2Justas: Процессор разгонять, конечно, не надо на роутере. Если у вас все 4 ядра честные, тогда гут. Тут, кстати правильно kayot подсказывает насчет rss/rfs - может помочь, попробуйте. Я лично, не знаю как работают софтовые очереди, так как не было необходимости. Если же у вас есть под рукой сетевая с MSI-X, то меняйте и не парьтесь. Поможет радикально. Остальные моменты упомянутые здесь при этом тоже нужно реализовать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cayz Опубликовано 15 января, 2011 · Жалоба А подскажите пожалуйста, а то перечитал и так и не понял: [ 3.483863] igb 0000:02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 3.483938] igb 0000:02:00.0: setting latency timer to 64 [ 3.484187] igb: 0000:02:00.0: igb_validate_option: Interrupt Throttling Rate (ints/sec) set to 5000 [ 3.484271] igb: 0000:02:00.0: igb_validate_option: Interrupt Mode set to 2 [ 3.484334] igb: 0000:02:00.0: igb_validate_option: RSS - RSS multiqueue receive count set to 8 [ 3.484485] igb 0000:02:00.0: irq 46 for MSI/MSI-X [ 3.484491] igb 0000:02:00.0: irq 47 for MSI/MSI-X [ 3.484496] igb 0000:02:00.0: irq 48 for MSI/MSI-X [ 3.484502] igb 0000:02:00.0: irq 49 for MSI/MSI-X [ 3.484507] igb 0000:02:00.0: irq 50 for MSI/MSI-X [ 3.484516] igb 0000:02:00.0: irq 51 for MSI/MSI-X [ 3.484521] igb 0000:02:00.0: irq 52 for MSI/MSI-X [ 3.484526] igb 0000:02:00.0: irq 53 for MSI/MSI-X [ 3.484531] igb 0000:02:00.0: irq 54 for MSI/MSI-X [ 3.730611] igb 0000:02:00.0: Intel(R) Gigabit Ethernet Network Connection [ 3.730675] igb 0000:02:00.0: eth0: (PCIe:2.5Gb/s:Width x4) 00:1b:21:48:3b:4c [ 3.731001] igb 0000:02:00.0: eth0: PBA No: E43709-003 [ 3.731060] igb 0000:02:00.0: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s) [ 3.731157] igb 0000:02:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17 [ 3.731226] igb 0000:02:00.1: setting latency timer to 64 [ 3.731439] igb: 0000:02:00.1: igb_validate_option: Interrupt Throttling Rate (ints/sec) set to 5000 [ 3.731523] igb: 0000:02:00.1: igb_validate_option: Interrupt Mode set to 2 [ 3.731586] igb: 0000:02:00.1: igb_validate_option: RSS - RSS multiqueue receive count set to 8 [ 3.731704] igb 0000:02:00.1: irq 55 for MSI/MSI-X [ 3.731709] igb 0000:02:00.1: irq 56 for MSI/MSI-X [ 3.731715] igb 0000:02:00.1: irq 57 for MSI/MSI-X [ 3.731720] igb 0000:02:00.1: irq 58 for MSI/MSI-X [ 3.731726] igb 0000:02:00.1: irq 59 for MSI/MSI-X [ 3.731732] igb 0000:02:00.1: irq 60 for MSI/MSI-X [ 3.731737] igb 0000:02:00.1: irq 61 for MSI/MSI-X [ 3.731743] igb 0000:02:00.1: irq 62 for MSI/MSI-X [ 3.731749] igb 0000:02:00.1: irq 63 for MSI/MSI-X [ 3.980563] igb 0000:02:00.1: Intel(R) Gigabit Ethernet Network Connection [ 3.980627] igb 0000:02:00.1: eth1: (PCIe:2.5Gb/s:Width x4) 00:1b:21:48:3b:4d [ 3.980952] igb 0000:02:00.1: eth1: PBA No: E43709-003 [ 3.981011] igb 0000:02:00.1: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s) Итого по 8 TXRX очередей для 2х интерфейсов. Interrupt Throttling Rate (ints/sec) set to 5000 - этот параметр применяется для устройства или для каждой очереди, А то всё равно показывает 60К прерываний в секунду. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 16 января, 2011 (изменено) · Жалоба Это количество прерываний на очередь. Итого у вас 16 очередей, а не 8. По 8 на каждый интерфейс. Да еще и ITR стоит 2, вот только что это за режим? Изменено 16 января, 2011 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lionel Опубликовано 18 января, 2011 · Жалоба у меня на железке с 10гбит сетевухой не пашет ioatdma и DCA на Intel Corporation 5000 Series Chipset с тем же конфигом оси и дров всё работает, по крайней мере ошибок в dmesg нет ни от ioatdma ни от ixgbe в биосе IOAT и DCA включены. сетевуха такая: Intel Corporation 82599EB 10-Gigabit Network Connection платформа: supermicro x8dtu-f системная плата 2xIntel® Xeon® CPU X5650 @ 2.67GHz 12 ядер 24 потока чипсет: Intel Corporation 5520/5500/X58 lsmod: dca 3633 3 igb,ixgbe,ioatdma проблема кажется именно в ioatdma, если вынуть сетевуху то всё равно Intel® I/OAT DMA Engine init failed вот что происходит dmesg | grep "ioat\|dca\|ixgbe" [ 10.436322] dca service started, version 1.12.1 [ 10.596656] ioatdma: Intel® QuickData Technology Driver 4.00 [ 10.596714] ioatdma 0000:00:16.0: PCI INT A -> GSI 43 (level, low) -> IRQ 43 [ 10.596760] ioatdma 0000:00:16.0: setting latency timer to 64 [ 10.596768] ioatdma 0000:00:16.0: channel error register unreachable [ 10.596769] ioatdma 0000:00:16.0: channel enumeration error [ 10.596772] ioatdma 0000:00:16.0: Intel® I/OAT DMA Engine init failed [ 10.596783] ioatdma 0000:00:16.0: PCI INT A disabled [ 10.628435] ixgbe 0000:05:00.0: PCI INT A -> GSI 34 (level, low) -> IRQ 34 [ 10.628445] ixgbe 0000:05:00.0: setting latency timer to 64 [ 10.778101] ixgbe: Direct Cache Access (DCA) set to 1 [ 10.778103] ixgbe: Receive-Side Scaling (RSS) set to 12 [ 10.778109] ixgbe: 0000:05:00.0: ixgbe_check_options: dynamic interrupt throttling enabled [ 10.778111] ixgbe: 0000:05:00.0: ixgbe_check_options: Flow Director hash filtering enabled [ 10.778113] ixgbe: 0000:05:00.0: ixgbe_check_options: Flow Director allocated 64kB of packet buffer [ 10.778115] ixgbe: 0000:05:00.0: ixgbe_check_options: ATR Tx Packet sample rate set to default of 20 [ 10.778117] ixgbe: Node to start on set to 0 [ 10.778118] ixgbe: 0000:05:00.0: ixgbe_check_options: node set to 0 [ 10.800780] ixgbe 0000:05:00.0: irq 81 for MSI/MSI-X [ 10.800785] ixgbe 0000:05:00.0: irq 82 for MSI/MSI-X [ 10.800789] ixgbe 0000:05:00.0: irq 83 for MSI/MSI-X [ 10.800793] ixgbe 0000:05:00.0: irq 84 for MSI/MSI-X [ 10.801040] ixgbe: 0000:05:00.0: ixgbe_init_interrupt_scheme: Multiqueue Enabled: Rx Queue count = 24, Tx Queue count = 24 [ 10.801860] ixgbe: eth0: ixgbe_probe: No DCA provider found. Please start ioatdma for DCA functionality. [ 10.801862] ixgbe: eth0: ixgbe_probe: (PCI Express:5.0Gb/s:Width x8) 00:1b:21:74:57:54 [ 10.801940] ixgbe: eth0: ixgbe_probe: MAC: 2, PHY: 15, SFP+: 5, PBA No: E68785-003 [ 10.801942] ixgbe: eth0: ixgbe_probe: GRO is enabled [ 10.801943] ixgbe: eth0: ixgbe_probe: HW RSC is enabled [ 10.802531] ixgbe: eth0: ixgbe_probe: Intel® 10 Gigabit Network Connection подозреваю что из-за этого уже при 3 гигабитах сквозного трафика загрузка процов за 50%, потери и подскоки пинга судя по этой статье в моём случае что-то явно не так: http://nag.ru/articles/article/19974/kak-m...tizirovali.html Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cayz Опубликовано 20 января, 2011 (изменено) · Жалоба Это количество прерываний на очередь. Итого у вас 16 очередей, а не 8. По 8 на каждый интерфейс. Да еще и ITR стоит 2, вот только что это за режим? IntMode Режим работы с прерываниями. Valid Range: 0-2 (0=legacy, 1=MSI, 2=MSI-X), насколько я понимаю по умолчанию само собой режим MSI-X устанавливается. Просто параметр в initrd прописан. UPD: а вообще, какое число выбирать, у меня по 8 очередей исходя из того, что два ксеона по 4 ядра стоят, сам тазик обслуживает около 600 мегабит и держит до 900 PPTP сессий на accel-pptp. Загрузка процессоров в пик уже к 90% подбирается, ip_conntrack в состоянии NOTRACK (белые адреса) - это последнее что помогло снизить загруз, сейчас начал мучать драйвера. Изменено 20 января, 2011 пользователем Cayz Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 22 января, 2011 · Жалоба Я перепутал IntMode с ITR. Однозначно должно стоять 2, если карта поддерживает. Это самый "дешевый" и производительный режим работы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Justas Опубликовано 28 января, 2011 · Жалоба Тут, кстати правильно kayot подсказывает насчет rss/rfs - может помочь, попробуйте. Я лично, не знаю как работают софтовые очереди, так как не было необходимости. Если же у вас есть под рукой сетевая с MSI-X, то меняйте и не парьтесь. Поможет радикально. Остальные моменты упомянутые здесь при этом тоже нужно реализовать. RFS/RPS посмотрел, настроил, оценил. Что-то как-то не впечатлило сильно... В общем поставил 1000ET с igb драйвером, убрал вланы, разбил очереди, снизил количество клиентов с шифрованием на 20%. Сейчас всё хорошо. Спасибо всем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
silitra Опубликовано 14 февраля, 2011 (изменено) · Жалоба RPS сервер DL360G4 Cent OS 5.5 сетевой адаптер HP NC7170, 2 порта Gigabit Ethernet на чипе Intel 82546EB отсюда http://shop.nag.ru/catalog/item/04483 90k pps туда и столько же обратно. потолок 500 Мбит, до этого стояло ядро 2.6.18 без RPS, упирался в 300Мбит - начинались дропы, 2 ядра простаивали. echo 3 > /sys/class/net/eth2/queues/rx-0/rps_cpus echo c > /sys/class/net/eth3/queues/rx-0/rps_cpus # uname -a Linux shaper 2.6.35.9 #1 SMP Thu Feb 10 08:06:47 YEKT 2011 i686 i686 i386 GNU/Linux #ethtool -i eth2 driver: e1000 version: 7.3.21-k6-NAPI firmware-version: N/A bus-info: 0000:07:01.1 #modinfo e1000 filename: /lib/modules/2.6.35.9/kernel/drivers/net/e1000/e1000.ko version: 7.3.21-k6-NAPI license: GPL description: Intel(R) PRO/1000 Network Driver author: Intel Corporation, <linux.nics@intel.com> srcversion: 68AEB9D8B34E0591820C149 depends: vermagic: 2.6.35.9 SMP mod_unload modversions 686 4KSTACKS parm: TxDescriptors:Number of transmit descriptors (array of int) parm: RxDescriptors:Number of receive descriptors (array of int) parm: Speed:Speed setting (array of int) parm: Duplex:Duplex setting (array of int) parm: AutoNeg:Advertised auto-negotiation setting (array of int) parm: FlowControl:Flow Control setting (array of int) parm: XsumRX:Disable or enable Receive Checksum offload (array of int) parm: TxIntDelay:Transmit Interrupt Delay (array of int) parm: TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int) parm: RxIntDelay:Receive Interrupt Delay (array of int) parm: RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int) parm: InterruptThrottleRate:Interrupt Throttling Rate (array of int) parm: SmartPowerDownEnable:Enable PHY smart power down (array of int) parm: copybreak:Maximum size of packet that is copied to a new buffer on receive (uint) parm: debug:Debug level (0=none,...,16=all) (int) # lspci -v 07:01.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01) Subsystem: Compaq Computer Corporation NC7170 Gigabit Server Adapter Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 48 Memory at fdfe0000 (64-bit, non-prefetchable) [size=128K] Memory at fdf80000 (64-bit, non-prefetchable) [size=256K] I/O ports at 5000 [size=64] [virtual] Expansion ROM at 80000000 [disabled] [size=256K] Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- 07:01.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01) Subsystem: Compaq Computer Corporation NC7170 Gigabit Server Adapter Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 49 Memory at fdf60000 (64-bit, non-prefetchable) [size=128K] I/O ports at 5040 [size=64] Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- #cat /proc/cpuinfo | grep name model name : Intel(R) Xeon(TM) CPU 3.00GHz model name : Intel(R) Xeon(TM) CPU 3.00GHz model name : Intel(R) Xeon(TM) CPU 3.00GHz model name : Intel(R) Xeon(TM) CPU 3.00GHz #top top - 19:15:28 up 4 days, 10:50, 5 users, load average: 0.44, 0.37, 0.29 Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 41.3%id, 0.0%wa, 0.0%hi, 58.7%si, 0.0%st Cpu1 : 0.0%us, 0.0%sy, 0.0%ni, 29.8%id, 0.0%wa, 0.0%hi, 70.2%si, 0.0%st Cpu2 : 0.0%us, 0.0%sy, 0.0%ni, 19.2%id, 0.0%wa, 0.0%hi, 80.8%si, 0.0%st Cpu3 : 0.0%us, 0.0%sy, 0.0%ni, 19.2%id, 0.0%wa, 0.0%hi, 80.8%si, 0.0%st Mem: 2073984k total, 1166440k used, 907544k free, 233780k buffers Swap: 4128764k total, 0k used, 4128764k free, 772828k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10 root 20 0 0 0 0 S 13.4 0.0 384:24.37 ksoftirqd/2 13 root 20 0 0 0 0 S 11.5 0.0 319:40.40 ksoftirqd/3 7 root 20 0 0 0 0 R 6.7 0.0 207:21.27 ksoftirqd/1 3 root 20 0 0 0 0 S 3.8 0.0 143:02.79 ksoftirqd/0 #tc class show dev eth2 | wc -l 6142 #tc class show dev eth3 | wc -l 6142 #iptables -nvL |grep NETFLOW 4455M 2461G NETFLOW all -- * * 0.0.0.0/0 0.0.0.0/0 NETFLOW совсем забыл mpstat -P ALL Linux 2.6.35.9 (shaper) 14.02.2011 20:00:58 CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s 20:00:58 all 0,10 0,00 0,21 0,08 0,00 50,23 0,00 49,37 36982,16 20:00:58 0 0,12 0,00 0,18 0,12 0,00 41,81 0,00 57,77 0,41 20:00:58 1 0,11 0,00 0,23 0,11 0,00 44,22 0,00 55,33 0,49 20:00:58 2 0,08 0,00 0,23 0,06 0,00 57,34 0,00 42,29 3327,65 20:00:58 3 0,10 0,00 0,22 0,05 0,00 57,54 0,00 42,09 3065,39 Изменено 14 февраля, 2011 пользователем silitra Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
silitra Опубликовано 14 февраля, 2011 · Жалоба и еще момент на интегрированной сетевухе после установки нового ядра появились очереди только они какие то не такие ), но их тоже можно раскидать по ядрам с помощью RPS # ls /sys/class/net/eth0/queues/rx- rx-0/ rx-1/ rx-2/ rx-3/ rx-4/ # ls /sys/class/net/eth1/queues/rx- rx-0/ rx-1/ rx-2/ rx-3/ rx-4/ #lspci -v 02:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 10) Subsystem: Compaq Computer Corporation NC7782 Gigabit Server Adapter (PCI-X, 10,100,1000-T) Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 25 Memory at fde70000 (64-bit, non-prefetchable) [size=64K] Expansion ROM at <ignored> [disabled] Capabilities: [40] PCI-X non-bridge device Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable- 02:02.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 10) Subsystem: Compaq Computer Corporation NC7782 Gigabit Server Adapter (PCI-X, 10,100,1000-T) Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 26 Memory at fde60000 (64-bit, non-prefetchable) [size=64K] Expansion ROM at <ignored> [disabled] Capabilities: [40] PCI-X non-bridge device Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable- Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
allexch Опубликовано 17 февраля, 2011 · Жалоба to lionel у меня на железке с 10гбит сетевухой не пашет ioatdma и DCAУ меня такая же ситуация, 24 ядра загибаются при нагрузке в 3Гиг/с. Xeon 7500 от supermicro. Я свзяался с supermicro, они сказали, что поддержка i/oat на данном чипсете встроенная, и что они тетсировали это на всех Линуксах, кроме gentoo (RH,SUSE):), который использую я.dmesg выводит: ixgbe_probe: No DCA provider found. Please start ioatdma for DCA functionality. Хочу поинтересоваться, у вас продвижения в этом вопросе есть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 30 марта, 2011 · Жалоба Прошу просветить в таком вопросе. Есть софт-роутеры под Linux на различном железе, включая как 2 х 4х-головых Ксеона, так и один Коре i7 2600. Для балансировки нагрузки в случае с зионами бондинг на 82571EB c e1000e. На Коре i7 бондинг, включая RSS на 82576 под igb. В итоге - рисуются графики cacti по нагрузке по CPU, трафику на bondX и pps там же. В любой конфе вижу траф до 1.1-1.2Гигабита максимум и не выше 150-160kpps. При этом по CPU по всем ядрам еще имеется idle. А картинка трафика иногда схожа на "полочку". Какие могут быть иные ограничения в kpps? Задачи железяки: tc + hashing filters, частично на трафик nat, ipset, ipt_netflow. Тут же в конфе прочитал про perf top. ------------------------------------------------------------------------------ PerfTop: 1424 irqs/sec kernel:99.4% [100000 cycles], (all, 4 CPUs) ------------------------------------------------------------------------------ samples pcnt kernel function _______ _____ _______________ 276.00 - 9.7% : tstat_lookup 247.00 - 8.7% : nethash_ktest [ip_set_nethash] 144.00 - 5.1% : __ticket_spin_lock 128.00 - 4.5% : u32_classify [cls_u32] 103.00 - 3.6% : igb_poll [igb] 86.00 - 3.0% : ipt_do_table [ip_tables] 62.00 - 2.2% : ip_route_input 59.00 - 2.1% : iphash_ktest [ip_set_iphash] 57.00 - 2.0% : netflow_target [ipt_NETFLOW] 56.00 - 2.0% : acpi_os_read_port 48.00 - 1.7% : irq_entries_start 48.00 - 1.7% : tc_classify_compat 34.00 - 1.2% : igb_xmit_frame_ring [igb] 32.00 - 1.1% : _read_lock_bh 30.00 - 1.1% : nf_iterate В любое время суток независимо от нагрузки: kernel:99.4% [100000 cycles] >=98%. Что показывает этот параметр? Гугл не отвечает на мой вопрос. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 31 марта, 2011 · Жалоба А покажите "vmstat 1" и как трафик по интерфейсам расходится? То есть работает ли боддинг? И давайте выберем какую-то одну машину для выяснения, например те же Ксеоны. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zevgen Опубликовано 22 августа, 2011 (изменено) · Жалоба Вообщем ситуация - есть следующий зоопарк из трех машин на которых проводятся эксперементы: 1-я. Linux KGW 2.6.32-lts #1 SMP Wed Jul 13 16:23:37 UTC 2011 x86_64 Intel(R) Core(TM)2 Quad CPU Q8300 @ 2.50GHz GenuineIntel GNU/Linux Мать вроде как ASUS P5Q-VM 01:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 01:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) ethtool -i eth0 driver: e1000e version: 1.0.2-k2 firmware-version: 5.11-2 bus-info: 0000:01:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes 2-я Linux area51 2.6.36.4-ARCH #1 SMP PREEMPT Tue Aug 9 17:33:33 MSK 2011 x86_64 Intel(R) Xeon(R) CPU E5520 @ 2.27GHz GenuineIntel GNU/Linux + эксперименты проводились и на 2.6.36, 2.6.39, 3.0.1 с драйверами с e1000.sf версии 1.4.4 и выше 00:19.0 Ethernet controller: Intel Corporation 82567LM-2 Gigabit Network Connection 01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection ethtool -i eth0 driver: e1000e version: 1.4.4-NAPI firmware-version: 1.8-4 bus-info: 0000:00:19.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes 3-я Linux VPN-2 2.6.32-lts #1 SMP Wed Aug 17 08:41:52 CEST 2011 x86_64 Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz GenuineIntel GNU/Linux 03:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06) + эксперименты проводились и на 2.6.36, 2.6.39, 3.0.1 с драйверами с e1000.sf версии 1.4.4 и выше ethtool -i eth0 driver: e1000e version: 1.4.4-NAPI firmware-version: 1.8-4 bus-info: 0000:00:19.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes На всех машинах установлены не интегрирование интеловские сетевухи. Задача 1-я машина, самая древняя, из коробочки, спокойно переваривает 800 мбит трафика в обе стороны с si на каждое ядро не более 10-12%, дропов пакетов нет, все работет отлично. Прерывания размазаны по всем 4-м ядра 2 и 3 машины ни при каких условиях, ни на каких ядрах, ни с какими драйверами не распределяют прерывания. Карточка садится на одно ядро и все. Руками через rps_cpus можно задать ядра 1,2 3,4 и т.п но маску f оно игнорирует. smp_affinity также игнорирует. Подскажите люди добрые как добиться распределения прерываний на все ядра. Изменено 22 августа, 2011 пользователем zevgen Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
c0rec0re Опубликовано 25 августа, 2011 · Жалоба Подскажите, что можно (и можно ли вообще) сделать для увеличения пропускной способности на софтроутере с шифрованием. Имею стенд из 4х блейдов hp bl 460 g7: 2 x Intel® Xeon® X5650 (6 ядер, 2.66 ГГц, 12 МБ L3, 95 Вт) 6GB RAM Integrated NC553i Dual Port FlexFabric 10Gb Adapter supporting autosensing 10Gb/1Gb Ethernet Linux u1 2.6.32-33-server #72-Ubuntu SMP Fri Jul 29 21:21:55 UTC 2011 x86_64 GNU/Linux Ubuntu 10.04.3 LTS Сервера подключены цепочкой. клиент-сервер-сервер-клиент Смысл в чём - сервер-сервер - это шифрующие устройства, ipsec-tools, клиенты - на одном iperf -s запущен, на втором ./iperf3 -c 3.3.3.2 -l 1024 -w 2M -t 3600 -i 60 -P 128 -M 100 То есть, тестирую возможности шифрования и пропускную способность. При использовании пакетов 1400 байт одним потоком всё отлично на серверах, 1 ядро грузится на 1-2% и выдаёт честный гигабит (на 10гбит нет возможности пока погонять), но когда включаю 120 потоков по 100 байт, тут трафик падает до 90-120мбит/с и вырастает ksoftirqd до 50%. 31 root 20 0 0 0 0 R 46 0.0 4:01.79 ksoftirqd/9 irqbalance убил, прерывания сетевой карты раскидал на разные ядра. У сетевой 2 прерывания - rx и tx. По чипу сетевой спецификация: http://www.emulex.com/products/oneconnect-ucnas/10gbe-fcoe-cnas/hp-certified/nc553i-dual-port-integrated-flexfabric-adapter/specifications.html iperf уходит в 100% нагрузки на клиенте и показывает только около 100мбит. sar вот, что показывает. root@s1:~# sar -n DEV 1 Linux 2.6.32-33-server (s1) 08/25/2011 _x86_64_ (12 CPU) 04:23:55 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s 04:23:56 PM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 04:23:56 PM eth0 163346.00 37427.00 24565.12 2424.71 0.00 0.00 0.00 04:23:56 PM eth1 57288.00 265224.00 6847.39 52319.42 0.00 0.00 0.00 Шифрование на обоих серверах AES-128. правила простые ipsec-tools.conf: spdadd 1.1.1.0/24 3.3.3.0/24 any -P out ipsec esp/tunnel/2.2.2.1-2.2.2.2/require; spdadd 3.3.3.0/24 1.1.1.0/24 any -P in ipsec esp/tunnel/2.2.2.2-2.2.2.1/require; racoon.conf: listen { isakmp 2.2.2.1 [500]; } remote 2.2.2.2 { exchange_mode main; lifetime time 1 hour; proposal { encryption_algorithm rijndael 128; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2; } } sainfo subnet 1.1.1.0/24 any subnet 3.3.3.0/24 any { pfs_group 2; encryption_algorithm rijndael 128; authentication_algorithm non_auth; compression_algorithm deflate; lifetime time 1 hour; } При отключении шифрования iperf показывает 265 Мбит стабильно, но нагружет ядро на клиенте на 100%, то есть как генератор трафика он как-то слишком жрущй CPU. 31 root 20 0 0 0 0 S 1 0.0 5:05.64 ksoftirqd/9 ksoftirqd падает до 1%. Очевидно, что шифрование сжирает всё и сервера могут много большее. Поможет ли мне то, что я куплю другие сетевые карточки, где по 8 tx/rx очереди и повешу на отдельное ядро? Но как проверить? iperf при большом кол-ве потоков уходит в 100%. Какие есть ещё утилиты? netperf однопоточный, не интересно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 25 августа, 2011 · Жалоба Подскажите, что можно (и можно ли вообще) сделать для увеличения пропускной способности на софтроутере с шифрованием. RPS из 2.6.35+ запользовать попытаться. Потому как распределение по очередям идет по хешу из IP адресов. Т.е. у вас все попадает в одну очередь. При множестве клиентов - будет полегче, шифровка будет распределяться равномерно по ядрам, дешифровка же - останется на одном из ядер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
c0rec0re Опубликовано 26 августа, 2011 (изменено) · Жалоба RPS из 2.6.35+ запользовать попытаться. Потому как распределение по очередям идет по хешу из IP адресов. Т.е. у вас все попадает в одну очередь. При множестве клиентов - будет полегче, шифровка будет распределяться равномерно по ядрам, дешифровка же - останется на одном из ядер. установил из репозитария 2.6.35 ядро, попытался привязать от двух сетевух rx'ы на разные ядра: echo 30 > /sys/class/net/eth0/queues/rx-0/rps_cpusecho C > /sys/class/net/eth1/queues/rx-0/rps_cpus Без результата, как были на старых ядрах, так и висят. root@s1:~# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 95: 277984 0 0 0 0 2997946 IR-PCI-MSI-edge eth0-tx 96: 848 0 0 0 5490607 0 IR-PCI-MSI-edge eth0-rx 97: 1168 0 0 3257342 0 0 IR-PCI-MSI-edge eth1-tx 98: 0 0 20754222 0 0 0 IR-PCI-MSI-edge eth1-rx root@s1:~# mpstat -P ALL Linux 2.6.35-30-server (s1) 08/26/2011 _x86_64_ (6 CPU) 06:07:54 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 06:07:55 PM all 0.00 0.00 0.00 0.00 0.00 6.33 0.00 0.00 93.67 06:07:55 PM 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 06:07:55 PM 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 06:07:55 PM 2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 06:07:55 PM 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 06:07:55 PM 4 0.00 0.00 0.00 0.00 0.00 40.71 0.00 0.00 59.29 06:07:55 PM 5 0.00 0.00 0.00 0.00 0.00 1.28 0.00 0.00 98.72 Не балансятся по ядрышкам почему-то. Изменено 26 августа, 2011 пользователем c0rec0re Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 26 августа, 2011 (изменено) · Жалоба Прерывания не будут перекидываться. Потому как RPS - уже поверх обработки прерываний. А вот почему не балансируется - хороший вопрос... Попробуйте более свежие дрова собрать. У меня e1000e тоже не балансились (не копал еще), в то время как sky2 и igb - RPS прекрасно работает... Изменено 26 августа, 2011 пользователем NiTr0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 28 августа, 2011 · Жалоба Если вам не нужен RPS, я бы откатился на 2.6.27 ядро. Где-то в инете пробегали графики бенчей, где на одинаковых конфигах ядер теребили апач на высокую загрузку. Так вот из всех тестов 27 ядро было с большим отрывом впереди. Ядра тогда были до 32 версии. Ну и там гарантированно SMP Affinity работает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 28 августа, 2011 (изменено) · Жалоба А кого волнует локальная производительность TCP стека при роутинге? Тут нет передачи данных из ядра в юзерленд, нет динамического выделения/высвобождения памяти и т.п. задач, жизненно важных апачу. И SMP affinity работает какбы везде - просто возможно на старых ядрах обработчик каждый тик прыгает по ядрам кузнечиком, тем самым добавляя оверхид на cache miss, а как подопрет под 100% одного ядра нагрузка - так и встанет все раком, впрочем, показывая что каждое ядро загружено всего на N %... Изменено 28 августа, 2011 пользователем NiTr0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
c0rec0re Опубликовано 29 августа, 2011 · Жалоба Прерывания не будут перекидываться. Потому как RPS - уже поверх обработки прерываний. А вот почему не балансируется - хороший вопрос... Попробуйте более свежие дрова собрать. У меня e1000e тоже не балансились (не копал еще), в то время как sky2 и igb - RPS прекрасно работает... точно, надо было в /proc/softirqs смотреть watch -n0.1 cat /proc/softirqs здесь видно, как на 4х из 6ти ядер растёт NET_RX. Но что-то не добавляет мощей такое... Может быть, процентов 5 максимум, но это не заметно, считай. Какие генераторы трафика можете посоветовать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
voron Опубликовано 29 августа, 2011 · Жалоба Какие генераторы трафика можете посоветовать? ядерный pktgen 1.4Mpps даёт на гигабите, может кто поделится опытом на 10G . Раньше не работал(kernel panic) на vlan'истых интерфейсах, сейчас - не знаю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...