[NiTr0]

В 24.02.2019 в 09:54, jffulcrum сказал:

ОК, идем на материалы SIGCOMM 2018 paper "Understanding PCIe Performance for End Host Networking", на основе которой калькулятор писали.

вы хоть поняли-то что на графике, который вы привели?

намекаю: transfer size - это не max payload size. более того - немного подумав над графиком, можно даже понять сколько max payload size там взят :)

[jffulcrum]

3 часа назад, NiTr0 сказал:

немного подумав над графиком, можно даже понять сколько max payload size там взят

Думать не обязательно, в полном материале указано, что это для MPS 256.

[alex39x]

Всем привет.

Есть  вопрос:
Имеем железку-маршрутизатор (ж-м)  которая на данный момент по 1Г линку гонит трафик пользователей на сервер NAS ( linux 4.9: NAT ip_ratelimit ipt_NETFLOW ).
Подбираемся к 1Гбит на этой схеме. Думаем использовать 2й 1Г линк на ж-м + ECMP. У ж-м бондинга нету. Только ECMP с контролем соединений на основе "source IP address" . Ядро как мы поняли должно быть >= 4.4.
Вопрос:

корректна ли схема?

насколько ECMP увеличит нагрузку на сервер NAS?
какие могут быть проблемы в такой конфигурации ?
 

 

 

Изменено 6 марта, 2019 пользователем alex39x

[NiTr0]

В 06.03.2019 в 12:22, alex39x сказал:

У ж-м бондинга нету.

а что это за зверек такой, без бондинга-то?...

 

как вариант извратиться, - не 802.3ad, а статик бондинг на лине, с RR балансировкой. аплоад с железки, соответственно, пойдет в какой-то один из линков (но это думаю не проблема - аплоада обычно намного меньше). но минус, как и в вашей схеме - при падении одного из линков случается беда...

[zhenya`]

Пример команды дефолтов оч похожи на экстрим, но они вроде умеют )

[arhead]

Коллеги подскажите немного куда копать. Недавно подключили кроме FV и пиринга w-ix еще FV от inet2. Через недельку начали звонить танкисты, капитаны дальнего плавания, авиаторы и т.п. пропадают пинги. Присылали отчеты PingPlotter, по ним видно что теряются пинги на сервере. Ради эксперимента запустил пинги до login.p6.worldoftanks.net и посмотрел что из 1500 потерялось 11% на другом тазике который стоит так на экскременты из 1500 потерялось 2 пакета. Конечно это все в ЧНН. Утром вроде потерь нет.

Имеется тазик с встроенной 4 головой сетевой на i350 и установленная тоже 4 головая на i350. Bonding по 3 порта. На тазике шейпер + NAT

Проц Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz c 8 Гб оперативы. HP и виртуализация отключена.

rc.local mtu поднят в сторону ipoe QinQ

Скрытый текст

ip link show | grep " eth[0-9]: "| grep "UP" | awk '{print $2}' | sed 's/://g' | sed 's/eth//' | while read int
do
    echo ff > /sys/class/net/eth$int/queues/rx-0/rps_cpus
    echo ff > /sys/class/net/eth$int/queues/rx-1/rps_cpus
    echo ff > /sys/class/net/eth$int/queues/rx-2/rps_cpus
    echo ff > /sys/class/net/eth$int/queues/rx-3/rps_cpus
    echo ff > /sys/class/net/eth$int/queues/rx-4/rps_cpus
    echo ff > /sys/class/net/eth$int/queues/rx-5/rps_cpus
    echo ff > /sys/class/net/eth$int/queues/rx-6/rps_cpus
    echo ff > /sys/class/net/eth$int/queues/rx-7/rps_cpus

    ifconfig eth$int txqueuelen 10000

    ethtool -G eth$int tx 4096

    ethtool -G eth$int rx 4096

    ethtool -K eth$int tso off  gso off gro off

    ethtool -A eth$int autoneg off rx off tx off

    grep eth$int- /proc/interrupts | awk '{print $1}' | sed 's/://' | (n=1; while read irq; do
        printf "%x" $n > /proc/irq/$irq/smp_affinity
        n=$(($n*2))
        if [ $n -eq 256 ]; then
            n=1
        fi
    done)

done

ip link set eth4 mtu 1504
ip link set eth5 mtu 1504
ip link set eth6 mtu 1504

 

 

sysctl.conf

Скрытый текст

net.ipv4.ip_forward=1

net.netfilter.nf_conntrack_max = 1048576

kernel.panic = 10
kernel.panic_on_oops = 1
kernel.hung_task_panic = 1
net.core.warnings = 0

net.ipv4.neigh.default.gc_thresh1 = 1024
net.ipv4.neigh.default.gc_thresh2 = 2048
net.ipv4.neigh.default.gc_thresh3 = 4096

net.netfilter.nf_conntrack_generic_timeout=120

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=180
net.netfilter.nf_conntrack_tcp_timeout_established=180

 

 

По htop загрузка процов выше 50% не бывает. Вот не могу понять где собака зарыта почему пинги теряются когда загрузка не выше 50% Трафик только к 2 ГБ подбирается. Ifconfig показывает RX errors в торону абонов но думаю они не причем. Ведь в сторону центрального маршрутизватора ошибок нет.

 

 

[rm_]

4 minutes ago, arhead said:

Ради эксперимента запустил пинги до login.p6.worldoftanks.net и посмотрел что из 1500 потерялось 11%

mtr запустите и посмотрите начиная с какого хопа идут потери. Может это у inet2 вообще.

[arhead]

6 минут назад, rm_ сказал:

mtr запустите и посмотрите начиная с какого хопа идут потери. Может это у inet2 вообще.

Спасибо. Сейчас попробую. Не думаю что у inet2 может быть такое. Хотя были косяки с их пирингом.

[alex39x]

Может кто-нибудь сталкивался с 4-х портовой i350 от SNR?

https://shop.nag.ru/catalog/31464.Komplektuyuschie-dlya-serverov-i-SHD/02273.Setevye-karty/24751.SNR-E1G44ET2

Цена в 2 раза ниже  по сравнению с   Silicom  https://shop.nag.ru/catalog/31464.Komplektuyuschie-dlya-serverov-i-SHD/02273.Setevye-karty/21363.PE2G4i35L

 

Как она в деле?

[rm_]

3 hours ago, alex39x said:

Может кто-нибудь сталкивался с 4-х портовой i350 от SNR?

Цена в 2 раза ниже  по сравнению с

Ещё в 2 раза ниже: https://www.ebay.com/itm/INTEL-i350T4V2BLK-Gigabit-Ethernet-Network-Server-Adapter-I350-T4-V2-Quad-Ports/152541619682

[h3ll1]

Quote

Ради эксперимента запустил пинги до login.p6.worldoftanks.net и посмотрел

Експеримента ето есть в lg.he.net.

Проблема по моем, потому что во первиьх я танкист. Во вторьих, ето как раз рутер в6> в4, которьй он как веть, хочеть, НО НЕ НАДО.

Изменено 24 ноября, 2019 пользователем h3ll1

[kayot]

Коллеги, на свежих ядрах ветки 4.14 кто-то pppoe использует? Нет падений как год-два назад?

На 4.9.180 все хорошо, но как-то не быстро, есть желание обновиться.

[rm_]

 

44 minutes ago, kayot said:

на свежих ядрах ветки 4.14

Посмотрите на строчки "longterm" в списке на https://www.kernel.org/. После 4.14 вышло уже две новые лонгтерм-серии: 4.19 и 5.4.

Если вы всё равно задумываете апгрейд, не лучше ли сразу на последнюю из доступных? А то выглядит как отрубание хвоста по частям.

Всё равно когда-то придётся и на неё, а значит снова риск, эксперименты, тестирование, возможный откат.

Сам не так давно перешёл везде с 4.14 на 5.4, значительных проблем не припомню. Впрочем у меня и не PPPoE-сервер, и масштабы наверное поскромнее провайдерских.

[kayot]

8 часов назад, rm_ сказал:

Посмотрите на строчки "longterm" в списке

А если зайти чуть дальше, станет понятно что лонгтермы бывают разные, и 4.14 с этой точки зрения выбор оптимальный.

Ну и вопрос именно про pppoe-терминатор провайдерских масштабов, дома любая версия будет работать.

Про отзывы по 4.19 или 5.4 буду не менее благодарен.

[NiTr0]

4.14.160 - полет относительно стабильный (есть небольшие утечки памяти в коннтраке, почему - хз). в более ранних (4.14.12х что ли, не помню) были серьезные утечки памяти, за месяц около 4 гигов утекало, сейчас - где-то менее 2.

 

сейчас подтекает так:

 

unreferenced object 0xffff88806f0dbe00 (size 256):
  comm "softirq", pid 0, jiffies 8895939313 (age 422075.624s)
  hex dump (first 32 bytes):
    01 00 00 00 00 00 00 00 02 00 00 00 00 03 00 00  ................
    c9 ff 0a 00 00 00 00 00 20 ff 6b e7 80 88 ff ff  ........ .k.....
  backtrace:
    [<ffffffff816cf9e8>] kmemleak_alloc+0x28/0x50
    [<ffffffff8119d405>] kmem_cache_alloc+0x125/0x190
    [<ffffffffa01b3183>] __nf_conntrack_alloc+0x53/0x190 [nf_conntrack]
    [<ffffffffa01b3786>] init_conntrack+0x4a6/0x500 [nf_conntrack]
    [<ffffffffa01b3bf6>] nf_conntrack_in+0x416/0x470 [nf_conntrack]
    [<ffffffffa016124c>] ipv4_conntrack_in+0x1c/0x20 [nf_conntrack_ipv4]
    [<ffffffff816338b8>] nf_hook_slow+0x48/0xd0
    [<ffffffff8163c49f>] ip_rcv+0x33f/0x380
    [<ffffffff815ede07>] __netif_receive_skb_core+0x8a7/0xc20
    [<ffffffff815f0828>] __netif_receive_skb+0x18/0x60
    [<ffffffff815f0dd1>] process_backlog+0x91/0x150
    [<ffffffff815f448b>] net_rx_action+0x2bb/0x780
    [<ffffffff81a0010c>] __do_softirq+0x10c/0x2b0
    [<ffffffff8106f754>] irq_exit+0xc4/0xd0
    [<ffffffff8180266f>] do_IRQ+0x4f/0xe0
    [<ffffffff8180094c>] ret_from_intr+0x0/0x1d
unreferenced object 0xffff8880c3c1c180 (size 128):
  comm "softirq", pid 0, jiffies 8895939313 (age 422075.624s)
  hex dump (first 32 bytes):
    82 00 63 3b ce fb 6a 8a 00 00 00 00 00 00 00 00  ..c;..j.........
    00 00 00 00 20 00 00 00 00 38 c1 c3 80 88 ff ff  .... ....8......
  backtrace:
    [<ffffffff816cf9e8>] kmemleak_alloc+0x28/0x50
    [<ffffffff8119fc5c>] __kmalloc_track_caller+0x13c/0x1b0
    [<ffffffff8116b141>] __krealloc+0x51/0x90
    [<ffffffffa01baf37>] nf_ct_ext_add+0x97/0x180 [nf_conntrack]
    [<ffffffffa01b34be>] init_conntrack+0x1de/0x500 [nf_conntrack]
    [<ffffffffa01b3bf6>] nf_conntrack_in+0x416/0x470 [nf_conntrack]
    [<ffffffffa016124c>] ipv4_conntrack_in+0x1c/0x20 [nf_conntrack_ipv4]
    [<ffffffff816338b8>] nf_hook_slow+0x48/0xd0
    [<ffffffff8163c49f>] ip_rcv+0x33f/0x380
    [<ffffffff815ede07>] __netif_receive_skb_core+0x8a7/0xc20
    [<ffffffff815f0828>] __netif_receive_skb+0x18/0x60
    [<ffffffff815f0dd1>] process_backlog+0x91/0x150
    [<ffffffff815f448b>] net_rx_action+0x2bb/0x780
    [<ffffffff81a0010c>] __do_softirq+0x10c/0x2b0
    [<ffffffff8106f754>] irq_exit+0xc4/0xd0
    [<ffffffff8180266f>] do_IRQ+0x4f/0xe0

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

[NiTr0]

4.14.174 - утечка присутствует.

[kayot]

В 16.04.2020 в 13:19, NiTr0 сказал:

(есть небольшие утечки памяти в коннтраке, почему - хз

Ну для твоего мини-дистрибутива ядро это последнее на что я бы грешил. Течь может даже сам пересобранный libc и вместе с ним все остальное.

А pppoe не падает? Или эта машина только под НАТ стоит?

[NiTr0]

2 часа назад, kayot сказал:

Ну для твоего мини-дистрибутива ядро это последнее на что я бы грешил. Течь может даже сам пересобранный libc и вместе с ним все остальное.

kmemleak показывает именно утечки памяти ядра же.

 

2 часа назад, kayot сказал:

А pppoe не падает?

нет, пппое не падало. только память течет.

[hsvt]

В 15.04.2020 в 22:43, kayot сказал:

Коллеги, на свежих ядрах ветки 4.14 кто-то pppoe использует? Нет падений как год-два назад?

На 4.9.180 все хорошо, но как-то не быстро, есть желание обновиться.

CentOS7 3.18.65 ванильный самосбор + accel_ppp + pppoe, работает уже много лет, но иногда зараза падает и уходит в ребут, выхлоп паники поймать не удалось т.к. стоит kernel.panic = 10, настроил netconsole, возможно успеет что-то отослать для дебага. 

Какое посоветуете попробовать ядро чтобы не сильно много всего перенастраивать? В том числе там с каких ядер емнип убрали крутилки через options ixgbe...

Изменено 23 апреля, 2020 пользователем hsvt

[kayot]

10 минут назад, hsvt сказал:

CentOS7 3.18.65 ванильный самосбор + accel_ppp + pppoe, работает уже много лет, но иногда зараза падает и уходит в ребут

Centos 6 + 4.9.180 + accel_ppp + pppoe работает больше года без единого сбоя, его и попробуйте.

Перенастраивать там в принципе нечего, проверить что все поднялось и забыть.

12 минут назад, hsvt сказал:

с каких ядер емнип убрали крутилки через options ixgbe

Да вроде штатный драйвер всегда без крутилок был, после загрузки на новом ядре соберите ixgbe под это ядро и все.

[Susanin]

Добрый день.

Имеем сервер HP DL160 G8 (2 * E5-2620 0 @ 2.00GHz, HT и виртуализация отключен в биосе),  82599ES SFP+, 32Gb, SSD raid 1

CentOS Linux release 7.6.1810, 3.10.0-693.el7.x86_64

В /etc/modprobe.d/ixgbe.conf прописано (конфиг был перенесен с предыдущего сервера):

options ixgbe RSS=8,8 IntMode=2,2 MQ=1,1 DCA=1,1 InterruptThrottleRate=1,1 FCoE=0,0 LRO=0,0 allow_unsupported_sfp=1,1

Сервер выполняет задачи роутинга + шейпер tc + биллинг (отключение биллинга дает снижение нагрузки 10-15%). Без ната.

За 2 года нагрузка плавно выросла с 40 до 75%. Трафик в максимуме 2,3 + 0,5 Гига.

 

lspci | grep -i network
06:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)
06:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)

cat /sys/bus/pci/devices/0000\:06\:00.0/numa_node
0
cat /sys/bus/pci/devices/0000\:06\:00.1/numa_node
0

numactl --hardware | grep cpus
node 0 cpus: 1 2 3 4 5 6
node 1 cpus: 0 7 8 9 10 11

 

Вопрос:

как идеологически правильно сделать:

1. сделать по 6 очередей на каждую сетевую и прибить их только на первый проц. Что бы второй проц вообще не задействовать.

2. переставить сетевку на второй проц и все очереди (6 штук) прибить на него. На первом проце   будет остальная полезная нагрузка.

3. Сделать по 12 очередей и прибить их на оба проца.

[Antares]

DHCP есть??? Трафика то мало для такой нагрузки

[Susanin]

@Antares Нет.

Да, трафика немного. Но большую часть нагрузки дает сетевая подсистема. Изначально текущие 8 очередей были прибиты на 6 ядер первого проца и 2 ядра от второго. Когда сервер поставили - нагрузка была минимальна, и оставили, как есть. Вчера перенес прерывания на 2 ядра от 1 проца и остальные - на второй проц.

 Сразу видно как подскочила нагрузка на последние 8 ядер в системе:

 

Сейчас все вернул назад. Работают 8 первых ядер, причем не такая суммарная нагрузка, как если задействовать 8 последних. Подразумеваю что такое количество очередей и их распределение - неверно (NUMA) для этого железа.

Но изменение этих параметров - ребут сервера. Поэтому и спрашиваю, как теоретически это сделать правильнее ?

Изменено 11 декабря, 2020 пользователем Susanin

[taf_321]

Прибейте очереди всех сетевых карт к одному физическому процессору, на который разведены порты PCIe с сетевухами. Количество очередей уменьшите до количества ядер на одном камне.

39 минут назад, Susanin сказал:

Но изменение этих параметров - ребут сервера. Поэтому и спрашиваю, как теоретически это сделать правильнее ? 

Зачем ребут? Достаточно же отправить в нужный smp_affinity маску, и всего делов
 

[Susanin]

2 минуты назад, taf_321 сказал:

Количество очередей уменьшите до количества ядер на одном камне.

Это ведь не меняется без ребута. Или я не прав ?