nshut

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

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

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

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

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

В общем поигрался я и с очередями через исходники, и с разными ядрами и еще много чем. Разница в использовании на одном процессоре бондинга и без него составила 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 (частота*ядра). Один проц производительнее двух, вымывание кэша в разы меньше, но частота дополнительных ядер отодвигает полку. Отсюда вывод: один проц с кучей ядер и максимальной частотой, точно лучше двух в сумме частота*ядра.

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

настройки простые: тюнинг и прибитие попробовал, изменений ни в какую сторону не произошло. по графикам ппс и байты разруливаются идеально. Статистику сейчас приложить не могу. Разрушил все, точнее откатывал настройки и ядра. Сейчас на ядре 2.6.32-573.26. и вот на нем четко видно, что в бондинге не размазывается исходящий трафик по очередям, rx все ок, а отправка идет только с одной очереди каждого интерфейса, к примеру ix0 tx_queue_3_packets: 3945387. на 3.10 ядрах драйвера менял и интела и родные центоса, не помогало. Видимо bonding зло, другие сервера без него работают прекрасно. Но все-равно пытаюсь разобраться. Т.к. разруливать bgp или еще чем то, это лишний костыль, если есть технология lacp, она обязана работать. загрузил 3.10 ядро, подождал 10 сек и снял нагрузку видно, что в этот момент времени отправка шла большую часть в очередь 0, tx при этом идеально. Похоже через время очередь меняется и итого показатели ровные. Похоже без изучения мат части и исходников мне не обойтись :(

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

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

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

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

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

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

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

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

а разве трэйса нет краша? а то маловато инфы. Такая же система трудится без нареканий, конечно сервисы другие, но модулей ядра точно больше. я краши долго не разгребал, делал только так, в папке с крашем makedumpfile --dump-dmesg vmcore txt в трейсе практиески видно кто был инициатором до падения.

Люди добрые, ветку прочитал, но подскажите как тюнить ipt_NETFLOW (без натевентс)? В документации параметры описаны подробно как настраивать, но ничего нет о том, что они означают. Интересуют скорости 10Г и больше. Сейчас на моем сервере это самый жрущий процесс, естественно он сидит на одном процессоре, сендер видимо. стата:

в стейтфул фаерах есть понятие поиск, вставка, удаление сессии. Так доссы и ложат наты, отправляя много новых конектов. На линуксе не видел чтобы это анализировали, фрибсдшники всегда эти данные прикладывают, к примеру графики строить можно отсюда cat /proc/net/stat/nf_conntrack. Но не суть, раз никто этого не пишет, значит никто и не анализировал. Не помню в какой версии линукса выпилили роуте кэш, может это и есть проблема большого количества маршрутов. Я бы подумал как уйти от бгп. К примеру у наших натов два машрута, остальное делает маршрутизатор + немного pbr. конечно все зависит от индивидуальности конфигурации. Процессоры вещь вообще мутная. распайка влияет на производительность факт, но куча процессоров больше сделает чем куча в 2 раза меньше. Сколько не игрался показатели разные. Причем влияет сильно и мать. У меня 2 идентичных сервера lisg. Один лучше на 1 проце (на 2х дропает пакеты, хотя не загружен), второй на двух лучше первого, так что только тестинг.

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

2 Wiredom net.netfilter.nf_conntrack_tcp_timeout_established = 90 жестокий вы человек :) а вообще тоже склонен к правилам. если сделано для лучшего определения кто куда ходил. то временно нат в подсеть сделайте для оценки ситуации, а там думать. конечно пакет цепочку проходит один раз. Но в нат модуле проверка внешних айпи по возврату тоже 500 раз делается. Может ошибаюсь, но легче попробовать чем в исходники опять лезть

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

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

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

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