[asid2006]

Здравствуйте. Некоторое время назад увеличился трафик и наш сервак перестал справляться с нагрузкой.

 

Вводные данные:

Процессор Intel® Xeon® CPU E3-1270 v3 @ 3.50GHz, 8 cores

Сетевая Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet PCIe

ОС CentOS release 6.6 (Final)

 

На серваке трудятся NAT+TC(HTB на хэш-таблицах)

 

Сейчас аплинк 650, но после 500 нагрузка на ядра начинает уходить в потолок, пропадают пинги и выше 570 скорость не поднимается, не смотря на свободный канал. Если выключить шейпинг, забиваются все 650 Мбит/с. Бывают случаи, когда одно ядро лежит в 100 процентах, а остальные почти по нулям (1-2 секунды).

 

cat /proc/interrupts

 48:     319372          1          0          2          0          0          0          0  IR-PCI-MSI-edge      em1-0
49: 2132019507         79          0          2          0          1          0          0  IR-PCI-MSI-edge      em1-1
50:          1         78 2213408710          1          0          0          0          1  IR-PCI-MSI-edge      em1-2
51:          4        188          0          9 3965478915          0          0          1  IR-PCI-MSI-edge      em1-3
52:          3         60          1          6          0          0 2164279421          0  IR-PCI-MSI-edge      em1-4
53:          0          3          0          0          0          0          0          0  IR-PCI-MSI-edge      em2-0
54:          0 4048532455          0          1          0          0          0          0  IR-PCI-MSI-edge      em2-1
55:          0          3          0 3981699196          0          0          0          1  IR-PCI-MSI-edge      em2-2
56:          2          1          0          1          0 1080872879          0          0  IR-PCI-MSI-edge      em2-3
57:          0          2          1          0          0          0          0 3898053363  IR-PCI-MSI-edge      em2-4

 

При старте выполняется следующее:

ethtool -L em1 tx 4 rx 4
ethtool -L em2 tx 4 rx 4

ethtool -G em1 rx 2047 tx 511
ethtool -G em2 rx 2047 tx 511

ethtool -K em1 gro off lro off gso off tso off
ethtool -K em2 gro off lro off gso off tso off

/usr/scripts/interrupts/smp.sh em1 0 0 2 4 6
/usr/scripts/interrupts/smp.sh em2 0 1 3 5 7

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu5/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu6/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu7/cpufreq/scaling_governor

ifconfig em1 txqueuelen 10000
ifconfig em2 txqueuelen 10000

/sbin/sysctl -w net.netfilter.nf_conntrack_max=262144
echo 32768 > /sys/module/nf_conntrack/parameters/hashsize

 

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

Edited November 2, 2016 by asid2006

[kayot]

Для начала нужно HT выключить, таки нету у E3 8 ядер.

А там уже видно будет.

[nuclearcat]

Эта машинка должна вытянуть под десятку минимум (на других сетевухах ессно).

Поядерно распределение нагрузки проверяли?

mpstat -P ALL

dmesg - есть ли что-то подозрительное

Ну и perf - профайлить, что грузит машину

 

Ну и:

echo ff >/sys/class/net/eth3/queues/rx-0/rps_cpus

echo ff >/sys/class/net/eth3/queues/rx-1/rps_cpus

echo ff >/sys/class/net/eth3/queues/rx-2/rps_cpus

echo ff >/sys/class/net/eth3/queues/rx-3/rps_cpus

 

Адаптируйте под себя название сетевух

[asid2006]

Эта машинка должна вытянуть под десятку минимум (на других сетевухах ессно).

Поядерно распределение нагрузки проверяли?

mpstat -P ALL

dmesg - есть ли что-то подозрительное

Ну и perf - профайлить, что грузит машину

 

Ну и:

echo ff >/sys/class/net/eth3/queues/rx-0/rps_cpus

echo ff >/sys/class/net/eth3/queues/rx-1/rps_cpus

echo ff >/sys/class/net/eth3/queues/rx-2/rps_cpus

echo ff >/sys/class/net/eth3/queues/rx-3/rps_cpus

 

Адаптируйте под себя название сетевух

 

[root@srv1 scripts]# mpstat -P ALL
Linux 3.10.84-1.el6.elrepo.x86_64 (srv1)        04.02.2016      _x86_64_        (8 CPU)

17:16:40     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
17:16:40     all    0,20    0,00    0,21    0,27    0,00    7,43    0,00    0,00   91,89
17:16:40       0    0,16    0,00    0,26    0,52    0,00   14,78    0,00    0,00   84,27
17:16:40       1    0,26    0,00    0,26    0,84    0,00    0,46    0,00    0,00   98,18
17:16:40       2    0,15    0,00    0,25    0,01    0,00   15,70    0,00    0,00   83,88
17:16:40       3    0,22    0,00    0,25    0,38    0,00    0,44    0,00    0,00   98,72
17:16:40       4    0,14    0,00    0,24    0,01    0,00   17,65    0,00    0,00   81,96
17:16:40       5    0,20    0,00    0,12    0,16    0,00    0,69    0,00    0,00   98,82
17:16:40       6    0,14    0,00    0,25    0,00    0,00   15,45    0,00    0,00   84,15
17:16:40       7    0,27    0,00    0,11    0,11    0,00    0,43    0,00    0,00   99,08

 

В dmesg есть такие сообщения:

net_ratelimit: 1 callbacks suppressed
UDP: short packet: From 178.35.142.27:0 0/1430 to 178.53.191.78:20480

 

perf top

 60,89%  [kernel]             [k] _raw_spin_lock
19,39%  [kernel]             [k] u32_classify
 3,73%  [kernel]             [k] tc_classify_compat
 0,91%  [kernel]             [k] rb_prev
 0,80%  [kernel]             [k] fib_table_lookup
 0,64%  [kernel]             [k] clflush_cache_range

[nuclearcat]

А почему на em1 0,2,4,6? Вы проверяли архитектуру и как идут HT ядра?

Иногда бывает 0,1,2,3 и вторая пара (HT) 4,5,6,7

 

К примеру у меня:

nat ~ # cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list

0,12

 

Это пара виртуальных ядер

 

Стоковое ядро Centos очень старое, и слабо рассчитано на роутинг.

[asid2006]

А почему на em1 0,2,4,6? Вы проверяли архитектуру и как идут HT ядра?

Иногда бывает 0,1,2,3 и вторая пара (HT) 4,5,6,7

 

К примеру у меня:

nat ~ # cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list

0,12

 

Это пара виртуальных ядер

 

Стоковое ядро Centos очень старое, и слабо рассчитано на роутинг.

 

cpu0 - 0-1

cpu1 - 0-1

cpu2 - 2-3

cpu3 - 2-3

cpu4 - 4-5

cpu5 - 4-5

cpu6 - 6-7

cpu7 - 6-7

[taf_321]

Если NAT, то у вас 100% для шейпера трафик заворачивается на ifb. Посмотрите размер очереди на этих интерфейсах, и для пробы попробуйте поставить его равным размеру очереди на физических интерфейсах.

[asid2006]

Если NAT, то у вас 100% для шейпера трафик заворачивается на ifb. Посмотрите размер очереди на этих интерфейсах, и для пробы попробуйте поставить его равным размеру очереди на физических интерфейсах.

ifb не используем. Только TC HTB с хэш-таблицами. Исходящую скорость режут коммутаторы.

 

Отключил Hyper Threading, посмотрим что будет.

Может, кому-то пригодится, на серверах Dell R220 эта штука называется Logical processors.

[yakov2000]

кидайте как tc сделан, похожая картина была, когда хеши не использовались.

[asid2006]

Отключил HT, стало 4 ядра. Нагрузка упала, всё стало работать хорошо. Прошло полторы недели, ситуация повторилась. Когда нагрузка доходит до 600 мбит, случаются ситуации, когда нагрузка на одно из ядер уходит в потолок, остальные загружены где-то в половину. Сейчас распределение нагрузки делается так:

/usr/scripts/interrupts/smp.sh em1 0 0 1 2 3
/usr/scripts/interrupts/smp.sh em2 0 0 1 2 3

 

Грузит в основном, шейпер, а он работает только на 2 сетевухе.

 

В tc следующее:

#!/bin/bash

tc qdisc del dev em2 root

tc qdisc add dev em2 root handle 1: htb default 100
tc class add dev em2 parent 1: classid 1:1 htb rate 1000mbit

tc class add dev em2 parent 1:1 classid 1:10 htb rate 1mbit ceil 200mbit

tc class add dev em2 parent 1:1 classid 1:20 htb rate 700716800
tc class add dev em2 parent 1:1 classid 1:30 htb rate 20mbit
tc class add dev em2 parent 1:1 classid 1:40 htb rate 1mbit ceil 400mbit
tc class add dev em2 parent 1:1 classid 1:50 htb rate 1mbit ceil 100mbit

tc filter add dev em2 protocol ip parent 1: u32 match ip src 95.33.251.60 flowid 1:10
tc filter add dev em2 protocol ip parent 1: u32 match ip src 81.23.6.224/27 flowid 1:40
tc filter add dev em2 protocol ip parent 1: u32 match ip src 95.163.68.48/28 flowid 1:40

tc filter add dev em2 protocol ip parent 1: u32 match ip src 10.0.0.0/16 match ip dst 95.33.251.61  flowid 1:50

tc class add dev em2 parent 1:20 classid 1:100 htb rate 500kbit ceil 200mbit quantum 2000

#Создаем корневой фильтр
tc filter add dev em2 parent 1:0 protocol ip u32

#Создаем 4 хеш таблицы для каждого октета
tc filter add dev em2 parent 1:0 handle 1: protocol ip u32 divisor 256
tc filter add dev em2 parent 1:0 handle 2: protocol ip u32 divisor 256
tc filter add dev em2 parent 1:0 handle 3: protocol ip u32 divisor 256
tc filter add dev em2 parent 1:0 handle 4: protocol ip u32 divisor 256

tc filter add dev em2 parent 1:0 handle 5: protocol ip u32 divisor 256
tc filter add dev em2 parent 1:0 handle 7: protocol ip u32 divisor 256
tc filter add dev em2 parent 1:0 handle 8: protocol ip u32 divisor 256
tc filter add dev em2 parent 1:0 handle 10: protocol ip u32 divisor 256
tc filter add dev em2 parent 1:0 handle 11: protocol ip u32 divisor 256

...

tc filter add dev em2 parent 1:0 handle 228: protocol ip u32 divisor 256
tc filter add dev em2 parent 1:0 handle 229: protocol ip u32 divisor 256

#Создаем фильтр направлящий весь трафик в хеш таблицу с ID 1
tc filter add dev em2 parent 1:0 protocol ip u32 ht 800:: match ip dst 0.0.0.0/0 hashkey mask 0xff000000 at 16 link 1:

# ======= 1-й октет =======
tc filter add dev em2 parent 1:0 protocol ip u32 ht 1:a: match ip dst 10.0.0.0/8  hashkey mask 0xff0000 at 16 link 2:
tc filter add dev em2 parent 1:0 protocol ip u32 ht 1:c0: match ip dst 192.168.7.0/24  hashkey mask 0xff0000 at 16 flowid 1:30
tc filter add dev em2 parent 1:0 protocol ip u32 ht 1:5f: match ip dst 95.33.251.0/24  hashkey mask 0xff at 16 link 8:


tc filter add dev em2 parent 1:0 protocol ip u32 ht 2:0: match ip dst 10.0.0.0/16 hashkey mask 0xff00 at 16 link 3:


tc filter add dev em2 parent 1:0 protocol ip u32 ht 3:0: match ip dst 10.0.0.0/24 hashkey mask 0xff at 16 flowid 1:10

tc filter add dev em2 parent 1:0 protocol ip u32 ht 3:a: match ip dst 10.0.10.0/24 hashkey mask 0xff at 16 link 10:
tc filter add dev em2 parent 1:0 protocol ip u32 ht 3:b: match ip dst 10.0.11.0/24 hashkey mask 0xff at 16 link 11:
tc filter add dev em2 parent 1:0 protocol ip u32 ht 3:c: match ip dst 10.0.12.0/24 hashkey mask 0xff at 16 link 12:

...

tc filter add dev em2 parent 1:0 protocol ip u32 ht 3:e4: match ip dst 10.0.228.0/24 hashkey mask 0xff at 16 link 228:
tc filter add dev em2 parent 1:0 protocol ip u32 ht 3:e5: match ip dst 10.0.229.0/24 hashkey mask 0xff at 16 link 229:

# =============== ABONENTS ===============
/usr/scripts/billing/ip/10.0.10.2.sh
/usr/scripts/billing/ip/10.0.11.43.sh

...

 

В файликах с айпишниками содержимое приблизительно такое:

tc class add dev em2 parent 1:20 classid 1:103 htb rate 256kbit ceil 3219456 quantum 1500
tc filter replace dev em2 protocol ip parent 1:0 handle 11:2b:800 u32 ht 11:2b: match ip dst 10.0.11.43/32 flowid 1:103

[NiTr0]

поставьте свежее ядро вместо окаменелого 2.6.32 из центос.

посмотрите perf top при нагрузке.

попробуйте включить gro/gso.

 

хотя похоже грабля в кривых сетевухах.

[asid2006]

поставьте свежее ядро вместо окаменелого 2.6.32 из центос.

посмотрите perf top при нагрузке.

попробуйте включить gro/gso.

 

хотя похоже грабля в кривых сетевухах.

 

У меня относительно новое:

[root@srv1 ~]# uname -r
3.10.84-1.el6.elrepo.x86_64

[nuclearcat]

Этому ядру три года

 

Тем не менее perf top все равно актуален

[kayot]

IMHO где-то кривизна в hash-фильтрах, не работают они. Лень разбираться в чужих дебрях :)

650мбит для такой машины - тьфу, загрузка должна быть околонулевая при любых условиях.

[NiTr0]

Этому ядру три года

ну с 3.10 на самом деле не так уж и печально. не, от перехода на более свежие есть прирост скорости, но не гигантский.

 

тут больше похоже либо на кривые правила шейпера/файра, либо - на кривую сетевку/кривой драйвер.

 

perf top покажет что-то умное думаю.

[photon]

Вы пытаетесь сделать хэширование по всем четырем октетам IP-адреса. Это довольно избыточно и сложно. Я делаю максимум по двум последним октетам, и на двух гигабитах все летает.

Edited February 18, 2016 by photon

[Ivan_83]

Вы пытаетесь сделать хэширование по всем четырем октетам IP-адреса. Это довольно избыточно и сложно. Я делаю максимум по двум последним октетам, и на двух гигабитах все летает.

Пффф.

Сначала сделать XOR и превратить 4 байта в два, дальше можно даже не хэшировать.

[NiTr0]

дальше можно даже не хэшировать.

лопатить перебором? 32к правил в среднем (от 1 до 64к)? мсье знает толк в извращениях...

 

 

к слову, а никто не щупал htb_hysteresis параметр? есть от него толк?

[nuclearcat]

Я не заметил разницы.

А вот на ~5 гигах HTB реально перестал работать, упиралось в дочерние классы, начинало буферизовать, и при этом даже не достигало скорости основого. Очень неприятная засада. Сервер весьма мощный, загрузка проца 2-3%.

В чем прикол - так и не понял. Последним увеличил внутренний лимит quantum до 2000000, вроде помогало, но потом придумал как снять лишний траффик, и стресс тесты прекратились.

Дело даже не в HTB похоже, HFSC была та же петрушка. Шейпил сбриджованные вланы.

[asid2006]

У меня все абоненты сидят за NAT. У них в айпишнике меняются только 2 последних откета. Есть ещё 3 диапазона: с внешними белыми айпишниками и управлением оборудования. Может быть, есть у кого-то пример рабочего хэш-фильтра? Когда собирал свой, у всех были примеры, основанные на одном и том же с небольшими изменениями. Возможно, в нём и косяк

[sirmax]

Тут есть соседняя тема про рейт-лимит, в iptables

Я сейчас смотрю туда, возможно при ваших условиях рейт-лимита будет достаточно?

[asid2006]

Другой сисадмин переписал шейпер, получил примерно тоже самое, с небольшими отличиями. Проблема осталась - при нагрузке 500 ядра процессора нагружены примерно на половину, при нагрузке 550 ядра нагружены более 80 процентов, при нагрузке 560 начинают появляться ситуации, когда вся нагрузка на несколько секунд ложится на одно ядро. Может быть, у кого-то появились идеи что это может быть?

[pppoetest]

99% не работают хэши.

[asid2006]

99% не работают хэши.

У вас не будет куска кода вашего шейпера?

Хэши были настроены после того, как на 150 мбитах при использовании линейных правил сервак (другой) стал захлёбываться в пакетах. После этого был настроен тот шейпер, который сейчас (с хэш-таблицами) и нагрузка упала многократно

[Ivan_83]

Видимо хэшей слишком много и они в кеш не влезают/периодически от туда вымываются.

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