Jump to content
Калькуляторы

[Решено] TC грузит процессор

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

 

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

Процессор 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 by asid2006

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

А почему на 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 очень старое, и слабо рассчитано на роутинг.

Share this post


Link to post
Share on other sites

А почему на 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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Отключил 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

Share this post


Link to post
Share on other sites

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

 

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

Edited by photon

Share this post


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

Пффф.

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

Share this post


Link to post
Share on other sites

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

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

 

 

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this