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