Jump to content
Калькуляторы

nshut

Пользователи
  • Content Count

    58
  • Joined

  • Last visited

Everything posted by nshut


  1. Что то далеко от темы ушли все. Я же лично думаю, что процессоры замерли в своей производительности, а сетевые потребности растут. Любая новая идея и продукт требует как минимум внимания. А дальнейшая разработка, поддержка и оплата, это уже дело автора, ну и в конце концов любой код станет опенсорсом или кто-то догадается повторить тоже самое в опен сорс, те же китайцы :) Что то они там перемудрили сильно, на тестах отказался в пользу 3 ядра, рхашинг ната при определенных условиях проц укладывал. Все, почему то прицепились к хашам ната, он не требовательный, посмотрите перф топ. Глобальная проблема как мне кажется все-таки отправка пакетов и разброс их в qdisc в очереди, вот если этот процесс избавить от локов, тогда и роутинг и фул стейты заживут (в текущем линуксе), а да, как раз фул стейты кушают процессорное время по более поиска и всего остального, а избавится от них можно отказавшись от фулстейт и только. Возможно превратить контрак в разные инстансы на процессоры с прибиваниям к очередям и есть альтернативное решение, но опять же исходники кто видел, знает, проще написать с нуля, а если это будет работать, то pptp и другие плюшки вопрос только времени.
  2. А в качестве платформы, какое железо? и показатели производительности в студию, все-таки 4 ядра, есть 4 ядра. Вообще надо составить табличку и в шапку прилепить. Каждый кто идет в эту тему, ищет такие данные
  3. роутить и натить не одно и то же. десятки гигабит и десятки mpps совсем разные вещи. Я не часто на форуме, но только и вижу, как у всех работают наты на целеронах, но ни одного практического результата толком не видел. Автор молодец! я лично тоже не нашел готового решения, а искал прилично. Уже ушел на ваш гит, пробовать тестить.
  4. В общем поигрался я и с очередями через исходники, и с разными ядрами и еще много чем. Разница в использовании на одном процессоре бондинга и без него составила 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 (частота*ядра). Один проц производительнее двух, вымывание кэша в разы меньше, но частота дополнительных ядер отодвигает полку. Отсюда вывод: один проц с кучей ядер и максимальной частотой, точно лучше двух в сумме частота*ядра.
  5. последую вашему совету, ну немножко. Начал интегрировать свои патчи в ядро 3.18. Увы не хочу переставлять и менять цент на убунту, только из-за ядра, ведь роутинг и нат затрагивают только ядро. Попробовал и 4ое ядро, но не буду разглагольстовать на предмет выбора. В общем на недельку пропал, пока все пилю, далее выложу результаты. Обязательно выложу результаты бондинга и без него, чего увы сам не нашел, да геморой, но истину узнать хочется =)
  6. настройки простые: тюнинг и прибитие попробовал, изменений ни в какую сторону не произошло. по графикам ппс и байты разруливаются идеально. Статистику сейчас приложить не могу. Разрушил все, точнее откатывал настройки и ядра. Сейчас на ядре 2.6.32-573.26. и вот на нем четко видно, что в бондинге не размазывается исходящий трафик по очередям, rx все ок, а отправка идет только с одной очереди каждого интерфейса, к примеру ix0 tx_queue_3_packets: 3945387. на 3.10 ядрах драйвера менял и интела и родные центоса, не помогало. Видимо bonding зло, другие сервера без него работают прекрасно. Но все-равно пытаюсь разобраться. Т.к. разруливать bgp или еще чем то, это лишний костыль, если есть технология lacp, она обязана работать. загрузил 3.10 ядро, подождал 10 сек и снял нагрузку видно, что в этот момент времени отправка шла большую часть в очередь 0, tx при этом идеально. Похоже через время очередь меняется и итого показатели ровные. Похоже без изучения мат части и исходников мне не обойтись :(
  7. убит на этапе инсталяции оси. прерывания по кол-ву из милиона в районе сотен точно сходятся по ядрам, т.е. все поровну на ядра. дело думаю именно в бондинге и его локах, т.к. допустим до 800мппс загрузка максимум 7%, после 850 50%, т.е. слишком резкий рывок, так локи обычно чудят. Да и разбаланс по ядрам видмо tx queue делает. Беда в том, что не могу найти нормальную конфигурацию и тесты бондинга на высокой производительности. Все только пишут как научились болячки бондинга решать, а решений не видел. Может вообще тупость в какой-нить настройке о которой я и не помню(не знаю).
  8. День добрый. Снова вопросы. ядро 3.10.104, использую bonding X520da2. процы 2xX5660. Два порта в бондинге, а там вланы. Распределение загрузок ядер неравномерное, т.е. то одни ядра загружены, то другие, каждые 2-5 сек меняется. При 1.7mpps то и дело одно из ядер пытается вырваться в полку. По иперфу на втором месте _raw_spin_lock 2%, выше писали что его бондинг и вызывает. 2% не много, но я понимаю, что на 12 ядрях, 2% это одно ядро в в сплошном локе. очереди 4096. Прерывания в ЧНН и понижал и повышал, через rx-usec. Толку нет. Какие то есть специфические настройки bonding чтобы было ровней все это дело? Никаких потерь и ошибок нет, но в полке конечно будут. На форуме находил кучу обсуждений bondinga, но кроме совета его не использовать решения не видел. Хотя здесь же выше писали что 20gbps выжали и работает. Как он вообще тюнится, где рыть? может есть ixgbe надо специфично настроить для бондинга. и да, очереди конечно прибиты жестко, в интеруптах по количеству прерываний на очередь все ровно, как и сама балансировка.
  9. во первых спасибо за разъяснения. документацию конечно читал, но или английский слаб или не понимаю просто. к примеру, я не использую, но так и не понял надо ли использовать. Задача: трафик > 10G, подсчет байтов скачанных пока обязателен. На данную задачу необходимы оптимальные параметры. Т.е. если надо использовать для производительности, то я буду. У меня задача оптимизировать максимально, а я туповат :) чтобы понять что делает sampler. На пальцах может кто объяснить зачем он? понятия хашь и рандом я сам знаю, мне цель этого сэмплера не известна
  10. Там линукс + кастомный софт который через DPDK пакеты жуёт. rdp.ru это пишет и барыжит. В обычных ОС на каждый отдельный пакет сильно много проверок, а там сильно облегчённый даже не стёк а просто транслятор. зашел на сайт, кроме красивых слов ничего толком не нашел, ну да ладно. Не раз думал о dpk и нетмап, но от фул стэйт никуда ведь не денешся. А доп протоколы типо гре требуют вмешательства в пакет, как и нат обязан adjust seq делать, т.е. одними заголовками не отделаться. Лень считать по производительности шины и памяти, но софтос врядли 110 выдаст, если речь x86-64, а не специфические спарк и т.д. с ценой соотетствующей.
  11. взлетит, но если чек сум ядра и модуля не сойдутся, то модуль просто не загрузится. сойдется ли он или нет никто не знает :)
  12. да правильно, но у меня было ядро другое и в трэйсе были упоминания что иому включен. я говорю я не спец в крашах. вообще у вас видно вот что napi_gro_receive. не знаю должна ли быть она в выключенном gro, но интел в своих драйверах пишет: "Disable GRO when routing/bridging" ethtool -K ethX gro off". как и lro, но опять же, может у вас все это настроено. я верю интел и всегда это выключаю
  13. вот пример моего дампа смерти. RIP показывает где умерло, дальше видим, был вызов mod_timer, его вызвал inet_frag_in. выводы, функция фрагментации попыталась обратиться к таймеру, который либо умер, либо нет указателя на него. в общем здесь явно в модуле ядра смерть пришла. как то у меня падал роутер связанный с фибом по включенному иому, но это у меня ядро 3.10 было, вылечилось грабе intel_iommu=off
  14. очень информативно... у меня было 1, делал 10,20,30,100. меня интересуют все параметры, в том числе sample hash и буфер send что помогут произодительности. тыкать разные валуе в настройки я пробовал, поэтому и прошу пояснить что на что влияет. Пока у меня идея вынести его на отдельное ядро, отдельно от очередей
  15. а разве трэйса нет краша? а то маловато инфы. Такая же система трудится без нареканий, конечно сервисы другие, но модулей ядра точно больше. я краши долго не разгребал, делал только так, в папке с крашем makedumpfile --dump-dmesg vmcore txt в трейсе практиески видно кто был инициатором до падения.
  16. Люди добрые, ветку прочитал, но подскажите как тюнить ipt_NETFLOW (без натевентс)? В документации параметры описаны подробно как настраивать, но ничего нет о том, что они означают. Интересуют скорости 10Г и больше. Сейчас на моем сервере это самый жрущий процесс, естественно он сидит на одном процессоре, сендер видимо. стата:
  17. в стейтфул фаерах есть понятие поиск, вставка, удаление сессии. Так доссы и ложат наты, отправляя много новых конектов. На линуксе не видел чтобы это анализировали, фрибсдшники всегда эти данные прикладывают, к примеру графики строить можно отсюда cat /proc/net/stat/nf_conntrack. Но не суть, раз никто этого не пишет, значит никто и не анализировал. Не помню в какой версии линукса выпилили роуте кэш, может это и есть проблема большого количества маршрутов. Я бы подумал как уйти от бгп. К примеру у наших натов два машрута, остальное делает маршрутизатор + немного pbr. конечно все зависит от индивидуальности конфигурации. Процессоры вещь вообще мутная. распайка влияет на производительность факт, но куча процессоров больше сделает чем куча в 2 раза меньше. Сколько не игрался показатели разные. Причем влияет сильно и мать. У меня 2 идентичных сервера lisg. Один лучше на 1 проце (на 2х дропает пакеты, хотя не загружен), второй на двух лучше первого, так что только тестинг.
  18. влан как и бондинг влияния практически не оказывает, при перестройке сети вечно то прихожу к вланам, то ухожу, разницы ноль. и еще, когда пишите загрузку, загрузка проца 65% понятие растяжимое, одно ядро 2%, другое 90. ну и плюс все от ппс зависит, трафик может быть ни о чем. графики выше показывают зависимость именно ппс. я бы увеличил tcp_establish время, ибо поиск в контреке это намного быстрее чем удаление, а удалив сессию открытую клиент ее переподымет заново, не знаю поможет ли, но чисто мое мнение. Графиков insert-delete никто (в отличии от бсдшников) не выкладывает, а зря.
  19. 2 Wiredom net.netfilter.nf_conntrack_tcp_timeout_established = 90 жестокий вы человек :) а вообще тоже склонен к правилам. если сделано для лучшего определения кто куда ходил. то временно нат в подсеть сделайте для оценки ситуации, а там думать. конечно пакет цепочку проходит один раз. Но в нат модуле проверка внешних айпи по возврату тоже 500 раз делается. Может ошибаюсь, но легче попробовать чем в исходники опять лезть
  20. честно перечитал все 3 раза. если у вас действительно длинк маршрутизатор, то все дело в нем, увы на л3 я его не пользовал. но 1. ничего не надо в лупбэки прописывать. и какие то no_bind тоже в жизни не делал. в общем даже нат сеть не назначайте пока. идите на 3120 и sh ipr, может для теста вы там эту подсеть подымали и забыли удалить. пинг с инета и дамп на сетевой. Если он действительно л3, значит собака там зарыта, прошивку в конце концов обновить ибо и покруче у длинков моделей есть баги в не стандартой маской маршрута. они видимо все на 24 тестят
  21. ну netflow коллектор тоже проц грузит, я допустим пока с миррор порта не хочу трафик снимать. На глаз евенты загрузили проц тоже больше, чем трафик правилом, а так как каунтеры не помогли отбросил пока. На больших скоростях погляжу за netflow, может тоже в исходники придется лезть. Сейчас запустил пользователей еще в сервер, в ЧНН поглядим. Пока на одном проце X5660 (частота ограничена 2ггц) 750kpps, 5Gb full duplex загрузка 5%, жду с нетерпением вечера.
  22. а вы с улогом не путаете? а то я обрадовался, все настроил и включил. счетчики по нулям, но сами нат евенты работают прекрастно. ядро 3.10.104, ipt_netflow 2.2. получается nat events нужен только для логирования сессий и конечно плюс, не надо расчитывать сначенный ip
  23. неплохо, а какие камни и сколько? я на гугл пока натю, но можно сказать специально, сейчас цель проверить производительность. Ибо lisg имеющиеся скоро в полки войдут. Завтра если выпрошу подсеть на нат, плюну 7 гигабит в добавок к 6FD, и будь что будет :)
  24. не обязательно линукс, можно и фряху. интересует софтнат. 110 гигабит, хм, наверно размер пакета 1 гиг и был :) Естественно нат айпи в айпи не интересует, я такое минут за 10 напишу на любой оси. Просто все что я находил меньше 1мппс, ну редко чуть больше. Интересуют возможности. Про ограничение пси-экспресс и слушать не хочу. Процы растут, память тоже, а все топчутся на 1-2мппс, ну не верю. К примеру есть статья "Recipe for building a 10Mpps FreeBSD based router" и другие, но это все синтетик тесты, я же интересуюсь практическим использованием.
  25. локи весч не однозначная. отследить в режиме lock_trace мне так и не удалось на загруженной системе. ибо локи перфа сжирают весь проц. Плюс патч разделения локов на контрак не дал прироста в стейтфул, а только на новые и удаляемые сессии. Кто может объяснить несколько вещей, много перечитал но не все нашел. 1. Сколько максимум выжимали pps на nat, выше писали 2.2mpps, это фуллдуплекс? есть где-нибудь тесты не 100 летней давности. 2. "UDP хэшинг по портам включен", это что и что дает? тыкните ссылкой если не сложно 3. nat events, я так понимаю берет эвенты с модуля контрэк, т.е. храним все сессии без направления трафика в netflow. а как же скачанные байты и пакеты, где их снимают? или я не так понимаю. И можно настройки модуля тоже в студию, у меня модуль в2.2 нагло жрет от 4% до 20%, фактически пики цпу он и делает по своим экспериментам скажу, очереди вроди бы выравнивают лучше загрузку проца если отправлять по 2 очереди на ядро. При загрузке >5Gbp/s речи о буфере 2048 и меньше речи не идет, ставлю максимум. я на продакшине экспериментальном приблизился к 0.9мппс, загрузка ни о чем 20% (и неравномерность). Хочу плюнуть еще 800мппс для теста, но так как продакшин не хочу уронить его. после запуска в бой еще абонентов на новый серв графики и результаты выложу, до 1 мппс смысла нет.