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

Повышенное потребление процессора приложениями во время высокой активности трафика

Здравствуйте.

Имею сервер на платформе 3.2.0-4-amd64 и с двумя карточками и линками, 82599 как основная и 82574 как дополнительная. Прерывания раскиданы по ядрам, RPS/RFS/XPS включен. Количество очередей у 82599 равно количеству ядер специально отведенного для этой карточки процессора, т.е. 4. TX/RX queue == txqueuelen == 4096

До отвода карточке отдельного процессора и перевешивания всех остальных процессов на другой процессор (taskset + default_smp_affinity) наблюдалась вообще ужасная картина - при трафике ~700 Kpps процессор жрали не прерывания, а именно мои процессы, которые, к сожалению, никуда деть нельзя. При прибивании карты к dedicated CPU ситуация улучшилась (например, имел процесс, который в покое потребляет 10% ЦПУ, когда я ничего не разделял при 700 Kpps он потреблял 40%, после разделения стал потреблять 20%). Собственно хотелось узнать, как можно минимизировать данный побочный эффект?

Он наблюдается как и 82599 так и с 82574, но в случае с 82574 также и появляется зажирание ЦП прерываниями (~2-3%). Стоит отметить, что в сервере процессора два, значит 82574 и приложения сидят на первом процессоре, а 82599 на втором и кроме нее там ничего нет.

Коннтрак включен, без него к сожалению никак.

options ixgbe InterruptThrottleRate=16000,16000 RSS=4,4

options nf_conntrack hashsize=1966080

net.nf_conntrack_max = 1966080

драйвера сетевых последние.

Спасибо за внимание к моему вопросу.

Share this post


Link to post
Share on other sites

Мне хотелось бы добавить еще пару строк.

Сервер используется как ддос-фильтр. (Пока не используется, планируется использоваться). Задача - поступающий трафик по линку 10 гигабит/сек очищать и очищенный слать уже дальше некстхопам по линку в 1 гигабит, чистить нужно много, ддосят часто, поэтому применяется такое решение.

В течении длительного времени курения этого и иных (в т.ч. англоязычных) форумов было выкручено все что только можно, начиная от экспериментов с CONFIG_HZ (остановился на дефолтном 250) до тюнинга дисковой подсистемы.

В данный момент сервер справляется с ддосом <1 Mpps нормально, пакеты эти плохие и дальше их пропускать не стоит.

Однако как я уже отметил была замечена проблема с повышенным потреблением ЦПУ приложениями и еще одно: на один из 4-х выделенных для сетевой карты ядер наблюдается повышенная загрузка. Виню RPS, грузит не обязательно первое ядро в списке, но на одно из 4-х приходится 40% работы, скажем, а на остальные - по 20.

 

# SMP

echo "f" > /proc/irq/default_smp_affinity

# eth1

echo "e" > /proc/irq/68/smp_affinity

echo "e" > /proc/irq/66/smp_affinity

echo "e" > /proc/irq/67/smp_affinity

# eth0

echo "10" > /proc/irq/73/smp_affinity

echo "10" > /proc/irq/69/smp_affinity

echo "20" > /proc/irq/70/smp_affinity

echo "40" > /proc/irq/71/smp_affinity

echo "80" > /proc/irq/72/smp_affinity

# RPS

# eth0

echo "20" > /sys/class/net/eth0/queues/rx-0/rps_cpus

echo "40" > /sys/class/net/eth0/queues/rx-1/rps_cpus

echo "80" > /sys/class/net/eth0/queues/rx-2/rps_cpus

echo "10" > /sys/class/net/eth0/queues/rx-3/rps_cpus

# eth1

echo "e" > /sys/class/net/eth1/queues/rx-0/rps_cpus

 

# XPS

# eth0

echo "20" > /sys/class/net/eth0/queues/tx-0/xps_cpus

echo "40" > /sys/class/net/eth0/queues/tx-1/xps_cpus

echo "80" > /sys/class/net/eth0/queues/tx-2/xps_cpus

echo "10" > /sys/class/net/eth0/queues/tx-3/xps_cpus

# eth1

echo "e" > /sys/class/net/eth1/queues/tx-0/xps_cpus

 

# RFS

# eth0

echo "8192" > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt

echo "8192" > /sys/class/net/eth0/queues/rx-1/rps_flow_cnt

echo "8192" > /sys/class/net/eth0/queues/rx-2/rps_flow_cnt

echo "8192" > /sys/class/net/eth0/queues/rx-3/rps_flow_cnt

# eth1

echo "32768" > /sys/class/net/eth1/queues/rx-0/rps_flow_cnt

 

Такое "кривое" распределение RPS (и XPS) не случайно, при указании rx-X/rps_cpus == /proc/irq/[номер IRQ, соответствующий этой очереди]/smp_affinity наблюдается бОльшая загрузка ЦП, чем так как сейчас. Намного большая.

Edited by Wheely

Share this post


Link to post
Share on other sites

Приложения локальные, или чистый роутинг? Если локальные - включайте ещё и RFS, это несколько снизит нагрузку на кэши.

Share this post


Link to post
Share on other sites

Да, непонятно что за приложения, ну и 82574 как минимум под замену, на что-нибудь поновее.

Share this post


Link to post
Share on other sites

Приложения локальные, или чистый роутинг? Если локальные - включайте ещё и RFS, это несколько снизит нагрузку на кэши.

 

Приложения - nginx, fpm, mysql.

RFS включен.

Share this post


Link to post
Share on other sites

Может быть tcp memory pressure (tcp стек выезжает к пределам использования памяти и начинает резать буфера).

У меня на 300000 коннектов и выше такое иногда вылезает.

Share this post


Link to post
Share on other sites

Возможно ли увеличение "предела памяти"? На сервере, я думаю, её хватит.

А вообще сегодня планируем обновляться до 3.14-0.bpo.1-amd64 в связи с необходимостью тестирования новой опции, не работающей под 3.2.0-4-amd64. Как все сделаем, отпишем результаты (касательно балансирования нагрузки RPS и проблем с приложениями).

Share this post


Link to post
Share on other sites

Картина прояснилась, согласно документации к драйверу ixgbe при использовании ntuple (а он у меня используется) RPS loses it's sence. Т.е не работает.

Попутно хотелось бы задать вопрос про ntuple, не работает правило:

root@server:/proc/net# ethtool -U eth0 flow-type tcp4 dst-ip myip dst-port 22616 action -1

Added rule with ID 2041

root@server:/proc/net# tcpdump -nv src myotherip

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

20:10:00.749106 IP (tos 0x0, ttl 58, id 143, offset 0, flags [+], proto TCP (6), length 1492)

myotherip.22616 > myip.22616: Flags [P.E], seq 1482184792:1482186244, ack 1482184792, win 22616, length 1452

20:10:00.749116 IP (tos 0x0, ttl 58, id 143, offset 1472, flags [none], proto TCP (6), length 29)

myotherip > myip: ip-proto-6

Как видим, несмотря на попадание под правило дропа трафика снимаемого с tcpdump, он все равно проходит. Почему так?

И правило drop в ntuple не действует на большие пакеты (>1492 bytes), только на маленькие. ЧЯНТД?

 

MTU на сервере с которого шлют пакеты 1500. На приемнике 9000.

Смена MTU и там и там не помогает, драйвер сетевой карты последний (пробовал со старыми, тоже проходит). Почему фильтр сетевой карты не действует в этом случае?

Если что, я шлю фрагментированные пакеты.

Edited by Wheely

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