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