[Zohan]

Кто-нибудь использует его в паблике?

 

Поставил на Убунту 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

 

 

никто с таким не встречался?

 

 

[t00r]

Господа, подскажите - поставил в тесте данную связку. 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

[t00r]

После небольшого гугления ( у меня просто все сервера на фре - линух немного подзабыл ) - думаю, дело в параметре HZ .... у меня ядро дефолтное с параметром 100

p.s. наврал - по дефолту там 250

Изменено 8 декабря, 2011 пользователем t00r

[t00r]

Да. Пересборка ядра помогла. Замечу, что нат был собран не на физике, а на цитрикс ксене. В итоге я получил на 8 ядрах 4 нат машины. По 2 ядра на каждой. Так как сетевухи мы прибиваем к ядрам, то производительность 1 физической машине на 4 виртуалках по 2 ядра на каждой выросла реально. Ща погоняю за выходные и могу дать конфиги.

ОСь - убунта с ядром 2.6.32.46+drm33.20, родной iptables и порт ipfw+dummynet

На одной физической машине живет сеть из 3200 юзеров. Тесты скорости в пик отдают всё ровно по тарифу.

[t00r]

Нагруз на бордере за которой стоит это все можно смотреть тут http://109.197.112.1/graphs/iface/ether1-fortex/

С новым ядром ксен заработал где-то в 12 утра - это видно по графику.

[220B]

Роутер: 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

[kayot]

Какие занимательные извращения :)

Родной tc работает стабильно как скала, с хеш-таблицами ресурсов потребляет минимум, трафика на нормальном железе жует сколько в интерфейсы влезет.

Конфиг для больших сетей получается конечно монструозным, но кому от этого хуже?

[taf_321]

Да пофиг на монструозность конфигов. Все равно они генерятся скриптами для скриптов и глазами в них никто не смотрит. Я долго понять не мог, если говорят за ipfw, то при чем тут линух? А оказывается это народ, вместо освоения стандартных и отлаженных инструментов играет в BSDM с кривыми портами из других систем.

[wtyd]

Да пофиг на монструозность конфигов. Все равно они генерятся скриптами для скриптов и глазами в них никто не смотрит. Я долго понять не мог, если говорят за ipfw, то при чем тут линух? А оказывается это народ, вместо освоения стандартных и отлаженных инструментов играет в BSDM с кривыми портами из других систем.

 

BSDM это типа игра слов/букв из BDSM и FreeBSD ? Надо запомнить ;-))).

 

Ну а вообще да, я с этой темы тоже офигел. Тут же ещё и виртуалки упоминались - очень неправдоподобным выглядит утверждение о получении выигрыша в производителдьности на виртуалках, виртуалки всегда проигрывают в производительности, просто их перетаскивать и бекапить удобнее, чем живые серверы.

 

Реально какая-то странная тема :-). BonDage Sado Mazo прям.

[mkc]

Тут же ещё и виртуалки упоминались - очень неправдоподобным выглядит утверждение о получении выигрыша в производителдьности на виртуалках, виртуалки всегда проигрывают в производительности, просто их перетаскивать и бекапить удобнее, чем живые серверы.

 

Я не утверждаю, что данное решение лучше или хуже. Дам просто пример. У меня есть 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% народа реконнектом улетит на другие машины.

[Hawk128]

Как показывает опыт, падает не виртуальная, а реальная машина. Так что сразу 4 виртуали в аут снесет...

[taf_321]

Вариант 1 - просто сделать 2 физ машины и роунд-робином в днс по имени vpn.lan разбросать юзеров.

Вариант 2 - ( который сейчас работает и работает стабильно ) - на каждой физ машине стоит цитрикс ксен 6.0, на каждой машине по 4 виртуалки с выделенными каждой по 2 проца, остальное поровну. Получается всего 8 впн серверов. Каждая ВМ загружена в среднем на 20-27%%. Каждая ВМ обслуживает 100-180 абонентов.

 

Что-то вы того. Делитесь контактами ваших поставщиков, ибо трава ядреная.

 

Зачем эти приколы с виртуалками в _Вашем_ случае? Как правильно выше сказали, стабильно работающая система может склеить ласты только по вине железа либо шаловливых ручек. И от первого и от второго никакая виртуализация не спасет.

 

Опять же, каждая система виртуализации отжирает некоторую часть ресурсов хост системы под свои нужды, и гость ни при каких условиях не получит 100% ресурсов хоста. И чем больше гостей запущено, тем бОльшая доля ресурсов впустую тратится на их обслуживание, В результате вы просто так греете воздух.

 

Ну, и натить непосредственно на BRAS'е это тоже подвиг, ждущий своего поэта.

Изменено 29 декабря, 2011 пользователем taf_321

[220B]

Холивары тут не уместны. По сути заданных вопросов пожалуйста.

 

p.s.

1) всё ещё актуально. если кто избавлялся от лавины этих сообщений, жду совета.

2) сделал пока "костыль", объединив LACP бондингом по два интерфейса, но производительность каждой сетевой остаётся скромная.

3) нашел причину крахов ipfw - наш биллинг банально таки совал по одному тарифному плану в скорость именно "0" - пофиксили - наблюдаем.

[Ilya Evseev]

После небольшого гугления ( у меня просто все сервера на фре - линух немного подзабыл ) - думаю, дело в параметре HZ .... у меня ядро дефолтное с параметром 100

Пересборка ядра помогла.

Так?

CONFIG_HZ_1000=y

CONFIG_NO_HZ=y

 

Или что-то ещё?