Перейти к содержимому
Калькуляторы
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 изменю на днях.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сетевая с e1000 не может нормально раскидывать очереди по ядрам, с одним интерфейсом так и должно быть, одно ядро под планку, на втором чего-то эпизодически, а остальные свободны.

Зачем вы такую странную схему придумали, весь трафик через одну сетевку пустить? В этом случае количество трафика через интерфейс еще и удваивается, и через интерфейс бегает (вход + исход) * 2. При ваших '340 мбит в одну сторону' суммарно трафика может получиться и больше гига, тут уже самим сетевкам простым может плохеть))

Перевесьте виланы входящий на eth0, исходящий на eth1, а интерфейс используемый для сбора статистики или повесьте виланом на любой из них, или вообще схему поменяйте.

У меня e1000e.

 

Схема такая, потому как всё приходит с опытом. У меня и мысли не возникало, что трафик на виланах сможет настолько сильно деградировать производительность. Сначала поиграюсь с ITR, а на следующей неделе поставлю Intel 1000ET, уберу виланы и разведу очереди по ядрам. Посмотрим, насколько это положительно отразится. Ну, и от шифрования нужно избавляться.

 

Туда льется тот же трафик что и через сервер проходит?

Да, но не весь. Часть трафика зеркалируется с другого сервера. Именно поэтому такая схема. Я понимаю вашу идею снимать данные непосредственно с интерфейса, который участвует в маршрутизации, но не в моем случае.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня e1000e.

 

Схема такая, потому как всё приходит с опытом. У меня и мысли не возникало, что трафик на виланах сможет настолько сильно деградировать производительность. Сначала поиграюсь с ITR, а на следующей неделе поставлю Intel 1000ET, уберу виланы и разведу очереди по ядрам. Посмотрим, насколько это положительно отразится. Ну, и от шифрования нужно избавляться.

В вашем конкретном случае установка ET board решит все проблемы, и шифрование можно будет не трогать. Разделите вход/исход + для самих интерфейсов с msi-x и драйвером IGB очереди раскидаете по ядрам - для pptp нагрузка равномерно распределится на все 4 ядра(2 для одного интерфейса, 2 для другого, очереди на вход/исход лучше совмещенные).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну а кроме радикальных методов(добавление сетевок) есть все-таки более простые методы.

1) разбить трафик на 2 физических интерфейса. Vlan10 на eth0, vlan100 на eth1, mirror трафик идущий на eth1 затегировать и лить на любой из интерфейсов, от него нагрузки практически не будет. Загрузка должна поделиться на 2 ядра более-менее равномерно.

2) использовать rss/rfs ядра 2.6.35, по идее можно всю вашу нагрузку разбить на 4 ядра. Оно конечно не столь эффективно как аппаратные очереди ET board, но тоже работает. Останется только перегрузка интерфейса трафиком, но все равно будет лучше.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2Justas: Процессор разгонять, конечно, не надо на роутере. Если у вас все 4 ядра честные, тогда гут.

 

Тут, кстати правильно kayot подсказывает насчет rss/rfs - может помочь, попробуйте. Я лично, не знаю как работают софтовые очереди, так как не было необходимости. Если же у вас есть под рукой сетевая с MSI-X, то меняйте и не парьтесь. Поможет радикально. Остальные моменты упомянутые здесь при этом тоже нужно реализовать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А подскажите пожалуйста, а то перечитал и так и не понял:

 

[    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К прерываний в секунду.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это количество прерываний на очередь. Итого у вас 16 очередей, а не 8. По 8 на каждый интерфейс. Да еще и ITR стоит 2, вот только что это за режим?

Изменено пользователем Dark_Angel

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

у меня на железке с 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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это количество прерываний на очередь. Итого у вас 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 (белые адреса) - это последнее что помогло снизить загруз, сейчас начал мучать драйвера.

Изменено пользователем Cayz

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я перепутал IntMode с ITR. Однозначно должно стоять 2, если карта поддерживает. Это самый "дешевый" и производительный режим работы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тут, кстати правильно kayot подсказывает насчет rss/rfs - может помочь, попробуйте. Я лично, не знаю как работают софтовые очереди, так как не было необходимости. Если же у вас есть под рукой сетевая с MSI-X, то меняйте и не парьтесь. Поможет радикально. Остальные моменты упомянутые здесь при этом тоже нужно реализовать.

RFS/RPS посмотрел, настроил, оценил. Что-то как-то не впечатлило сильно...

 

В общем поставил 1000ET с igb драйвером, убрал вланы, разбил очереди, снизил количество клиентов с шифрованием на 20%. Сейчас всё хорошо. Спасибо всем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем silitra

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

и еще момент

на интегрированной сетевухе после установки нового ядра появились очереди только они какие то не такие ), но их тоже можно раскидать по ядрам с помощью 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-

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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.

Хочу поинтересоваться, у вас продвижения в этом вопросе есть?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Прошу просветить в таком вопросе. Есть софт-роутеры под 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%. Что показывает этот параметр? Гугл не отвечает на мой вопрос.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А покажите "vmstat 1" и как трафик по интерфейсам расходится? То есть работает ли боддинг? И давайте выберем какую-то одну машину для выяснения, например те же Ксеоны.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вообщем ситуация - есть следующий зоопарк из трех машин на которых проводятся эксперементы:

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 также игнорирует. Подскажите люди добрые как добиться распределения прерываний на все ядра.

Изменено пользователем zevgen

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Подскажите, что можно (и можно ли вообще) сделать для увеличения пропускной способности на софтроутере с шифрованием.

 

Имею стенд из 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 однопоточный, не интересно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Подскажите, что можно (и можно ли вообще) сделать для увеличения пропускной способности на софтроутере с шифрованием.

RPS из 2.6.35+ запользовать попытаться. Потому как распределение по очередям идет по хешу из IP адресов. Т.е. у вас все попадает в одну очередь.

При множестве клиентов - будет полегче, шифровка будет распределяться равномерно по ядрам, дешифровка же - останется на одном из ядер.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

RPS из 2.6.35+ запользовать попытаться. Потому как распределение по очередям идет по хешу из IP адресов. Т.е. у вас все попадает в одну очередь.

При множестве клиентов - будет полегче, шифровка будет распределяться равномерно по ядрам, дешифровка же - останется на одном из ядер.

установил из репозитария 2.6.35 ядро, попытался привязать от двух сетевух rx'ы на разные ядра:

 

echo 30 > /sys/class/net/eth0/queues/rx-0/rps_cpus

echo 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

 

Не балансятся по ядрышкам почему-то.

Изменено пользователем c0rec0re

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Прерывания не будут перекидываться. Потому как RPS - уже поверх обработки прерываний. А вот почему не балансируется - хороший вопрос... Попробуйте более свежие дрова собрать. У меня e1000e тоже не балансились (не копал еще), в то время как sky2 и igb - RPS прекрасно работает...

Изменено пользователем NiTr0

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если вам не нужен RPS, я бы откатился на 2.6.27 ядро. Где-то в инете пробегали графики бенчей, где на одинаковых конфигах ядер теребили апач на высокую загрузку. Так вот из всех тестов 27 ядро было с большим отрывом впереди. Ядра тогда были до 32 версии. Ну и там гарантированно SMP Affinity работает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А кого волнует локальная производительность TCP стека при роутинге? Тут нет передачи данных из ядра в юзерленд, нет динамического выделения/высвобождения памяти и т.п. задач, жизненно важных апачу.

И SMP affinity работает какбы везде - просто возможно на старых ядрах обработчик каждый тик прыгает по ядрам кузнечиком, тем самым добавляя оверхид на cache miss, а как подопрет под 100% одного ядра нагрузка - так и встанет все раком, впрочем, показывая что каждое ядро загружено всего на N %...

Изменено пользователем NiTr0

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Прерывания не будут перекидываться. Потому как RPS - уже поверх обработки прерываний. А вот почему не балансируется - хороший вопрос... Попробуйте более свежие дрова собрать. У меня e1000e тоже не балансились (не копал еще), в то время как sky2 и igb - RPS прекрасно работает...

 

точно, надо было в /proc/softirqs смотреть

 

watch -n0.1 cat /proc/softirqs

здесь видно, как на 4х из 6ти ядер растёт NET_RX.

 

Но что-то не добавляет мощей такое... Может быть, процентов 5 максимум, но это не заметно, считай.

 

Какие генераторы трафика можете посоветовать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Какие генераторы трафика можете посоветовать?
ядерный pktgen 1.4Mpps даёт на гигабите, может кто поделится опытом на 10G . Раньше не работал(kernel panic) на vlan'истых интерфейсах, сейчас - не знаю.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.