Счетчики underruns S2995G, S2985G

[Счетчики underruns S2995G, S2985G]

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

[Счетчики underruns S2995G, S2985G]

День добрый. Хотелось бы видеть дропы на портах указанный коммутаторов, т.е. если я буду лить трафик в порт ласп или 10Г, больше гигабита, предназначенные в 1г порт этого коммутатора, из-за разности скоростей интерфейсов, обязаны быть дропы. хотелось бы видеть эти показатели. В текущих прошивках этот счетчик показывает всегда 0. Только старшая модель s300x отображает эти данные. Также очень хотелось бы видеть эти данные по SNMP. Наша компания планирует и дальше закупать данные коммутаторы, но нам необходим данный функционал для анализа проблем. Если это технически невозможно, хотелось бы видеть хотябы общий дроп на порту.

[TheRouter, NAT, DPDK, 6Mpps]

Что то далеко от темы ушли все. Я же лично думаю, что процессоры замерли в своей производительности, а сетевые потребности растут. Любая новая идея и продукт требует как минимум внимания. А дальнейшая разработка, поддержка и оплата, это уже дело автора, ну и в конце концов любой код станет опенсорсом или кто-то догадается повторить тоже самое в опен сорс, те же китайцы :)

Если я не ошибаюсь, в том же линуксе, в свежих версиях достаточно замороченный механизм добавления записей, через rhashtable, очень схожий с тем, что описал Ivan_83, там так сделано не в целях повышения производительности NAT forwarding, имхо этого все равно недостаточно для высокого CPS.

Что то они там перемудрили сильно, на тестах отказался в пользу 3 ядра, рхашинг ната при определенных условиях проц укладывал.

Все, почему то прицепились к хашам ната, он не требовательный, посмотрите перф топ. Глобальная проблема как мне кажется все-таки отправка пакетов и разброс их в qdisc в очереди, вот если этот процесс избавить от локов, тогда и роутинг и фул стейты заживут (в текущем линуксе), а да, как раз фул стейты кушают процессорное время по более поиска и всего остального, а избавится от них можно отказавшись от фулстейт и только. Возможно превратить контрак в разные инстансы на процессоры с прибиваниям к очередям и есть альтернативное решение, но опять же исходники кто видел, знает, проще написать с нуля, а если это будет работать, то pptp и другие плюшки вопрос только времени.

[Linux NAT]

поэтому мы натим на дешевых e3-1240 =)

А в качестве платформы, какое железо?

и показатели производительности в студию, все-таки 4 ядра, есть 4 ядра. Вообще надо составить табличку и в шапку прилепить. Каждый кто идет в эту тему, ищет такие данные

[TheRouter, NAT, DPDK, 6Mpps]

Но линукс легко роутит десятки гигабит без проблем. Так что 6 mpps - это мало.

роутить и натить не одно и то же. десятки гигабит и десятки mpps совсем разные вещи.

Я не часто на форуме, но только и вижу, как у всех работают наты на целеронах, но ни одного практического результата толком не видел.

 

Автор молодец! я лично тоже не нашел готового решения, а искал прилично. Уже ушел на ваш гит, пробовать тестить.

[Linux NAT]

В общем поигрался я и с очередями через исходники, и с разными ядрами и еще много чем.

Разница в использовании на одном процессоре бондинга и без него составила 100mpps, что примерно 8% от общей производительности, т.е. не загрузка процессора, а именно производительность железа и текущей конфигурации. Тест проводится с идентичными настройками, бондинг был разобран без перезагрузки. Двух процессорный результат получить не удалось, т.к. уперся в полку сетевой. Для себя сделал вывод, 100мппс погоды не играют, т.к. на графиках видно, что сервер когда достигает критического момента производительности, следующие 50-100мппс уложат его в полку, а работа на пределе, это любой флуд сделает ваш сервер трупом. Возможно мои показатели и настройки ужасные, я продолжаю экспереминтировать пока. Тесты проводились на X5660 @ 2.80GHz, память 3CH 1333, сетевая X520da2, сервисы 25правил iptables (есть ipset и xmark), ipt_netflow, весь трафик NATится в 3 подсети.

Ядро линукса: до этого было 3.10.104, последние тесты на ядре 3.18.45, интересный момент, последнее показывает загрузку на 10-15% меньше в общем, но полка наступает одновременно, т.е. ложит сервер мппс и никаких улучшений в эту сторону не сделано.

Когда наступает полка: игры с usec_rx и другими умными параметрами сильно результата не дают, т.е. тупо нехватает Mpps vs (частота*ядра).

Один проц производительнее двух, вымывание кэша в разы меньше, но частота дополнительных ядер отодвигает полку. Отсюда вывод: один проц с кучей ядер и максимальной частотой, точно лучше двух в сумме частота*ядра.

[Linux NAT]

Попробуйте проделать это на свежей ubuntu lts, поставить актуальное ядро, собрать свежий драйвер сетевых карт руками. Мне помогло в свое время

последую вашему совету, ну немножко. Начал интегрировать свои патчи в ядро 3.18. Увы не хочу переставлять и менять цент на убунту, только из-за ядра, ведь роутинг и нат затрагивают только ядро. Попробовал и 4ое ядро, но не буду разглагольстовать на предмет выбора. В общем на недельку пропал, пока все пилю, далее выложу результаты. Обязательно выложу результаты бондинга и без него, чего увы сам не нашел, да геморой, но истину узнать хочется =)

[Linux NAT]

настройки простые:

BONDING_OPTS="mode=802.3ad miimon=100 xmit_hash_policy=layer3+4"

тюнинг и прибитие попробовал, изменений ни в какую сторону не произошло.

по графикам ппс и байты разруливаются идеально. Статистику сейчас приложить не могу. Разрушил все, точнее откатывал настройки и ядра. Сейчас на ядре 2.6.32-573.26.

и вот на нем четко видно, что в бондинге не размазывается исходящий трафик по очередям, rx все ок, а отправка идет только с одной очереди каждого интерфейса, к примеру ix0 tx_queue_3_packets: 3945387.

на 3.10 ядрах драйвера менял и интела и родные центоса, не помогало. Видимо bonding зло, другие сервера без него работают прекрасно. Но все-равно пытаюсь разобраться. Т.к. разруливать bgp или еще чем то, это лишний костыль, если есть технология lacp, она обязана работать.

загрузил 3.10 ядро, подождал 10 сек и снял нагрузку

tx_queue_0_packets: 796470

tx_queue_0_bytes: 862901227

tx_queue_1_packets: 127331

tx_queue_1_bytes: 154521719

tx_queue_2_packets: 105433

tx_queue_2_bytes: 113146569

tx_queue_3_packets: 110952

tx_queue_3_bytes: 131290894

tx_queue_4_packets: 112896

tx_queue_4_bytes: 139732927

tx_queue_5_packets: 108352

tx_queue_5_bytes: 105378175

видно, что в этот момент времени отправка шла большую часть в очередь 0, tx при этом идеально. Похоже через время очередь меняется и итого показатели ровные. Похоже без изучения мат части и исходников мне не обойтись :(

[Linux NAT]

У меня подобное было когда оставлял штатный irqbalancer

убит на этапе инсталяции оси. прерывания по кол-ву из милиона в районе сотен точно сходятся по ядрам, т.е. все поровну на ядра.

дело думаю именно в бондинге и его локах, т.к. допустим до 800мппс загрузка максимум 7%, после 850 50%, т.е. слишком резкий рывок, так локи обычно чудят. Да и разбаланс по ядрам видмо tx queue делает. Беда в том, что не могу найти нормальную конфигурацию и тесты бондинга на высокой производительности. Все только пишут как научились болячки бондинга решать, а решений не видел. Может вообще тупость в какой-нить настройке о которой я и не помню(не знаю).

[Linux NAT]

День добрый. Снова вопросы. ядро 3.10.104, использую bonding X520da2. процы 2xX5660.

Два порта в бондинге, а там вланы. Распределение загрузок ядер неравномерное, т.е. то одни ядра загружены, то другие, каждые 2-5 сек меняется. При 1.7mpps то и дело одно из ядер пытается вырваться в полку. По иперфу на втором месте _raw_spin_lock 2%, выше писали что его бондинг и вызывает. 2% не много, но я понимаю, что на 12 ядрях, 2% это одно ядро в в сплошном локе. очереди 4096. Прерывания в ЧНН и понижал и повышал, через rx-usec. Толку нет. Какие то есть специфические настройки bonding чтобы было ровней все это дело? Никаких потерь и ошибок нет, но в полке конечно будут. На форуме находил кучу обсуждений bondinga, но кроме совета его не использовать решения не видел. Хотя здесь же выше писали что 20gbps выжали и работает. Как он вообще тюнится, где рыть? может есть ixgbe надо специфично настроить для бондинга. и да, очереди конечно прибиты жестко, в интеруптах по количеству прерываний на очередь все ровно, как и сама балансировка.

[ipt_NETFLOW]

вообще все параметры описаны тут: https://github.com/aabc/ipt-netflow с объяснением что на что влияет.

во первых спасибо за разъяснения.

документацию конечно читал, но или английский слаб или не понимаю просто.

только если вы используете flow sampling

к примеру, я не использую, но так и не понял надо ли использовать. Задача: трафик > 10G, подсчет байтов скачанных пока обязателен. На данную задачу необходимы оптимальные параметры. Т.е. если надо использовать для производительности, то я буду. У меня задача оптимизировать максимально, а я туповат :) чтобы понять что делает sampler. На пальцах может кто объяснить зачем он? понятия хашь и рандом я сам знаю, мне цель этого сэмплера не известна

[Linux NAT]

не обязательно линукс, можно и фряху. интересует софтнат. 110 гигабит, хм, наверно размер пакета 1 гиг и был :)

Там линукс + кастомный софт который через DPDK пакеты жуёт.

rdp.ru это пишет и барыжит.

 

В обычных ОС на каждый отдельный пакет сильно много проверок, а там сильно облегчённый даже не стёк а просто транслятор.

зашел на сайт, кроме красивых слов ничего толком не нашел, ну да ладно. Не раз думал о dpk и нетмап, но от фул стэйт никуда ведь не денешся. А доп протоколы типо гре требуют вмешательства в пакет, как и нат обязан adjust seq делать, т.е. одними заголовками не отделаться. Лень считать по производительности шины и памяти, но софтос врядли 110 выдаст, если речь x86-64, а не специфические спарк и т.д. с ценой соотетствующей.

[Kernel panic]

взлетит ли вообще система на обновлённом ядре, не завалится сразу в kernel panic?

взлетит, но если чек сум ядра и модуля не сойдутся, то модуль просто не загрузится. сойдется ли он или нет никто не знает :)

[Kernel panic]

И как я понимаю, мне необходимо в grub.conf добавить intel_iommu=off?

да правильно, но у меня было ядро другое и в трэйсе были упоминания что иому включен. я говорю я не спец в крашах. вообще у вас видно вот что napi_gro_receive.

не знаю должна ли быть она в выключенном gro, но интел в своих драйверах пишет: "Disable GRO when routing/bridging" ethtool -K ethX gro off".

как и lro, но опять же, может у вас все это настроено. я верю интел и всегда это выключаю

[Kernel panic]

вот пример моего дампа смерти.

[11078.080927] RIP: 0010:[<ffffffff81067bf6>] [<ffffffff81067bf6>] internal_ add_timer+0x46/0x150

[11078.080998] RSP: 0018:ffff88013fc43a08 EFLAGS: 00010002

[11078.081039] RAX: ffff8801399f1570 RBX: ffff8800a673d308 RCX: 0000000100a48 a5f

[11078.081092] RDX: ffffffffa042e2a0 RSI: ffff8800a673d308 RDI: ffff8801399f0 000

[11078.081145] RBP: ffff88013fc43a08 R08: ffff880139ad8128 R09: 0000000000000 000

[11078.081199] R10: 0000000000000002 R11: 0000000000000000 R12: 0000000100a50 000

[11078.081253] R13: ffff8801399f0000 R14: 0000000000000000 R15: ffff8801399f0 000

[11078.081307] FS: 0000000000000000(0000) GS:ffff88013fc40000(0000) knlGS:00 00000000000000

[11078.081368] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b

[11078.081411] CR2: ffffffffa042e2a0 CR3: 000000013818a000 CR4: 0000000000000 7e0

[11078.081465] Stack:

[11078.081482] ffff88013fc43a58 ffffffff8106a716 ffff8800a673d300 0000000000 000286

[11078.081546] ffffffff81d1c040 ffffffff81d1c040 ffff8800a673d300 ffffffff82 0f1b00

[11078.081611] 0000000000000000 0000000000000307 ffff88013fc43aa8 ffffffff81 5b6d64

[11078.081675] Call Trace:

[11078.081696] <IRQ>

[11078.081714]

[11078.081734] [<ffffffff8106a716>] mod_timer+0x106/0x200

[11078.081768] [<ffffffff815b6d64>] inet_frag_intern+0x94/0x1a0

[11078.081815] [<ffffffff815b6f7f>] inet_frag_find+0x10f/0x120

[11078.081861] [<ffffffff81573299>] ip_defrag+0xc9/0x180

[11078.081903] [<ffffffff81571520>] ? inet_add_protocol+0x50/0x50

[11078.081952] [<ffffffffa040809f>] ipv4_conntrack_defrag+0x8f/0xfc [nf_defr

RIP показывает где умерло, дальше видим, был вызов mod_timer, его вызвал inet_frag_in. выводы, функция фрагментации попыталась обратиться к таймеру, который либо умер, либо нет указателя на него. в общем здесь явно в модуле ядра смерть пришла.

как то у меня падал роутер связанный с фибом по включенному иому, но это у меня ядро 3.10 было, вылечилось грабе intel_iommu=off

[ipt_NETFLOW]

net.netflow.scan-min = 25

очень информативно...

у меня было 1, делал 10,20,30,100.

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

[Kernel panic]

Прошу помощь зала..

а разве трэйса нет краша? а то маловато инфы. Такая же система трудится без нареканий, конечно сервисы другие, но модулей ядра точно больше.

я краши долго не разгребал, делал только так, в папке с крашем makedumpfile --dump-dmesg vmcore txt

в трейсе практиески видно кто был инициатором до падения.

[ipt_NETFLOW]

Люди добрые, ветку прочитал, но подскажите как тюнить ipt_NETFLOW (без натевентс)?

В документации параметры описаны подробно как настраивать, но ничего нет о том, что они означают.

Интересуют скорости 10Г и больше. Сейчас на моем сервере это самый жрущий процесс, естественно он сидит на одном процессоре, сендер видимо.

стата:

Flows: active 249751 (peak 250864 reached 0d0h0m ago), mem 55407K, worker delay 30/1000 [30..100] (21 ms, 0 us, 359:0 0 [cpu2]).

Hash: size 2097152 (mem 16384K), metric 1.06 [1.02, 1.00, 1.00]. InHash: 61735594 pkt, 68411103 K, InPDU 427, 413759.

Rate: 2974108518 bits/sec, 317127 packets/sec; Avg 1 min: 2947243075 bps, 314958 pps; 5 min: 2379479772 bps, 255645 pps

cpu# pps; <search found new [metric], trunc frag alloc maxflows>, traffic: <pkt, bytes>, drop: <pkt, bytes>

Total 317122; 5777961 84902045 985826 [1.06], 0 0 0 0, traffic: 85887871, 95015 MB, drop: 0, 0 K

cpu0 22799; 443519 6462857 85099 [1.02], 0 0 0 0, traffic: 6547956, 7040 MB, drop: 0, 0 K

cpu1 24556; 523816 6711940 85676 [1.05], 0 0 0 0, traffic: 6797616, 7520 MB, drop: 0, 0 K

cpu2 24930; 363336 6444002 80556 [1.03], 0 0 0 0, traffic: 6524558, 6597 MB, drop: 0, 0 K

cpu3 25322; 404957 7912739 80706 [1.02], 0 0 0 0, traffic: 7993445, 9436 MB, drop: 0, 0 K

cpu4 23348; 299822 6653466 81720 [1.01], 0 0 0 0, traffic: 6735186, 7238 MB, drop: 0, 0 K

cpu5 25581; 551247 6884774 81193 [1.07], 0 0 0 0, traffic: 6965967, 7900 MB, drop: 0, 0 K

cpu6 26801; 378480 6856966 84374 [1.03], 0 0 0 0, traffic: 6941340, 7484 MB, drop: 0, 0 K

cpu7 29716; 362770 7155102 83164 [1.02], 0 0 0 0, traffic: 7238266, 7975 MB, drop: 0, 0 K

cpu8 32271; 672805 7595261 81377 [1.04], 0 0 0 0, traffic: 7676638, 8409 MB, drop: 0, 0 K

cpu9 25130; 494106 6624542 79212 [1.05], 0 0 0 0, traffic: 6703754, 7186 MB, drop: 0, 0 K

cpu10 29076; 788791 8295171 81998 [1.06], 0 0 0 0, traffic: 8377169, 9820 MB, drop: 0, 0 K

cpu11 27592; 494319 7305257 80751 [1.03], 0 0 0 0, traffic: 7386008, 8406 MB, drop: 0, 0 K

Export: Rate 155550 bytes/s; Total 24535 pkts, 34 MB, 736050 flows; Errors 0 pkts; Traffic lost 0 pkts, 0 Kbytes, 0 flows.

sock0: 10.ччччч:9993, sndbuf 212992, filled 1, peak 13825; err: sndbuf reached 0, connect 0, cberr 0, other 0

[Linux softrouter]

в стейтфул фаерах есть понятие поиск, вставка, удаление сессии. Так доссы и ложат наты, отправляя много новых конектов. На линуксе не видел чтобы это анализировали, фрибсдшники всегда эти данные прикладывают, к примеру графики строить можно отсюда cat /proc/net/stat/nf_conntrack.

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

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

Процессоры вещь вообще мутная. распайка влияет на производительность факт, но куча процессоров больше сделает чем куча в 2 раза меньше. Сколько не игрался показатели разные. Причем влияет сильно и мать. У меня 2 идентичных сервера lisg. Один лучше на 1 проце (на 2х дропает пакеты, хотя не загружен), второй на двух лучше первого, так что только тестинг.

[Linux softrouter]

кстати наличие влана на высоконагруженном интерфейсе может как то влиять на нагрузку?

влан как и бондинг влияния практически не оказывает, при перестройке сети вечно то прихожу к вланам, то ухожу, разницы ноль.

и еще, когда пишите загрузку, загрузка проца 65% понятие растяжимое, одно ядро 2%, другое 90. ну и плюс все от ппс зависит, трафик может быть ни о чем. графики выше показывают зависимость именно ппс. я бы увеличил tcp_establish время, ибо поиск в контреке это намного быстрее чем удаление, а удалив сессию открытую клиент ее переподымет заново, не знаю поможет ли, но чисто мое мнение. Графиков insert-delete никто (в отличии от бсдшников) не выкладывает, а зря.

[Linux softrouter]

2 Wiredom

net.netfilter.nf_conntrack_tcp_timeout_established = 90

жестокий вы человек :)

а вообще тоже склонен к правилам. если сделано для лучшего определения кто куда ходил. то временно нат в подсеть сделайте для оценки ситуации, а там думать.

конечно пакет цепочку проходит один раз. Но в нат модуле проверка внешних айпи по возврату тоже 500 раз делается. Может ошибаюсь, но легче попробовать чем в исходники опять лезть

[Непонятки с NAT]

Я правильно понимаю, если у вышестоящего прова сделано именно так, как Вы описали, то все любые другие "правильные" манипуляции с маршрутизацией с моей стороны не помогут?

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

но 1. ничего не надо в лупбэки прописывать. и какие то no_bind тоже в жизни не делал.

в общем даже нат сеть не назначайте пока. идите на 3120 и sh ipr, может для теста вы там эту подсеть подымали и забыли удалить. пинг с инета и дамп на сетевой. Если он действительно л3, значит собака там зарыта, прошивку в конце концов обновить ибо и покруче у длинков моделей есть баги в не стандартой маской маршрута. они видимо все на 24 тестят

[Linux NAT]

От включенного в conntrack аккаунтинга проц немного растет, замерял давно "на глаз".

ну netflow коллектор тоже проц грузит, я допустим пока с миррор порта не хочу трафик снимать. На глаз евенты загрузили проц тоже больше, чем трафик правилом, а так как каунтеры не помогли отбросил пока. На больших скоростях погляжу за netflow, может тоже в исходники придется лезть. Сейчас запустил пользователей еще в сервер, в ЧНН поглядим. Пока на одном проце X5660 (частота ограничена 2ггц) 750kpps, 5Gb full duplex загрузка 5%, жду с нетерпением вечера.

[Linux NAT]

но в самом conntrack-е должны обязательно быть включены таймстампы и аккаунтинг.

а вы с улогом не путаете? а то я обрадовался, все настроил и включил. счетчики по нулям, но сами нат евенты работают прекрастно. ядро 3.10.104, ipt_netflow 2.2.

получается nat events нужен только для логирования сессий и конечно плюс, не надо расчитывать сначенный ip

[Linux NAT]

У меня есть тазик, в ЧНН 2.6Mpps, но 2x10G

неплохо, а какие камни и сколько? я на гугл пока натю, но можно сказать специально, сейчас цель проверить производительность. Ибо lisg имеющиеся скоро в полки войдут. Завтра если выпрошу подсеть на нат, плюну 7 гигабит в добавок к 6FD, и будь что будет :)