NiTr0 Posted February 26, 2019 · Report post В 24.02.2019 в 09:54, jffulcrum сказал: ОК, идем на материалы SIGCOMM 2018 paper "Understanding PCIe Performance for End Host Networking", на основе которой калькулятор писали. вы хоть поняли-то что на графике, который вы привели? намекаю: transfer size - это не max payload size. более того - немного подумав над графиком, можно даже понять сколько max payload size там взят :) Share this post Link to post Share on other sites
jffulcrum Posted February 26, 2019 · Report post 3 часа назад, NiTr0 сказал: немного подумав над графиком, можно даже понять сколько max payload size там взят Думать не обязательно, в полном материале указано, что это для MPS 256. Share this post Link to post Share on other sites
alex39x Posted March 6, 2019 (edited) · Report post Всем привет. Есть вопрос: Имеем железку-маршрутизатор (ж-м) которая на данный момент по 1Г линку гонит трафик пользователей на сервер NAS ( linux 4.9: NAT ip_ratelimit ipt_NETFLOW ). Подбираемся к 1Гбит на этой схеме. Думаем использовать 2й 1Г линк на ж-м + ECMP. У ж-м бондинга нету. Только ECMP с контролем соединений на основе "source IP address" . Ядро как мы поняли должно быть >= 4.4. Вопрос: корректна ли схема? насколько ECMP увеличит нагрузку на сервер NAS? какие могут быть проблемы в такой конфигурации ? Edited March 6, 2019 by alex39x Share this post Link to post Share on other sites
NiTr0 Posted March 18, 2019 · Report post В 06.03.2019 в 12:22, alex39x сказал: У ж-м бондинга нету. а что это за зверек такой, без бондинга-то?... как вариант извратиться, - не 802.3ad, а статик бондинг на лине, с RR балансировкой. аплоад с железки, соответственно, пойдет в какой-то один из линков (но это думаю не проблема - аплоада обычно намного меньше). но минус, как и в вашей схеме - при падении одного из линков случается беда... Share this post Link to post Share on other sites
zhenya` Posted March 19, 2019 · Report post Пример команды дефолтов оч похожи на экстрим, но они вроде умеют ) Share this post Link to post Share on other sites
arhead Posted October 23, 2019 · Report post Коллеги подскажите немного куда копать. Недавно подключили кроме 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 в торону абонов но думаю они не причем. Ведь в сторону центрального маршрутизватора ошибок нет. Share this post Link to post Share on other sites
rm_ Posted October 23, 2019 · Report post 4 minutes ago, arhead said: Ради эксперимента запустил пинги до login.p6.worldoftanks.net и посмотрел что из 1500 потерялось 11% mtr запустите и посмотрите начиная с какого хопа идут потери. Может это у inet2 вообще. Share this post Link to post Share on other sites
arhead Posted October 23, 2019 · Report post 6 минут назад, rm_ сказал: mtr запустите и посмотрите начиная с какого хопа идут потери. Может это у inet2 вообще. Спасибо. Сейчас попробую. Не думаю что у inet2 может быть такое. Хотя были косяки с их пирингом. Share this post Link to post Share on other sites
alex39x Posted November 13, 2019 · Report post Может кто-нибудь сталкивался с 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 Как она в деле? Share this post Link to post Share on other sites
rm_ Posted November 13, 2019 · Report post 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 Share this post Link to post Share on other sites
h3ll1 Posted November 24, 2019 (edited) · Report post Quote Ради эксперимента запустил пинги до login.p6.worldoftanks.net и посмотрел Експеримента ето есть в lg.he.net. Проблема по моем, потому что во первиьх я танкист. Во вторьих, ето как раз рутер в6> в4, которьй он как веть, хочеть, НО НЕ НАДО. Edited November 24, 2019 by h3ll1 Share this post Link to post Share on other sites
kayot Posted April 15, 2020 · Report post Коллеги, на свежих ядрах ветки 4.14 кто-то pppoe использует? Нет падений как год-два назад? На 4.9.180 все хорошо, но как-то не быстро, есть желание обновиться. Share this post Link to post Share on other sites
rm_ Posted April 15, 2020 · Report post 44 minutes ago, kayot said: на свежих ядрах ветки 4.14 Посмотрите на строчки "longterm" в списке на https://www.kernel.org/. После 4.14 вышло уже две новые лонгтерм-серии: 4.19 и 5.4. Если вы всё равно задумываете апгрейд, не лучше ли сразу на последнюю из доступных? А то выглядит как отрубание хвоста по частям. Всё равно когда-то придётся и на неё, а значит снова риск, эксперименты, тестирование, возможный откат. Сам не так давно перешёл везде с 4.14 на 5.4, значительных проблем не припомню. Впрочем у меня и не PPPoE-сервер, и масштабы наверное поскромнее провайдерских. Share this post Link to post Share on other sites
kayot Posted April 16, 2020 · Report post 8 часов назад, rm_ сказал: Посмотрите на строчки "longterm" в списке А если зайти чуть дальше, станет понятно что лонгтермы бывают разные, и 4.14 с этой точки зрения выбор оптимальный. Ну и вопрос именно про pppoe-терминатор провайдерских масштабов, дома любая версия будет работать. Про отзывы по 4.19 или 5.4 буду не менее благодарен. Share this post Link to post Share on other sites
NiTr0 Posted April 16, 2020 · Report post 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 надо будет попробовать собрать свежее ядро, да зарипортить если утечки останутся... Share this post Link to post Share on other sites
NiTr0 Posted April 17, 2020 · Report post 4.14.174 - утечка присутствует. Share this post Link to post Share on other sites
kayot Posted April 18, 2020 · Report post В 16.04.2020 в 13:19, NiTr0 сказал: (есть небольшие утечки памяти в коннтраке, почему - хз Ну для твоего мини-дистрибутива ядро это последнее на что я бы грешил. Течь может даже сам пересобранный libc и вместе с ним все остальное. А pppoe не падает? Или эта машина только под НАТ стоит? Share this post Link to post Share on other sites
NiTr0 Posted April 18, 2020 · Report post 2 часа назад, kayot сказал: Ну для твоего мини-дистрибутива ядро это последнее на что я бы грешил. Течь может даже сам пересобранный libc и вместе с ним все остальное. kmemleak показывает именно утечки памяти ядра же. 2 часа назад, kayot сказал: А pppoe не падает? нет, пппое не падало. только память течет. Share this post Link to post Share on other sites
hsvt Posted April 23, 2020 (edited) · Report post В 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... Edited April 23, 2020 by hsvt Share this post Link to post Share on other sites
kayot Posted April 23, 2020 · Report post 10 минут назад, hsvt сказал: CentOS7 3.18.65 ванильный самосбор + accel_ppp + pppoe, работает уже много лет, но иногда зараза падает и уходит в ребут Centos 6 + 4.9.180 + accel_ppp + pppoe работает больше года без единого сбоя, его и попробуйте. Перенастраивать там в принципе нечего, проверить что все поднялось и забыть. 12 минут назад, hsvt сказал: с каких ядер емнип убрали крутилки через options ixgbe Да вроде штатный драйвер всегда без крутилок был, после загрузки на новом ядре соберите ixgbe под это ядро и все. Share this post Link to post Share on other sites
Susanin Posted December 11, 2020 · Report post Добрый день. Имеем сервер 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 очередей и прибить их на оба проца. Share this post Link to post Share on other sites
Antares Posted December 11, 2020 · Report post DHCP есть??? Трафика то мало для такой нагрузки Share this post Link to post Share on other sites
Susanin Posted December 11, 2020 (edited) · Report post @Antares Нет. Да, трафика немного. Но большую часть нагрузки дает сетевая подсистема. Изначально текущие 8 очередей были прибиты на 6 ядер первого проца и 2 ядра от второго. Когда сервер поставили - нагрузка была минимальна, и оставили, как есть. Вчера перенес прерывания на 2 ядра от 1 проца и остальные - на второй проц. Сразу видно как подскочила нагрузка на последние 8 ядер в системе: Сейчас все вернул назад. Работают 8 первых ядер, причем не такая суммарная нагрузка, как если задействовать 8 последних. Подразумеваю что такое количество очередей и их распределение - неверно (NUMA) для этого железа. Но изменение этих параметров - ребут сервера. Поэтому и спрашиваю, как теоретически это сделать правильнее ? Edited December 11, 2020 by Susanin Share this post Link to post Share on other sites
taf_321 Posted December 11, 2020 · Report post Прибейте очереди всех сетевых карт к одному физическому процессору, на который разведены порты PCIe с сетевухами. Количество очередей уменьшите до количества ядер на одном камне. 39 минут назад, Susanin сказал: Но изменение этих параметров - ребут сервера. Поэтому и спрашиваю, как теоретически это сделать правильнее ? Зачем ребут? Достаточно же отправить в нужный smp_affinity маску, и всего делов Share this post Link to post Share on other sites
Susanin Posted December 11, 2020 · Report post 2 минуты назад, taf_321 сказал: Количество очередей уменьшите до количества ядер на одном камне. Это ведь не меняется без ребута. Или я не прав ? Share this post Link to post Share on other sites