Zohan Опубликовано 21 февраля, 2011 · Жалоба Кто-нибудь использует его в паблике? Поставил на Убунту 10.10 с последним ядром 2.6.35-25-generic-pae трафик идет через машину около 300-400 Мбит по вечерам начинаются глюки - программные прерывания резко ложатся на один процессор и лочится функция __ticket_spin_lock (perf top) - резко возрастает пинг помогает удаление всех правил, правила такого типа: ipfw pipe 1 config bw 3000Kbit/s queue 50 ipfw pipe 2 config bw 3000Kbit/s queue 50 ipfw add 1 pipe 1 all from 175.2**.*.101 to any out ipfw add 2 pipe 2 all from not any to 175.2**.*.101 in никто с таким не встречался? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
t00r Опубликовано 7 декабря, 2011 (изменено) · Жалоба Господа, подскажите - поставил в тесте данную связку. ipfw собрал из пакет не с сайта - вот этой версии - ipfw3-20110810. в логах чисто. root@nat2:~/src/ipfw3# uname -a Linux nat2 2.6.32-35-generic-pae #78-Ubuntu SMP Tue Oct 11 17:01:12 UTC 2011 i686 GNU/Linux Dec 7 21:50:47 nat2 kernel: [ 2922.997020] UDP: short packet: From 64.30.2.130:47188 25649/111 to 109.197.112.74:42159 - это торренты Dec 7 21:03:09 nat2 kernel: [ 65.140761] ip_tables: (C) 2000-2006 Netfilter Core Team Dec 7 21:03:09 nat2 kernel: [ 65.149602] nf_conntrack version 0.5.0 (15995 buckets, 63980 max) Dec 7 21:03:09 nat2 kernel: [ 65.149957] CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use Dec 7 21:03:09 nat2 kernel: [ 65.149961] nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or Dec 7 21:03:09 nat2 kernel: [ 65.149964] sysctl net.netfilter.nf_conntrack_acct=1 to enable it. тут тоже криминала не вижу симптомы: поток небольшой - максимум 220-250 мегабит, на нате не более 600 юзеров, скорость со спидтеста ( у меня нет ограничения ) - 97 мегабит. а вот странички грузятся ужасно долго, скорость торрентов падает до 20-30 килобит. значения максимального размера контрекка увеличил до 128000 - все тоже самое. куда копать то? вот значения статистики коннтрака: root@nat2:~/src/ipfw3# conntrack -S entries 38054 searched 1785955 found 1950205 new 243660 invalid 106637 ignore 0 delete 119026 delete_list 115871 insert 243406 insert_failed 107 drop 0 early_drop 0 icmp_error 92166 expect_new 0 expect_create 0 expect_delete 0 root@nat2:~/src/ipfw3# conntrack -S entries 40220 searched 2355562 found 2094633 new 257371 invalid 108394 ignore 0 delete 121920 delete_list 118424 insert 257117 insert_failed 107 drop 0 early_drop 0 icmp_error 92194 expect_new 0 expect_create 0 expect_delete 0 root@nat2:~/src/ipfw3# conntrack -S entries 21981 searched 3671009 found 2455966 new 305763 invalid 114748 ignore 84 delete 139758 delete_list 134089 insert 305448 insert_failed 135 drop 0 early_drop 0 icmp_error 93011 expect_new 0 expect_create 0 expect_delete 0 root@nat2:~/src/ipfw3# роутинг на эту машину включал буквально на пару минут на ядре Изменено 7 декабря, 2011 пользователем t00r Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
t00r Опубликовано 8 декабря, 2011 (изменено) · Жалоба После небольшого гугления ( у меня просто все сервера на фре - линух немного подзабыл ) - думаю, дело в параметре HZ .... у меня ядро дефолтное с параметром 100 p.s. наврал - по дефолту там 250 Изменено 8 декабря, 2011 пользователем t00r Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
t00r Опубликовано 8 декабря, 2011 · Жалоба Да. Пересборка ядра помогла. Замечу, что нат был собран не на физике, а на цитрикс ксене. В итоге я получил на 8 ядрах 4 нат машины. По 2 ядра на каждой. Так как сетевухи мы прибиваем к ядрам, то производительность 1 физической машине на 4 виртуалках по 2 ядра на каждой выросла реально. Ща погоняю за выходные и могу дать конфиги. ОСь - убунта с ядром 2.6.32.46+drm33.20, родной iptables и порт ipfw+dummynet На одной физической машине живет сеть из 3200 юзеров. Тесты скорости в пик отдают всё ровно по тарифу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
t00r Опубликовано 8 декабря, 2011 · Жалоба Нагруз на бордере за которой стоит это все можно смотреть тут http://109.197.112.1/graphs/iface/ether1-fortex/ С новым ядром ксен заработал где-то в 12 утра - это видно по графику. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
220B Опубликовано 27 декабря, 2011 (изменено) · Жалоба Роутер: Ubuntu c ядром 2.6.32-30-generic-pae, Dell-1950 два QC CPU, два Intel 82571EB, 4Гб ОЗУ, SAS 15k mirror ПО: quagga(zebra,bgpd принимаю только дэфолт), bind, ntpd, mrtg(по крону раз в 5 минут строит пару десятков графиков используя snmp с удаленных узлов и парся баш скриптами структуры локальных счетчиков ядра нужных параметров системы), iptables (nat-пару строк, TOS маркировка пакетов, резалка не нужного трафика - десяток правил), ipfw3 (была версия апрельская, сейчас поставил последнюю летнюю; использую для шейпа без очередей на основе хэш-таблиц в пайпах и оттуда же снимаю каждые 10 секунд php скриптом статистику по трафику - всего в сети полторы тысячи хостов) Линки:пир1=1Гбит,пир2=100Мбит,сеть потребителей=1Гбит (все сидит на картах 82571EB c последними сдровами с NAPI и прибитое по отдельным ядрам) Тюнинг: killall -9 irqbalance modprobe e1000e InterruptThrottleRate=1,1,1,1 ethtool -G eth0 rx 4096 tx 4096 ... ethtool -K eth0 gso off ... ifconfig eth0 txqueuelen 5000 ... sysctl -w net.ipv4.ip_forward=1 sysctl -w kernel.panic=1 sysctl -w net.ipv4.neigh.default.gc_thresh1=2048 sysctl -w net.ipv4.neigh.default.gc_thresh2=4096 sysctl -w net.ipv4.neigh.default.gc_thresh3=16384 sysctl -w net.ipv4.tcp_mem="8388608 8388608 8388608" sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216" sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216" sysctl -w net.unix.max_dgram_qlen=2500 sysctl -w net.core.rmem_default=131072 sysctl -w net.core.wmem_default=131072 sysctl -w net.core.rmem_max=16777216 sysctl -w net.core.wmem_max=16777216 sysctl -w net.core.netdev_max_backlog=5000 sysctl -w net.ipv4.route.max_size=1048576 # simple anti DoS/DDoS sysctl -w net.ipv4.tcp_fin_timeout=15 sysctl -w net.ipv4.tcp_max_orphans=131072 sysctl -w net.ipv4.tcp_max_syn_backlog=2048 sysctl -w net.ipv4.tcp_synack_retries=2 sysctl -w net.ipv4.tcp_syncookies=1 sysctl -w net.ipv4.tcp_sack=0 sysctl -w net.ipv4.tcp_timestamps=0 sysctl -w net.ipv4.tcp_window_scaling=0 sysctl -w net.ipv4.tcp_keepalive_intvl=10 sysctl -w net.ipv4.tcp_keepalive_probes=5 sysctl -w net.ipv4.tcp_keepalive_time=1800 sysctl -w net.ipv4.tcp_keepalive_time=60 ulimit -n 1000000 echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter echo 0 > /proc/sys/net/ipv4/conf/default/rp_filter echo "1" > /sys/module/ipfw_mod/parameters/io_fast echo "16384" > /sys/module/ipfw_mod/parameters/hash_size echo "16384" > /sys/module/ipfw_mod/parameters/dyn_buckets echo "16384" > /sys/module/ipfw_mod/parameters/dyn_max echo "10" > /sys/module/ipfw_mod/parameters/autoinc_step echo "0" > /sys/module/ipfw_mod/parameters/verbose Проблемы: 1)заставляет нервничать постоянно заваливающие консоль и syslog сообщения вида: Bump sched buckets to ... Бороздя гугль, делаю выводы что я не одинок, но люди либо мирятся с этим либо Фряшники успешно фиксят. Под линуксом же не нашел пока решения. 2)как не бился, но не могу без заметных потерь заставить сетевые нормально прокачивать Гиг трафика. Как только количество пакетов превышает 70kpps обработка пакетов явно деградирует, что пагубно влияет на латентность сети. Заметил что иногда явно на одном ядре образовывается очередь, но прерывания почему-то не вызываются так часто, на сколько бы это было нужно и такие "залипания" могут спонтанно появляться и длится минутами. Пробовал ночью когда мало нагрузки выгружать ipfw и тестировать iperf_ом - даже в таком состоянии в один поток не могу добиться от сетевых более 300Мбит/с и 70кpps хотя на более простых встроенных бродкомах iperf показывает в один поток 940 Мбит/с 3)на днях появились дополнительные странные симптомы: ipfw_mod.ko падает, записывая в журнал сообщение "bw is null". Открыв исходники, никак не пойму как модулю попадает значение bw равное нулю если я его явно передаю правильно. Результатом "падения" является полная или частичная деградация всех ядерных функций на срок от 5сек до пары минут, т.е. не обрабатываются прерывания, не выделяется память под структуры данных уже работающих демонов - в общем отказ от обслуживания... Правда всегда само собой восстанавливается, но от этого не легче. Поставил сейчас последнюю версию - понаблюдаю ещё. Если кто-то решал подобные задачи, буду рад услышать рекомендации. _INF_, я верно понял, что Вам удалось решить проблему, описываемую мной в первом пункте? Можно полюбопытствовать на счет того какая у вас система и какой тюнинг делали для этого? t00r, Ваш опыт весьма интересен, но я так и не понял конкретной последовательности действий, после чего у Вас стало всё так хорошо. Изменено 28 декабря, 2011 пользователем 220B Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 27 декабря, 2011 · Жалоба Какие занимательные извращения :) Родной tc работает стабильно как скала, с хеш-таблицами ресурсов потребляет минимум, трафика на нормальном железе жует сколько в интерфейсы влезет. Конфиг для больших сетей получается конечно монструозным, но кому от этого хуже? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 28 декабря, 2011 · Жалоба Да пофиг на монструозность конфигов. Все равно они генерятся скриптами для скриптов и глазами в них никто не смотрит. Я долго понять не мог, если говорят за ipfw, то при чем тут линух? А оказывается это народ, вместо освоения стандартных и отлаженных инструментов играет в BSDM с кривыми портами из других систем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wtyd Опубликовано 29 декабря, 2011 · Жалоба Да пофиг на монструозность конфигов. Все равно они генерятся скриптами для скриптов и глазами в них никто не смотрит. Я долго понять не мог, если говорят за ipfw, то при чем тут линух? А оказывается это народ, вместо освоения стандартных и отлаженных инструментов играет в BSDM с кривыми портами из других систем. BSDM это типа игра слов/букв из BDSM и FreeBSD ? Надо запомнить ;-))). Ну а вообще да, я с этой темы тоже офигел. Тут же ещё и виртуалки упоминались - очень неправдоподобным выглядит утверждение о получении выигрыша в производителдьности на виртуалках, виртуалки всегда проигрывают в производительности, просто их перетаскивать и бекапить удобнее, чем живые серверы. Реально какая-то странная тема :-). BonDage Sado Mazo прям. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mkc Опубликовано 29 декабря, 2011 · Жалоба Тут же ещё и виртуалки упоминались - очень неправдоподобным выглядит утверждение о получении выигрыша в производителдьности на виртуалках, виртуалки всегда проигрывают в производительности, просто их перетаскивать и бекапить удобнее, чем живые серверы. Я не утверждаю, что данное решение лучше или хуже. Дам просто пример. У меня есть 2 тестовые физические машины ( одинаковые ): На базе: Vendor: GenuineIntel Model: Intel® Xeon® CPU E31230 @ 3.20GHz Speed: 3192 MHz Машины для доступа pptp, l2tp Ось для доступа: FreeBSD 8.2-STABLE, mpd5, kernel_space_nat Вариант 1 - просто сделать 2 физ машины и роунд-робином в днс по имени vpn.lan разбросать юзеров. Вариант 2 - ( который сейчас работает и работает стабильно ) - на каждой физ машине стоит цитрикс ксен 6.0, на каждой машине по 4 виртуалки с выделенными каждой по 2 проца, остальное поровну. Получается всего 8 впн серверов. Каждая ВМ загружена в среднем на 20-27%%. Каждая ВМ обслуживает 100-180 абонентов. Я не берусь делать выводы что лучше что хуже. Машины запущены недавно и явных выводов пока не буду делать. Один из явных плюсов, который я вижу уже сейчас - если упадёт одна из ВМ, только 12,5% народа реконнектом улетит на другие машины. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 29 декабря, 2011 · Жалоба Как показывает опыт, падает не виртуальная, а реальная машина. Так что сразу 4 виртуали в аут снесет... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 29 декабря, 2011 (изменено) · Жалоба Вариант 1 - просто сделать 2 физ машины и роунд-робином в днс по имени vpn.lan разбросать юзеров. Вариант 2 - ( который сейчас работает и работает стабильно ) - на каждой физ машине стоит цитрикс ксен 6.0, на каждой машине по 4 виртуалки с выделенными каждой по 2 проца, остальное поровну. Получается всего 8 впн серверов. Каждая ВМ загружена в среднем на 20-27%%. Каждая ВМ обслуживает 100-180 абонентов. Что-то вы того. Делитесь контактами ваших поставщиков, ибо трава ядреная. Зачем эти приколы с виртуалками в _Вашем_ случае? Как правильно выше сказали, стабильно работающая система может склеить ласты только по вине железа либо шаловливых ручек. И от первого и от второго никакая виртуализация не спасет. Опять же, каждая система виртуализации отжирает некоторую часть ресурсов хост системы под свои нужды, и гость ни при каких условиях не получит 100% ресурсов хоста. И чем больше гостей запущено, тем бОльшая доля ресурсов впустую тратится на их обслуживание, В результате вы просто так греете воздух. Ну, и натить непосредственно на BRAS'е это тоже подвиг, ждущий своего поэта. Изменено 29 декабря, 2011 пользователем taf_321 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
220B Опубликовано 30 декабря, 2011 · Жалоба Холивары тут не уместны. По сути заданных вопросов пожалуйста. p.s. 1) всё ещё актуально. если кто избавлялся от лавины этих сообщений, жду совета. 2) сделал пока "костыль", объединив LACP бондингом по два интерфейса, но производительность каждой сетевой остаётся скромная. 3) нашел причину крахов ipfw - наш биллинг банально таки совал по одному тарифному плану в скорость именно "0" - пофиксили - наблюдаем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 17 октября, 2012 · Жалоба После небольшого гугления ( у меня просто все сервера на фре - линух немного подзабыл ) - думаю, дело в параметре HZ .... у меня ядро дефолтное с параметром 100 Пересборка ядра помогла. Так? CONFIG_HZ_1000=y CONFIG_NO_HZ=y Или что-то ещё? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...