asid2006 Posted February 4, 2016 (edited) Здравствуйте. Некоторое время назад увеличился трафик и наш сервак перестал справляться с нагрузкой. Вводные данные: Процессор 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 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
kayot Posted February 4, 2016 Для начала нужно HT выключить, таки нету у E3 8 ядер. А там уже видно будет. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
nuclearcat Posted February 4, 2016 Эта машинка должна вытянуть под десятку минимум (на других сетевухах ессно). Поядерно распределение нагрузки проверяли? 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 Адаптируйте под себя название сетевух Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
asid2006 Posted February 4, 2016 Эта машинка должна вытянуть под десятку минимум (на других сетевухах ессно). Поядерно распределение нагрузки проверяли? 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 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
nuclearcat Posted February 4, 2016 А почему на 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 очень старое, и слабо рассчитано на роутинг. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
asid2006 Posted February 4, 2016 А почему на 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 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
taf_321 Posted February 4, 2016 Если NAT, то у вас 100% для шейпера трафик заворачивается на ifb. Посмотрите размер очереди на этих интерфейсах, и для пробы попробуйте поставить его равным размеру очереди на физических интерфейсах. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
asid2006 Posted February 5, 2016 Если NAT, то у вас 100% для шейпера трафик заворачивается на ifb. Посмотрите размер очереди на этих интерфейсах, и для пробы попробуйте поставить его равным размеру очереди на физических интерфейсах. ifb не используем. Только TC HTB с хэш-таблицами. Исходящую скорость режут коммутаторы. Отключил Hyper Threading, посмотрим что будет. Может, кому-то пригодится, на серверах Dell R220 эта штука называется Logical processors. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
yakov2000 Posted February 9, 2016 кидайте как tc сделан, похожая картина была, когда хеши не использовались. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
asid2006 Posted February 17, 2016 Отключил 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 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NiTr0 Posted February 17, 2016 поставьте свежее ядро вместо окаменелого 2.6.32 из центос. посмотрите perf top при нагрузке. попробуйте включить gro/gso. хотя похоже грабля в кривых сетевухах. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
asid2006 Posted February 17, 2016 поставьте свежее ядро вместо окаменелого 2.6.32 из центос. посмотрите perf top при нагрузке. попробуйте включить gro/gso. хотя похоже грабля в кривых сетевухах. У меня относительно новое: [root@srv1 ~]# uname -r 3.10.84-1.el6.elrepo.x86_64 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
nuclearcat Posted February 17, 2016 Этому ядру три года Тем не менее perf top все равно актуален Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
kayot Posted February 17, 2016 IMHO где-то кривизна в hash-фильтрах, не работают они. Лень разбираться в чужих дебрях :) 650мбит для такой машины - тьфу, загрузка должна быть околонулевая при любых условиях. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NiTr0 Posted February 17, 2016 Этому ядру три года ну с 3.10 на самом деле не так уж и печально. не, от перехода на более свежие есть прирост скорости, но не гигантский. тут больше похоже либо на кривые правила шейпера/файра, либо - на кривую сетевку/кривой драйвер. perf top покажет что-то умное думаю. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
photon Posted February 18, 2016 (edited) Вы пытаетесь сделать хэширование по всем четырем октетам IP-адреса. Это довольно избыточно и сложно. Я делаю максимум по двум последним октетам, и на двух гигабитах все летает. Edited February 18, 2016 by photon Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted February 18, 2016 Вы пытаетесь сделать хэширование по всем четырем октетам IP-адреса. Это довольно избыточно и сложно. Я делаю максимум по двум последним октетам, и на двух гигабитах все летает. Пффф. Сначала сделать XOR и превратить 4 байта в два, дальше можно даже не хэшировать. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NiTr0 Posted February 18, 2016 дальше можно даже не хэшировать. лопатить перебором? 32к правил в среднем (от 1 до 64к)? мсье знает толк в извращениях... к слову, а никто не щупал htb_hysteresis параметр? есть от него толк? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
nuclearcat Posted February 19, 2016 Я не заметил разницы. А вот на ~5 гигах HTB реально перестал работать, упиралось в дочерние классы, начинало буферизовать, и при этом даже не достигало скорости основого. Очень неприятная засада. Сервер весьма мощный, загрузка проца 2-3%. В чем прикол - так и не понял. Последним увеличил внутренний лимит quantum до 2000000, вроде помогало, но потом придумал как снять лишний траффик, и стресс тесты прекратились. Дело даже не в HTB похоже, HFSC была та же петрушка. Шейпил сбриджованные вланы. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
asid2006 Posted February 19, 2016 У меня все абоненты сидят за NAT. У них в айпишнике меняются только 2 последних откета. Есть ещё 3 диапазона: с внешними белыми айпишниками и управлением оборудования. Может быть, есть у кого-то пример рабочего хэш-фильтра? Когда собирал свой, у всех были примеры, основанные на одном и том же с небольшими изменениями. Возможно, в нём и косяк Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
sirmax Posted February 19, 2016 Тут есть соседняя тема про рейт-лимит, в iptables Я сейчас смотрю туда, возможно при ваших условиях рейт-лимита будет достаточно? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
asid2006 Posted March 29, 2016 Другой сисадмин переписал шейпер, получил примерно тоже самое, с небольшими отличиями. Проблема осталась - при нагрузке 500 ядра процессора нагружены примерно на половину, при нагрузке 550 ядра нагружены более 80 процентов, при нагрузке 560 начинают появляться ситуации, когда вся нагрузка на несколько секунд ложится на одно ядро. Может быть, у кого-то появились идеи что это может быть? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
pppoetest Posted March 29, 2016 99% не работают хэши. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
asid2006 Posted March 29, 2016 99% не работают хэши. У вас не будет куска кода вашего шейпера? Хэши были настроены после того, как на 150 мбитах при использовании линейных правил сервак (другой) стал захлёбываться в пакетах. После этого был настроен тот шейпер, который сейчас (с хэш-таблицами) и нагрузка упала многократно Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted March 29, 2016 Видимо хэшей слишком много и они в кеш не влезают/периодически от туда вымываются. Либо наоборот слишком мало, и тогда слишком часто случаются одновременные попадания двух и более ядер на одну корзину, в результате они крутятся в спинлоках. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...