[c0rec0re]

ядерный pktgen 1.4Mpps даёт на гигабите

вещь! спасибо.

клиент выкидывает 560к pps на udp 200байт, шифрующий сервер переваривает только 350к pps и 690 мбит (с оверхедом IPSEC'а получается ~870мбит).

при том шифрующий сервер становится слабоотзывчивым, но не кладётся, а честно старается перелапачивать всё это барахло.

похоже, что нужны сетевушки с большим кол-вом rx/tx очередей, нежели 1 на rx, и 1 на tx - ядро сжирает на tx ksoftirqd на 100%, раскидать бы этот tx по 4ём хотя бы ядрам...

но для блейдов то ли нет сетевух с множеством rx/tx queues, то ли я так плохо искал (имею ввиду 10G карточки).

Изменено 29 августа, 2011 пользователем c0rec0re

[c0rec0re]

05:25:38 PM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
05:25:39 PM        lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00
05:25:39 PM      eth0 103788982.00      2.00 111165.13      0.00      0.00      0.00      0.00
05:25:39 PM      eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00

 

О скока прерываний!103 миллиона, с приёмом 1.1 гигабита от клиента pktgen.

Врёт и не краснеет! :)

это уже 10.04.1 убунта с ядром 2.6.32-24-server

 

при чём на 10.04.3 с 2.6.35 ядром правильно показывается статистика по прерываниям и трафику.

Изменено 29 августа, 2011 пользователем c0rec0re

[NiTr0]

О скока прерываний!103 миллиона, с приёмом 1.1 гигабита от клиента pktgen.

Прерываний, или же пакетов? ;)

[c0rec0re]

Прерываний, или же пакетов? ;)

да, конечно, пакетов :)

интеррапты посмотрел - 10к всего.

[nicol@s]

Добрый день, коллеги!

Используем софтовый роутер на Debian с ядром 2.6.32.5, до этого использовали Centos 2.6.18. После перехода в iptables пропал модуль ipt_SAME. Нашел, что с версии ядра 2.6.25 и более ipt_SAME выпилен. Этот модуль нам нужен для того, чтобы натить абонентов маской внешних адресов так, чтобы для каждого соединения абонента выдавался один и тот же внешний адрес (аналог static-port в pf). Вот правило:

iptables -t nat -A POSTROUTING -o $ext_if -s 10.1.0.0/16 -j SAME --to x.x.46.1-x.x.46.254 --nodst

Подскажите, как можно реализовать без модуля ipt_SAME??

Исходников модуля для данной версии ядра не нашли. Заголовочный файл есть и только.

[vitalyb]

-j SNAT --persistent

[nicol@s]

Спасибо.

Был невнимателен. Нашел еще одну похожу тему на форуме.

[nicol@s]

С добрым утром, коллеги!

Есть сервер на Debian с ядром 2.6.32.

Процессор: Intel® Core™ i7 CPU X980.

Сетевая карта: INTEL 82576 с последними дровами:

ethtool -i eth1

driver: igb
version: 3.1.16
firmware-version: 1.2-1
bus-info: 0000:06:00.1

Параметры тюнинга сетевой подсистемы такие:

1. Ядро собрано с параметром HZ=1000.

2. sysctl.conf:

net.ipv4.tcp_rmem = 8192 8388608 16777216
net.ipv4.tcp_wmem = 8192 4194394 16777216
net.ipv4.tcp_no_metrics_save = 1
net.core.netdev_max_backlog = 1000
net.core.somaxconn = 262144
net.core.wmem_default = 4194394
net.core.rmem_default = 8388608
net.ipv4.netfilter.ip_conntrack_max = 524288
net.ipv4.tcp_max_tw_buckets = 1440000
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 6000

3. ethtool -g eth1/eth0

Current hardware settings:
RX:		2048
RX Mini:	0
RX Jumbo:	0
TX:		2048

ifconfig eth0/eth1 txqueuelen 10000

4. Flow control отключен

ethtool -a eth1/eth0

Pause parameters for eth1:
Autonegotiate:	off
RX:		off
TX:		off

5. Выставляю следующие значения параметров сетевухи

IntMode=2,2,2,2 InterruptThrottleRate=5000,5000,5000,5000 RSS=6,6,6,6 QueuePairs=1,1,1,1 LLIPort=80

6. Прерывания сетевухи прибил к ядрам проца как здесь

 

Тестирую роутер под нагрузкой. Схема проста:

desktop->bridge->Linux-router

Вот немного статистики:

При скачках трафика до, примерно, 800Мбит пинги с desktop также немного подскакивают:

bridge4

netstat -w1d -I igb1
    95514     0     0   84142447     101062     0   87398568     0
    97911     0     0   92661871      95795     0   77353183     0
   103622     0     0  106423360      89746     0   66755034     0
   108637     0     0  111191926      94184     0   70007292     0
   107814     0     0  109793525      94905     0   76089241     0
   101308     0     0   99683282      94081     0   76689066     0
    97984     0     0   94794879      92107     0   75325225     0
    94219     0     0   90241594      92195     0   76574761     0
    87137     0     0   75648936      92095     0   81328462     0

desktop

64 bytes from www.yandex.ru (87.250.251.3): icmp_seq=1326 ttl=58 time=4.36 ms

64 bytes from www.yandex.ru (87.250.251.3): icmp_seq=1327 ttl=58 time=3.37 ms

64 bytes from www.yandex.ru (87.250.251.3): icmp_seq=1328 ttl=58 time=7.59 ms

64 bytes from www.yandex.ru (87.250.251.3): icmp_seq=1329 ttl=58 time=13.41 ms

64 bytes from www.yandex.ru (87.250.251.3): icmp_seq=1330 ttl=58 time=8.49 ms

64 bytes from www.yandex.ru (87.250.251.3): icmp_seq=1331 ttl=58 time=3.82 ms

64 bytes from www.yandex.ru (87.250.251.3): icmp_seq=1332 ttl=58 time=3.08 ms

Запускаю параллельно пинги до того же адреса с Linux-роутера:

bridge4

netstat -w1d -I igb1
   112824     0     0  120955930      96627     0   64931740     0
   112078     0     0  119737701      94731     0   64567861     0
   97911     0     0   92661871      95795     0   77353183     0
   110266     0     0  115830616      95750     0   67505041     0
   113464     0     0  120745608      98545     0   67511505     0

С Linux-роутера

64 bytes from 77.88.21.3: icmp_req=640 ttl=60 time=15.9 ms

64 bytes from 77.88.21.3: icmp_req=641 ttl=60 time=9.90 ms

64 bytes from 77.88.21.3: icmp_req=642 ttl=60 time=4.42 ms

64 bytes from 77.88.21.3: icmp_req=643 ttl=60 time=14.8 ms

64 bytes from 77.88.21.3: icmp_req=644 ttl=60 time=12.97 ms

desktop

64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=662 ttl=58 time=14.38 ms

64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=663 ttl=58 time=21.7 ms

64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=664 ttl=58 time=5.08 ms

64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=665 ttl=58 time=13.92 ms

64 bytes from www.yandex.ru (77.88.21.3): icmp_seq=666 ttl=58 time=14.84 ms

На самом роутере:

top -SH

top - 17:40:11 up  2:49,  4 users,  load average: 0.00, 0.00, 0.00
Tasks: 124 total,   1 running, 123 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us,  0.0%sy,  0.0%ni, 85.4%id,  0.0%wa,  0.0%hi, 14.6%si,  0.0%st
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni, 86.4%id,  0.0%wa,  0.0%hi, 13.6%si,  0.0%st
Cpu2  :  0.0%us,  0.3%sy,  0.0%ni, 84.8%id,  0.0%wa,  0.0%hi, 14.9%si,  0.0%st
Cpu3  :  0.3%us,  0.0%sy,  0.0%ni, 84.5%id,  0.0%wa,  0.0%hi, 15.2%si,  0.0%st
Cpu4  :  0.0%us,  0.0%sy,  0.0%ni, 87.7%id,  0.0%wa,  0.0%hi, 12.3%si,  0.0%st
Cpu5  :  0.3%us,  0.0%sy,  0.0%ni, 84.2%id,  0.0%wa,  0.0%hi, 15.5%si,  0.0%st
Mem:   3085276k total,   694336k used,  2390940k free,    14752k buffers
Swap:  5859320k total,        0k used,  5859320k free,    57048k cached


 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                                                         
16207 root      20   0 19064 1348 1000 S    0  0.0   0:04.14 top                                                                                                                                                                             
   1 root      20   0  8352  816  676 S    0  0.0   0:03.83 init                                                                                                                                                                            
   2 root      20   0     0    0    0 S    0  0.0   0:00.00 kthreadd                                                                                                                                                                        
   3 root      RT   0     0    0    0 S    0  0.0   0:00.00 migration/0                                                                                                                                                                     
   4 root      20   0     0    0    0 S    0  0.0   0:00.89 ksoftirqd/0

vmstat

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
0  0      0 2378572  14868  57100    0    0     1     1   17   47  0  6 94  0

cat /proc/interrupts

56:          1          0          0          0          0          0   PCI-MSI-edge      eth0
57:   48422937          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-0
58:          2   48567078          0          0          0          0   PCI-MSI-edge      eth0-TxRx-1
59:          2          0   48322159          0          0          0   PCI-MSI-edge      eth0-TxRx-2
60:          2          0          0   48042159          0          0   PCI-MSI-edge      eth0-TxRx-3
61:          2          0          0          0   48397717          0   PCI-MSI-edge      eth0-TxRx-4
62:          2          0          0          0          0   48088654   PCI-MSI-edge      eth0-TxRx-5
63:          1          0          0          0          0          0   PCI-MSI-edge      eth1
64:          2          0          0          0          0   48154657   PCI-MSI-edge      eth1-TxRx-0
65:          2          0          0          0   48153187          0   PCI-MSI-edge      eth1-TxRx-1
66:          2          0          0   47886269          0          0   PCI-MSI-edge      eth1-TxRx-2
67:          2          0   47641151          0          0          0   PCI-MSI-edge      eth1-TxRx-3
68:          2   48196221          0          0          0          0   PCI-MSI-edge      eth1-TxRx-4
69:   47795242          0          0          0          0          0   PCI-MSI-edge      eth1-TxRx-5

При этом потерь пакетов нет, что уже радует.

Подскажите, может что-то можно еще подтюнить или изменить какой-то из указанных мною параметров?? В пиковые значения трафика загрузка процессора не превышала и 20%. Хотелось бы хотя бы примерно знать насколько мы можем закладываться в роутер, сколько трафика сможем прокачать.

Спасибо.

[a_andry]

LLIPort=80 уберите. Толку особо нет, но по прерываниям может просесть есть флуд какой пойдет.

[nicol@s]

Спасибо, убрал.

Но мне кажется, что задержки все равно останутся. Может что еще "подкрутить"?

[Justas]

Такой вопрос всплыл.

 

Старенький сервер на однопроцессорной маме Intel, Linux, одноядерный Pentium 4 3 ГГц L1-16K L2-2MB. Две встроенные PCI-сетевые 82541PI. В качестве софтроутера прослужил верой и правдой 5 лет, трафик вырос до значений, когда 90% загрузки процессора - норма.

 

На замену решил попробовать не менее старенькую машину на двухпроцессорной маме Intel, Linux, два одноядерных XEON 3 ГГц L1-16K L2-2MB. Две PCI-сетевые 82571EB.

 

Сетевые карты разные векторы по прерываниям не умеют, поэтому я прибил их к физическим ядрам каждого из процессоров: eth0 на CPU0, eth1 на CPU1.

 

 66:      74934          5          0          0   PCI-MSI-edge      eth0
 67:          1          1      78265          0   PCI-MSI-edge      eth1  

 

(на 4 видимых ядра не обращайте внимание, это гипетрединг, вопрос не в нем).

 

Вообще, я надеялся на чудо что двухпроцессорная машина покажет производительность в 2 раза выше, чем старая однопроцессорная. Но чуда, понятно, не произошло. Так как процессоры постоянно перебрасывают друг другу tx/rx-пакеты на обработку, то я увидел картину: оба процессора на тех же объемах маршрутизации пакетов имеют такую же утилизацию, что и однопроцессорная машина. То есть, замена одного одноядерного процессора на два одноядерных не решает вопрос производительности вообще.

 

Я понимаю, что вопрос можно решить через использование Intel 82576 и разделение векторов. Но мне интересно, как можно эффективно использовать имеющееся железо путем программной настройки. Например, если я 82571EB объединю bonding'ом, а bond разобью на виланы, как будут обрабатываться процессорами пакеты, проходящие через подобные "виртуальные" интерфейсы? Будут ли каждый из процессоров обрабатывать rx/tx-пакеты в случайном порядке по формуле round-robin и нагрузка на процессоры снизится? Есть ли у кого опыт или хотя бы теоретические размышления?

Изменено 4 октября, 2011 пользователем Justas

[NiTr0]

RPS попробуйте запользовать.

Вообще - нагрузка идет в основном от RX прерываний, tx - практически нагрузки не несут. И никто никому ничего не перекидывает, ядро, получив пакет, переваривает его и передает в сетевуху. Максимум что может с этим пакетом сделать 2-я голова - освободить занимаемую память.

Посмотрите профайлером, что ресурсы у вас собссно кушает.

[Dark_Angel]

2 Justas: Еще я рекомендую отключить HT. Практически доказано, что это вымывает кеш. Да, я вижу, что вы прибили сетевые раз через раз, и они должны быть на разных процессорах, но чтобы исключить вероятность вымывания кеша, отключите их. Всеравно пользоваться виртуальными ядрами на роутере вы не сможете.

 

Кроме того вы не указали значение pps которое у вас сейчас загружает новую машину.

 

2nicol@s: Я понимаю, что задаю вопрос немного поздновато, но удалось ли решить описанные проблемы?

[Justas]

На старой однопроцессорной машине 120kpps = 90% cpu load.

 

На текущей двухпроцессорной машине 120kpps = 90% каждого cpu load.

 

Сейчас не час пик, но perf top говорит

 

-----------------------------------------------------------------------------------------
  PerfTop:     389 irqs/sec  kernel:99.0%  exact:  0.0% [1000Hz cycles],  (all, 4 CPUs)
-----------------------------------------------------------------------------------------

            samples  pcnt function              DSO
            _______ _____ _____________________ _________

             328.00  3.3% do_raw_spin_lock      [kernel]
             284.00  2.8% htb_dequeue           [sch_htb]
             268.00  2.7% e1000_irq_enable      [e1000e]
             266.00  2.6% u32_classify          [cls_u32]
             221.00  2.2% e1000_clean_rx_irq    [e1000e]
             212.00  2.1% ipt_do_table          [kernel]
             208.00  2.1% e1000_intr_msi        [e1000e]
             190.00  1.9% __netif_receive_skb   [kernel]
             183.00  1.8% e1000_xmit_frame      [e1000e]                                 

 

На htb_dequeue и u32_classify не смотрите, я знаю что они забирают около 7-10% процессоров. ipt_do_table берет еще процента 2-3. То есть отключение шейпинга и iptables разгружает процессоры на 10-13%, что понятно и это не тот результат, который хочется увидеть.

 

Полагаю, do_raw_spin_lock - это локи процессоров и в них загвоздка?

[NiTr0]

Соберите 2.6.35.14 ядро туда, без big kernel lock, посмотрите на результат.

[Justas]

Да,

 

[root@ ~]# uname -r
2.6.35.14-98.fc14.i686 

 

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

[Justas]

Еще интересно. Вот есть cpu0 cpu1 cpu2 cpu3. Если я прерывания одной сетевой карты вешаю на cpu2, а второй - на cpu3, то общая средняя нагрузка на процессоры возрастает всего на 5%.

 

То есть, было

cpu0 cpu1 cpu2 cpu3
50%  1%   50%  1%

 

а становится

cpu0 cpu1 cpu2 cpu3
1%   1%   56%  53%

 

Ситуация явно связана с обработкой пакетов от разных сетевых карт разными процессорами, потому как один процессор даже с гипетредингом прекрасно справляется с обработкой трафика от двух сетевых карт.

Изменено 5 октября, 2011 пользователем Justas

[Dark_Angel]

120K - это очевидно мало для такой машины.

[Justas]

Судя по http://kerneltrap.org/mailarchive/linux-netdev/2009/5/6/5646174/thread , проблема действительно связана с локами.

 

Also when a cpu receives a frame on ethX, it has to forward it on ethY, and

another lock guards access to TX queue of ethY device. If another cpus receives

a frame on ethZ and want to forward it to ethY device, this other cpu will

need same locks and everything slowdown.

 

Процессоры взаимно тормозят друг друга локами сетевых карт. Осталось определить, как обойти это...

Изменено 5 октября, 2011 пользователем Justas

[NiTr0]

Ядро у вас с отключеным big kernel lock, или он таки включен?

[Justas]

Ядро у вас с отключеным big kernel lock, или он таки включен?

 

Отключено:

 

CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set  

[Justas]

Идея решения проблемы следующая.

 

1. Объединяем eth0 и eth1 в bond0.

2. Разбиваем bond0 на vlan1 и vlan2.

3. Трафик начинает приходить и уходить через те же сетевые интерфейсы, через которые пришел/ушел.

 

То есть нужно добиться, чтобы входящий пакет всегда уходил через тот же физический интерфейс, через который пришел. Как это можно сделать? Как сказать системе, что пришедший через bond0 на eth0 в vlan1 пакет должен уйти через bond0/eth0, но в vlan2 ?

[NiTr0]

Ядро у вас с отключеным big kernel lock, или он таки включен?

 

Отключено:

 

CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set  

CONFIG_BKL - отключено или нет?

[Justas]

Такого параметра в конфиге нет вовсе. Судя по описаниям в комьюнити redhat.com, big kernel lock включается/выключается с помощью параметра CONFIG_PREEMPT_NONE. В конфиге ядра вижу только:

 

[root@ ~]# cat config* | grep PREE
# CONFIG_TREE_PREEMPT_RCU is not set
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set       

 

По "cat config* | grep BKL" совпадений нет. Такого параметра нет.

Изменено 6 октября, 2011 пользователем Justas

[NiTr0]

Хм, ошибся с версиями. Его убрали в 2.6.37, а не в 2.6.35...