Ivan_83 Опубликовано 30 ноября, 2016 · Жалоба 1. Сколько максимум выжимали pps на nat, выше писали 2.2mpps, это фуллдуплекс? есть где-нибудь тесты не 100 летней давности. Сколько линуксовым натом хз, а вот натом на писюке делали 110 гигабит, правда размер какета я не знаю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nshut Опубликовано 30 ноября, 2016 (изменено) · Жалоба Сколько линуксовым натом хз, а вот натом на писюке делали 110 гигабит, правда размер какета я не знаю не обязательно линукс, можно и фряху. интересует софтнат. 110 гигабит, хм, наверно размер пакета 1 гиг и был :) Естественно нат айпи в айпи не интересует, я такое минут за 10 напишу на любой оси. Просто все что я находил меньше 1мппс, ну редко чуть больше. Интересуют возможности. Про ограничение пси-экспресс и слушать не хочу. Процы растут, память тоже, а все топчутся на 1-2мппс, ну не верю. К примеру есть статья "Recipe for building a 10Mpps FreeBSD based router" и другие, но это все синтетик тесты, я же интересуюсь практическим использованием. Изменено 30 ноября, 2016 пользователем nshut Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 30 ноября, 2016 · Жалоба У меня есть тазик, в ЧНН 2.6Mpps, но 2x10G уже почти забиты (7.41Gbit/s на каждом порту). Насчет правил - я даже не особо оптимизировал, т.к. делаю хитрые реверансы с connmark и прочим, и тем не менее больше половины процессорного ресурса свободны. А сейчас еще и GGC сделал возможность гонять траффик с серыми IP на него, чем я и воспользуюсь, и может еще полгодика проживу без апгрейда железа. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nshut Опубликовано 30 ноября, 2016 · Жалоба У меня есть тазик, в ЧНН 2.6Mpps, но 2x10G неплохо, а какие камни и сколько? я на гугл пока натю, но можно сказать специально, сейчас цель проверить производительность. Ибо lisg имеющиеся скоро в полки войдут. Завтра если выпрошу подсеть на нат, плюну 7 гигабит в добавок к 6FD, и будь что будет :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 30 ноября, 2016 · Жалоба два E5-2640 v3 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
evil-man Опубликовано 30 ноября, 2016 · Жалоба 3. nat events, я так понимаю берет эвенты с модуля контрэк, т.е. храним все сессии без направления трафика в netflow. а как же скачанные байты и пакеты, где их снимают? или я не так понимаю. И можно настройки модуля тоже в студию, у меня модуль в2.2 нагло жрет от 4% до 20%, фактически пики цпу он и делает nat events построен поверх событий от conntrack. Счётчики пакетов и байтов так же хранятся в записях коннтрака, но в самом conntrack-е должны обязательно быть включены таймстампы и аккаунтинг. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nshut Опубликовано 1 декабря, 2016 · Жалоба но в самом conntrack-е должны обязательно быть включены таймстампы и аккаунтинг. а вы с улогом не путаете? а то я обрадовался, все настроил и включил. счетчики по нулям, но сами нат евенты работают прекрастно. ядро 3.10.104, ipt_netflow 2.2. получается nat events нужен только для логирования сессий и конечно плюс, не надо расчитывать сначенный ip Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 1 декабря, 2016 · Жалоба От включенного в conntrack аккаунтинга проц немного растет, замерял давно "на глаз". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nshut Опубликовано 1 декабря, 2016 · Жалоба От включенного в conntrack аккаунтинга проц немного растет, замерял давно "на глаз". ну netflow коллектор тоже проц грузит, я допустим пока с миррор порта не хочу трафик снимать. На глаз евенты загрузили проц тоже больше, чем трафик правилом, а так как каунтеры не помогли отбросил пока. На больших скоростях погляжу за netflow, может тоже в исходники придется лезть. Сейчас запустил пользователей еще в сервер, в ЧНН поглядим. Пока на одном проце X5660 (частота ограничена 2ггц) 750kpps, 5Gb full duplex загрузка 5%, жду с нетерпением вечера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 1 декабря, 2016 · Жалоба У меня нагрузка на проц от ipt_NETFLOW была минимальна (но ессно была), необходимости в исходники лезть не было. Да и не думаю, что будет особо толк. Кстати, в теории если логировать обьемы не надо, а лишь для "органов" - то можно и отвинтить ему считалку, по идее нагрузку на проц снизит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 1 декабря, 2016 · Жалоба не обязательно линукс, можно и фряху. интересует софтнат. 110 гигабит, хм, наверно размер пакета 1 гиг и был :) Там линукс + кастомный софт который через DPDK пакеты жуёт. rdp.ru это пишет и барыжит. В обычных ОС на каждый отдельный пакет сильно много проверок, а там сильно облегчённый даже не стёк а просто транслятор. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nshut Опубликовано 2 декабря, 2016 · Жалоба не обязательно линукс, можно и фряху. интересует софтнат. 110 гигабит, хм, наверно размер пакета 1 гиг и был :) Там линукс + кастомный софт который через DPDK пакеты жуёт. rdp.ru это пишет и барыжит. В обычных ОС на каждый отдельный пакет сильно много проверок, а там сильно облегчённый даже не стёк а просто транслятор. зашел на сайт, кроме красивых слов ничего толком не нашел, ну да ладно. Не раз думал о dpk и нетмап, но от фул стэйт никуда ведь не денешся. А доп протоколы типо гре требуют вмешательства в пакет, как и нат обязан adjust seq делать, т.е. одними заголовками не отделаться. Лень считать по производительности шины и памяти, но софтос врядли 110 выдаст, если речь x86-64, а не специфические спарк и т.д. с ценой соотетствующей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
big-town Опубликовано 6 декабря, 2016 (изменено) · Жалоба Использую Linux nat 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux В час пик натит трафик 2.5Гбит. железо: 2хIntel® Xeon® CPU E5620 @ 2.40GHz Intel Corporation 82599EB 10-Gigabit SFI/SFP+ на нем же ipt_NETFLOW - сбор статистики IPSET+squid 3.4 - как фильтр РКН Загрузка в пике около 30%. 00:27:03 up 231 days, 36 min, 1 user, load average: 0.31, 0.43, 0.47 Мой sysctl.conf net.ipv4.ip_forward = 1 net.ipv4.neigh.default.gc_thresh1 = 4096 net.ipv4.neigh.default.gc_thresh2 = 8192 net.ipv4.neigh.default.gc_thresh3 = 8192 net.ipv4.neigh.default.base_reachable_time = 86400 net.ipv4.neigh.default.gc_stale_time = 86400 net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.all.arp_announce = 2 net.ipv4.conf.all.arp_filter = 1 net.ipv4.tcp_syn_retries = 4 net.ipv4.tcp_synack_retries = 4 net.ipv4.tcp_max_syn_backlog = 4096 net.ipv4.tcp_fin_timeout = 15 net.core.somaxconn = 16384 net.core.netdev_max_backlog = 10000 net.core.rmem_default = 16777216 net.core.wmem_default = 16777216 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_mem = 287160 16777216 16777216 net.ipv4.tcp_rmem = 287160 16777216 16777216 net.ipv4.tcp_wmem = 287160 16777216 16777216 net.ipv4.ip_local_port_range = 1024 65500 net.ipv4.ip_local_reserved_ports = 3333,10050 net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 60 net.netfilter.nf_conntrack_tcp_timeout_time_wait = 20 net.netfilter.nf_conntrack_tcp_timeout_established = 12500 net.netfilter.nf_conntrack_max=1048576 net.nf_conntrack_max=1048576 net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 net.ipv6.conf.lo.disable_ipv6 = 1 net.core.warnings=0 Обязательно нужно раскинуть по прерываниям, на интеловском сайте есть скрипт. Буферы делаем по максимуму. ethtool -G ethX rx tx 4096 Очередь рекомендуют 30000, но на моем трафике разницы не заметил. ifconfig ethX txqueuelen 30000 Изменено 6 декабря, 2016 пользователем big-town Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nshut Опубликовано 7 декабря, 2016 · Жалоба День добрый. Снова вопросы. ядро 3.10.104, использую bonding X520da2. процы 2xX5660. Два порта в бондинге, а там вланы. Распределение загрузок ядер неравномерное, т.е. то одни ядра загружены, то другие, каждые 2-5 сек меняется. При 1.7mpps то и дело одно из ядер пытается вырваться в полку. По иперфу на втором месте _raw_spin_lock 2%, выше писали что его бондинг и вызывает. 2% не много, но я понимаю, что на 12 ядрях, 2% это одно ядро в в сплошном локе. очереди 4096. Прерывания в ЧНН и понижал и повышал, через rx-usec. Толку нет. Какие то есть специфические настройки bonding чтобы было ровней все это дело? Никаких потерь и ошибок нет, но в полке конечно будут. На форуме находил кучу обсуждений bondinga, но кроме совета его не использовать решения не видел. Хотя здесь же выше писали что 20gbps выжали и работает. Как он вообще тюнится, где рыть? может есть ixgbe надо специфично настроить для бондинга. и да, очереди конечно прибиты жестко, в интеруптах по количеству прерываний на очередь все ровно, как и сама балансировка. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
big-town Опубликовано 7 декабря, 2016 (изменено) · Жалоба У меня подобное было когда оставлял штатный irqbalancer. Его вырубить все сетевухи вручную развести по прерываниям. Скрипт для разведения по прерываниям использую такой: for interface in eth0 eth1 eth2 eth3 do /sbin/ethtool -K $interface tso off gso off gro off /sbin/ethtool -A $interface autoneg off rx off tx off /sbin/ethtool -G $interface rx 4096 /sbin/ethtool -G $interface tx 4096 n=`cat "$filenn"` for irq in `cat /proc/interrupts |grep " ${interface}-"|cut -d: -f1 |tr -d ' '` do f="/proc/irq/$irq/smp_affinity" test -r "$f" || continue cpu=$[$ncpus - ($n % $ncpus) - 1] if [ $cpu -ge 0 ] then mask=`printf %x $[2 ** $cpu]` echo "$mask" > "$f" echo "$n $interface" "$mask" "$f" let n+=1 fi echo "$n">"$filenn" done done Иначе после запуск скрипта все ОК,а со временем одно ядро в 100% уходило. Изменено 7 декабря, 2016 пользователем big-town Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nshut Опубликовано 7 декабря, 2016 · Жалоба У меня подобное было когда оставлял штатный irqbalancer убит на этапе инсталяции оси. прерывания по кол-ву из милиона в районе сотен точно сходятся по ядрам, т.е. все поровну на ядра. дело думаю именно в бондинге и его локах, т.к. допустим до 800мппс загрузка максимум 7%, после 850 50%, т.е. слишком резкий рывок, так локи обычно чудят. Да и разбаланс по ядрам видмо tx queue делает. Беда в том, что не могу найти нормальную конфигурацию и тесты бондинга на высокой производительности. Все только пишут как научились болячки бондинга решать, а решений не видел. Может вообще тупость в какой-нить настройке о которой я и не помню(не знаю). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
big-town Опубликовано 7 декабря, 2016 (изменено) · Жалоба Попробуйте воспользоваться скриптом что я дал в посте http://forum.nag.ru/forum/index.php?showtopic=98864&view=findpost&p=1350319, и твиками отсюда http://forum.nag.ru/forum/index.php?showtopic=98864&view=findpost&p=1350120, затем покажите atop 1 при 850. И покажите конфиг бондинга. Изменено 7 декабря, 2016 пользователем big-town Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nshut Опубликовано 8 декабря, 2016 (изменено) · Жалоба настройки простые: 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 при этом идеально. Похоже через время очередь меняется и итого показатели ровные. Похоже без изучения мат части и исходников мне не обойтись :( Изменено 8 декабря, 2016 пользователем nshut Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 8 декабря, 2016 · Жалоба А это пробовали выставлять ? for i in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor do echo performance > $i done Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 8 декабря, 2016 · Жалоба Вроде встречал тут инфу про какой-то крутилятор генерирования прерываний в случае бондинга.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
big-town Опубликовано 9 декабря, 2016 · Жалоба Похоже без изучения мат части и исходников мне не обойтись Попробуйте проделать это на свежей ubuntu lts, поставить актуальное ядро, собрать свежий драйвер сетевых карт руками. Мне помогло в свое время. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nshut Опубликовано 10 декабря, 2016 · Жалоба Попробуйте проделать это на свежей ubuntu lts, поставить актуальное ядро, собрать свежий драйвер сетевых карт руками. Мне помогло в свое время последую вашему совету, ну немножко. Начал интегрировать свои патчи в ядро 3.18. Увы не хочу переставлять и менять цент на убунту, только из-за ядра, ведь роутинг и нат затрагивают только ядро. Попробовал и 4ое ядро, но не буду разглагольстовать на предмет выбора. В общем на недельку пропал, пока все пилю, далее выложу результаты. Обязательно выложу результаты бондинга и без него, чего увы сам не нашел, да геморой, но истину узнать хочется =) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nshut Опубликовано 16 декабря, 2016 (изменено) · Жалоба В общем поигрался я и с очередями через исходники, и с разными ядрами и еще много чем. Разница в использовании на одном процессоре бондинга и без него составила 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 (частота*ядра). Один проц производительнее двух, вымывание кэша в разы меньше, но частота дополнительных ядер отодвигает полку. Отсюда вывод: один проц с кучей ядер и максимальной частотой, точно лучше двух в сумме частота*ядра. Изменено 16 декабря, 2016 пользователем nshut Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
boco Опубликовано 16 декабря, 2016 · Жалоба Отсюда вывод: один проц с кучей ядер и максимальной частотой, точно лучше двух в сумме частота*ядра. поэтому мы натим на дешевых e3-1240 =) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
No_name Опубликовано 16 декабря, 2016 · Жалоба поэтому мы натим на дешевых e3-1240 =) А в качестве платформы, какое железо? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...