Wheely Posted June 6, 2014 Здравствуйте. Имею сервер на платформе 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 драйвера сетевых последние. Спасибо за внимание к моему вопросу. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Wheely Posted June 6, 2014 (edited) Мне хотелось бы добавить еще пару строк. Сервер используется как ддос-фильтр. (Пока не используется, планируется использоваться). Задача - поступающий трафик по линку 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 June 6, 2014 by Wheely Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Alex/AT Posted June 7, 2014 Приложения локальные, или чистый роутинг? Если локальные - включайте ещё и RFS, это несколько снизит нагрузку на кэши. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
BETEPAH Posted June 7, 2014 Да, непонятно что за приложения, ну и 82574 как минимум под замену, на что-нибудь поновее. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Wheely Posted June 7, 2014 Приложения локальные, или чистый роутинг? Если локальные - включайте ещё и RFS, это несколько снизит нагрузку на кэши. Приложения - nginx, fpm, mysql. RFS включен. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
nuclearcat Posted June 7, 2014 Может быть tcp memory pressure (tcp стек выезжает к пределам использования памяти и начинает резать буфера). У меня на 300000 коннектов и выше такое иногда вылезает. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Wheely Posted June 7, 2014 Возможно ли увеличение "предела памяти"? На сервере, я думаю, её хватит. А вообще сегодня планируем обновляться до 3.14-0.bpo.1-amd64 в связи с необходимостью тестирования новой опции, не работающей под 3.2.0-4-amd64. Как все сделаем, отпишем результаты (касательно балансирования нагрузки RPS и проблем с приложениями). Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Wheely Posted June 8, 2014 (edited) Картина прояснилась, согласно документации к драйверу 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 June 8, 2014 by Wheely Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...