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

nshut

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

    58
  • Joined

  • Last visited

About nshut

  • Rank
    Абитуриент

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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 в трейсе практиески видно кто был инициатором до падения.