[kayot]

1) Очереди сетевок в таком тестировании не работают ибо источник-получатель имеют по 1 mac'у.

2) Ядро для такого железа слишком древнее. Есть вероятность что что-то программно глючит.

3) Сервер похоже в глубоком энергосбережении находится, или опять же какой-то драйвер глючит.

Изменено 28 июня, 2013 пользователем kayot

[^rage^]

ядро 2.6.32 уже давно умерло и плохо пахнет. в 2.6.35 добавили rps, в 2.6.36 - xps. в 2.6.39 выкинули BLK. вообщем, берите свежий(3.9) софт и тестируйте заново.

[pavel.odintsov]

^rage^, спасибо за рекомендацю, поставили самое новое ядро до упора, те же цифры :(

[vitalyb]

В студию: dmesg после загрузки, perf top где "упирается _spin_lock в perf top", таблицу маршрутизации, arp таблицу. icmp_send выше быть не должно вообще, вы точно все правильно тестируете?

[legioner0]

Добрый день, товарищи.

Вопрос по оптимизации linux softrouter.

В наличии имеется три одинаковых машины "все в одном" (fw+tc+nat+netflow) на базе Sun Ultra 20 (Dual-Core AMD Opteron Processor 1214 @ 1Ghz, 1Gb RAM) с двумя двухголовыми сетевыми картами Intel 82576 (бралось с запасом под bond. по одному линку в каждой карте). Машины работают параллельно, позволяя балансировать нагрузку при помощи next-hop+acl на циске. Суммарно 2к клиентов.

Используется htb + ipset, ipt_netflow.

Оптимизации текущие:

• GRUB_CMDLINE_LINUX_DEFAULT="quiet hpet=force clocksource=tsc"

• ip_conntrack hashsize=387584

• net.ipv4.ip_forward=1
  net.ipv4.netfilter.ip_conntrack_max = 3097152
  net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 1200
  net.netfilter.nf_conntrack_acct=1
  

• для обоих интерфейсов:

  ethtool -G eth2 rx 4096 tx 4096
  ethtool -C eth2 rx-usecs 300
  ifconfig eth2 txqueuelen 10000
  

• прерывания прибиты:

  eth4-rx-0 - cpu0
  eth4-rx-1 - cpu0
  eth4-tx-0 - cpu1
  eth4-tx-1 - cpu1
  eth2-rx-0 - cpu1
  eth2-rx-1 - cpu0
  eth2-tx-0 - cpu0
  eth2-tx-1 - cpu0

 

Сейчас вся эта машинерия затыкается примерно на 400Мбит при 50-60kpps из-за роста soft-irq:

 

Вопросы:

0) Что еще можно подкрутить?

1) Имеет ли смысл использовать две отдельных сетевые карты? Или лучше использовать оба порта одной сетевой?

2) Насколько существенным будет прирост производительности, если разделить функции машин на fw+tc и nat+netflow (2+1 в текущей ситуации)?

3) Или уже бросить все и требовать машины с более мощными процами?

[kayot]

Сервер древний как говно мамонта, больше он ни с какими ужимками не осилит.

Требуйте покупку нормальной машины.

[NiTr0]

ip_conntrack hashsize=387584 - исходя из чего выбрано?

 

eth4-rx-0 - cpu0, eth4-rx-1 - cpu0 - с чего вы их на оно ядро повешали, смысл тогда от очередей вообще?

 

Ну и interrupt moderation попробовать заюзать, задать фиксированное кол-во прерываний в секунду, скажем, 5000.

 

Dual-Core AMD Opteron™ Processor 1214 @ 1Ghz - с какой радости камни с номиналом 2.2ГГц работают на 1 ГГц?

 

Хотя да, в целом - тазик довольно убогий получается, лучше сменить на какой-то десктопный интел. Даже целерон G1610 резвее будет.

[legioner0]

ip_conntrack hashsize=387584 - исходя из чего выбрано?

Где-то вычитал, что оно должно ровняться ip_conntrack_max/8

eth4-rx-0 - cpu0, eth4-rx-1 - cpu0 - с чего вы их на оно ядро повешали, смысл тогда от очередей вообще?

То есть лучше будет так:

eth4-rx-0 - cpu0

eth4-rx-1 - cpu1

eth4-tx-0 - cpu0

eth4-tx-1 - cpu1

eth2-rx-0 - cpu0

eth2-rx-1 - cpu1

eth2-tx-0 - cpu0

eth2-tx-1 - cpu1

?

Ну и interrupt moderation попробовать заюзать, задать фиксированное кол-во прерываний в секунду, скажем, 5000.

Спасибо, надо попробовать.

 

Dual-Core AMD Opteron™ Processor 1214 @ 1Ghz - с какой радости камни с номиналом 2.2ГГц работают на 1 ГГц?

Странно. надо проверить.

Upd: Это частота HT, а так оно 2.2ГГц.

Хотя да, в целом - тазик довольно убогий получается, лучше сменить на какой-то десктопный интел. Даже целерон G1610 резвее будет.

Эх. Денег бы найти =(

 

Что насчет разделения функций?

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

[Tamahome]

Хотел спросить, как у вас нагрузка с новыми ядрами ?

У нас на пограничных роутерах, после перехода на 3.9 нагрузка на cpu в 25% до 3% упала.

Какие сетевухи у Вас стоят?

 

Подтверждаю, причем даже на самых обычных сетевухах с одной очередью стало возможно прокачать 700-900 мегабит трафика/80-100Kpps (проц E7400)

 

 

Правда нерешённой остаётся трабла с

 INFO: rcu_preempt detected stalls on CPUs/tasks

Особо страшно оно на тех местах где сейчас не 1g или 10g, а 2g bonding из-за этого lacp роняет все нафиг.

и куда копать не знаю.

dmesg_rcu.txt

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

[NiTr0]

Где-то вычитал, что оно должно ровняться ip_conntrack_max/8

А еще оптимальная производительность достигается тогда, когда хеш-таблица полностью влазит в кеш проца...

 

То есть лучше будет так:

Угу.

 

Эх. Денег бы найти =(

$100 для вашей фирмы - непосильная сумма? Тогда - да, печально...

 

Что насчет разделения функций?

Можете попробовать. Нат - отдельно, все остальное (с отключенным коннтраком) - отдельно. Может и полегчает.

[legioner0]

Где-то вычитал, что оно должно ровняться ip_conntrack_max/8

А еще оптимальная производительность достигается тогда, когда хеш-таблица полностью влазит в кеш проца...

Так куда крутить?

Эх. Денег бы найти =(

$100 для вашей фирмы - непосильная сумма? Тогда - да, печально...

У нас ВУЗ. Не непосильно, а долго и нудно.

Что насчет разделения функций?

Можете попробовать. Нат - отдельно, все остальное (с отключенным коннтраком) - отдельно. Может и полегчает.

Спасибо, попробую как-нибудь. Пока что экспериментирую с одной сетевой картой вместо двух и прибитыми по новому прерываниями.

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

[kayot]

Пока что экспериментирую с одной сетевой картой вместо двух и прибитыми по новому прерываниями.

Нет смысла пробовать.

[NiTr0]

Так куда крутить?

Попробуйте уменьшить скажем до 32-64к записей. Сколько реально сессий у вас на нем сейчас?

[vitalyb]

tc хоть с хеш-таблицами? сколько правил iptables в среднем проходит пакет? - основная нагрузка тут, не в нате. Ну и perf top бы глянуть...

[morfair]

Господа, подскажите. Есть Intel 82576 и, допустим, 4'ядерный процессор. Сколько очередей лучше делать: RSS=2,2 (по две очереди на кажду голову, и каждую очередь на свое ядро) или RSS=4,4 (по четыре очереди на голову, и тогда по две очереди от разных голов на одно ядро)?

[morfair]

И еще, есть такой документ: http://www.intel.com/content/dam/doc/application-note/82575-82576-82598-82599-ethernet-controllers-interrupts-appl-note.pdf

 

Кто-нибудь делает это и нужно ли вообще:

 

8. Configure the kernel.

a. Start up the configuration menu:

make menuconfig

b. Make sure you are using the SLUB memory allocator (the unqueued SLAB

allocator):

General setup -> Choose SLAB allocator -> SLUB allocator (Unqueued Allocator)

c. Turn off forced pre-emption:

Processor type and features -> Preemption Model -> No Forced Preemption

(Server)

7

82575/82576/82598/82599—Assigning Inte

rrupts to Processor Cores

d. Turn on NUMA memory allocation (for multiple processors):

Processor type and features -> Numa Memory Allocation and Scheduler

Support = Y

e. Lower the interrupt frequency. 100 Hz is

a typical choice for servers, SMP and

NUMA with most processors might show reduced performance when too many

timer interrupts are occurring:

Processor type and features -> Timer Frequency -> 100 Hz

f. Make sure MSI and MSI-X are enabled:

Bus options (PCI etc.) -> Message Signaled Interrupts (MSI and MSI-X) = Y

g. Turn off Fair Queueing and QoS:

Networking support -> Networking Options -> QoS and/or Fair Queueing = N

h. Turn off kernel statistics:

Kernel hacking -> Collect kernel timers statistics = N

i. If possible:

Kernel hacking -> Collect scheduler statistics = N

[legioner0]

Пока что экспериментирую с одной сетевой картой вместо двух и прибитыми по новому прерываниями.

Нет смысла пробовать.

Так скажем результат оказался и не хуже и не лучше, но в результате освобождается одна сетевая карта, которую можно воткнуть в резервный тазик.

 

Так куда крутить?

Попробуйте уменьшить скажем до 32-64к записей. Сколько реально сессий у вас на нем сейчас?

Надо в пике смотреть. Сейчас при 150Мбит@20kpps:

# conntrack -L -n

conntrack v1.2.1 (conntrack-tools): 35036 flow entries have been shown.

...

 

tc хоть с хеш-таблицами? сколько правил iptables в среднем проходит пакет? - основная нагрузка тут, не в нате. Ну и perf top бы глянуть...

htb+ipset. В цепочке FORWARD 5 правил: 1-2 netflow, 3-4 прямой доступ к двум сетям, 5ое ACCEPT с --match-set

В цепочке PREROUTING 3 правила (1-2 REDIRECT ФЗ-139). В POSTROUTING 17 строк SNAT по сетям, номер сработавшего правила зависит от тазика.

 

perf top сейчас

14,68%  [kernel]                [k] ktime_get
11,52%  [cls_u32]               [k] u32_classify
 4,74%  [kernel]                [k] tc_classify_compat
 3,11%  [igb]                   [k] igb_poll
 2,94%  [ip_tables]             [k] ipt_do_table
 2,24%  [sch_htb]               [k] htb_dequeue
 1,98%  [kernel]                [k] ip_route_input_common
 1,81%  [kernel]                [k] do_raw_spin_lock
 1,25%  [kernel]                [k] hrtimer_interrupt
 1,15%  [kernel]                [k] __alloc_skb
 1,10%  [ipt_NETFLOW]           [k] netflow_target
 1,01%  [sch_sfq]               [k] sfq_enqueue
 0,89%  [igb]                   [k] igb_xmit_frame_ring
 0,85%  [nf_conntrack]          [k] nf_ct_tuple_equal
 0,85%  [kernel]                [k] memcmp
 0,77%  [kernel]                [k] irq_entries_start

[NiTr0]

morfair

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

 

legioner0

Смотрите правила tc фильтров.

[legioner0]

legioner0

Смотрите правила tc фильтров.

Спасибо, покручу.

Временно решили установкой 4го тазика, а там глядишь и машинку по-серьезнее купят.

[kayot]

Cервер HP DL380 G6, 2шт X5560. 4 бортовые сетевки BCM5709 включены в бондинги.

Машина IPOE BRAS, терминирует vlan-per-user. В принципе занимается тупой маршрутизацией(iptables минимальный, фильтрации нет, NATa нет, conntrack не используется).

 

В итоге при минимальном числе клиентов(500 сессий) и смешном трафике(300/200мбит) получаю высокую загрузку, с вылезанием ksoftirq.

Сейчас не час пик, специально посадил прерывания 4ех сетевок на 2 ядра для большей наглядности:

[root@ipoe1 sbin]# top

top - 11:20:05 up 28 days,  3:57,  2 users,  load average: 0.50, 0.25, 0.34
Tasks: 147 total,   1 running, 146 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us,  0.0%sy,  0.0%ni, 64.3%id,  0.0%wa,  0.0%hi, 35.7%si,  0.0%st
Cpu1  :  0.0%us,  1.0%sy,  0.0%ni, 99.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us,  0.0%sy,  0.0%ni, 26.3%id,  0.0%wa,  0.0%hi, 73.7%si,  0.0%st
Cpu3  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  :  1.0%us,  0.0%sy,  0.0%ni, 99.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  :  0.0%us,  1.0%sy,  0.0%ni, 99.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8183824k total,  5288676k used,  2895148k free,   271064k buffers
Swap:  8191992k total,        0k used,  8191992k free,  1594600k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  17 root      20   0     0    0    0 S 42.8  0.0 166:46.39 ksoftirqd/2
   3 root      20   0     0    0    0 S 14.9  0.0 143:10.10 ksoftirqd/0
11031 root      20   0 1239m  19m 1932 S  4.0  0.2   1053:37 accel-pppd
13097 named     20   0  658m 141m 3036 S  2.0  1.8 433:05.38 named
   1 root      20   0 19276 1544 1244 S  0.0  0.0   0:19.43 init

 

[root@ipoe1 sbin]# perf top

81.05%  [kernel]                        [k] __netif_receive_skb_core
 1.02%  [kernel]                        [k] _raw_spin_lock
 0.53%  [kernel]                        [k] _raw_spin_lock_irq
 0.48%  [ip_tables]                     [k] ipt_do_table

На 8ми ядрах ситуация пока не критична, 10-20% загрузка. Но ведь неправильно это, такая же загрузка у меня получается на соседних 4ех ядерных серверах на i5-2500 с трафиком в 2Гбит, огромными фаерволами/редиректами и т.п.

Куда копать? Броадкомы выкинуть?

[vitalyb]

айпишники по dhcp раздаете? покажите cat /proc/net/ptype

[kayot]

DHCP relay на машине есть.

[code][root@ipoe1 ~]# cat /proc/net/ptype

Type Device      Function
ALL           vlan_pt_recv [ipoe]
0800 bond1.2024.1151 packet_rcv
0800 bond1.2024.1150 packet_rcv
...
0800          ip_rcv
8863 bond1.2001.1108 packet_rcv
8863 bond1.2008.1163 packet_rcv
...
8863          pppoe_disc_rcv [pppoe]
8864          pppoe_rcv [pppoe]
0806 bond1.2024.1151 packet_rcv
0806 bond1.2024.1150 packet_rcv
...
0806          arp_rcv
dada          edsa_rcv
001b          dsa_rcv
88cc bond1    packet_rcv
88cc bond0    packet_rcv
88cc eth3     packet_rcv
88cc eth2     packet_rcv
88cc eth1     packet_rcv
88cc eth0     packet_rcv
001c          trailer_rcv

[root@ipoe1 ~]# cat /proc/net/ptype | wc -l
5217

Сейчас еще печальнее стало, этак мы и до 1G не дойдем.

[root@ipoe1 ~]# perf top
75.94%  [kernel]                        [k] __netif_receive_skb_core
 2.27%  [kernel]                        [k] cpu_idle_loop
 1.65%  [kernel]                        [k] _raw_spin_lock
 1.28%  [cls_u32]                       [k] u32_classify
 0.58%  [ip_tables]                     [k] ipt_do_table

top - 17:54:23 up 28 days, 10:31,  1 user,  load average: 0.09, 0.19, 0.18
Tasks: 139 total,   1 running, 138 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us,  0.0%sy,  0.0%ni, 84.5%id,  0.0%wa,  0.0%hi, 15.5%si,  0.0%st
Cpu1  :  1.2%us,  1.2%sy,  0.0%ni, 96.4%id,  0.0%wa,  0.0%hi,  1.2%si,  0.0%st
Cpu2  :  0.0%us,  0.0%sy,  0.0%ni, 39.2%id,  0.0%wa,  0.0%hi, 60.8%si,  0.0%st
Cpu3  :  0.0%us,  2.0%sy,  0.0%ni, 30.6%id,  0.0%wa,  0.0%hi, 67.3%si,  0.0%st
Cpu4  :  0.0%us,  1.7%sy,  0.0%ni, 81.0%id,  0.0%wa,  0.0%hi, 17.2%si,  0.0%st
Cpu5  :  0.0%us,  2.0%sy,  0.0%ni, 78.4%id,  0.0%wa,  0.0%hi, 19.6%si,  0.0%st
Cpu6  :  0.0%us,  2.7%sy,  0.0%ni, 90.4%id,  0.0%wa,  0.0%hi,  6.8%si,  0.0%st
Cpu7  :  0.0%us,  0.0%sy,  0.0%ni, 76.6%id,  0.0%wa,  0.0%hi, 23.4%si,  0.0%st

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  21 root      20   0     0    0    0 S 34.8  0.0  13:25.20 ksoftirqd/3
  17 root      20   0     0    0    0 S 26.9  0.0 168:33.00 ksoftirqd/2
11031 root      20   0 1239m  19m 1932 S  9.9  0.2   1077:10 accel-pppd
  37 root      20   0     0    0    0 S  8.0  0.0  11:03.40 ksoftirqd/7
13097 named     20   0  658m 142m 3036 S  7.0  1.8 444:00.52 named
  25 root      20   0     0    0    0 S  5.0  0.0  40:19.95 ksoftirqd/4
  29 root      20   0     0    0    0 S  5.0  0.0   8:14.71 ksoftirqd/5
   3 root      20   0     0    0    0 S  4.0  0.0 143:33.19 ksoftirqd/0

Изменено 10 октября, 2013 пользователем kayot

[vitalyb]

[root@ipoe1 ~]# cat /proc/net/ptype | wc -l

5217

Коллега 8) http://lkml.org/lkml/2013/6/7/260

 

Там получается линейный поиск по количеству интерфейсов с DHCP сервером. После того как полечил (самописный) DHCP сервак у меня нагрузка упала на порядок (для 2000 интерфейсов, емнип), картинка в mrtg просто эпичная...

[kayot]

vitalyb

Ясно. А как лечили, поделитесь? В моей ситуации вероятно придется лечить relay-модуль у accel-ppp.

[vitalyb]

kayot

Как и написано по ссылке - вместо сокета на каждый интерфейс, делается один сокет, который принимает весь трафик (ifindex=0, bpf фильтр для dhcp с исключением аплинка по SKF_AD_IFINDEX), а интерфейс-источник определяется из sockaddr'a в recvfrom()/sendto(). Так в приложение попадает, теоретически, больше лишнего трафика, но экономия просто несравнимая. С помощью fanout'а можно данные раскидывать по нескольким сокетам для балансировки нагрузки на несколько процессов, но тут явно не тот случай - одного мне более чем достаточно.

 

В /proc/net/ptype это выглядит одной строкой:

0800 packet_rcv+0x0/0x34e