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