dummynet загрузка 100%

[manpac]

FreeBSD 7.1-RELEASE-p3, MPD 5.2, Dell PowerEdge 1800(2xXeon DP 2.8Ghz, 2Gb Ram, 2xIntel Pro 1000 ). Онлайн 300-400.

Ядро собрано с

options IPFIREWALL
options DUMMYNET
options HZ=1000

Такие правила IPFW:

pipe 1 config bw 8192Kbits queue 20
queue 1 config pipe 1 weight 50 queue 20 mask dst-ip 0xffffffff #in
queue 11 config pipe 1 weight 50 queue 20 mask src-ip 0xffffffff #out
add 10 allow ip from any to any via lo0
add 20 deny ip from any to 127.0.0.0/8
add 30 deny ip from 127.0.0.0/8 to any
add 40 deny udp from any to me 53
add 41 queue 11 ip from 172.16.200.0/23 to any out via em1
add 50 divert natd ip from any to 91.x.x.x in via em1
add 60 divert natd ip from 172.16.0.0/16 to any via em1
add 61 queue 1 ip from any to 172.16.200.0/23 in via em1
add 70 allow all from any to me
add 80 allow all from me to any
add 90 allow ip from table(1) to any
add 91 allow ip from any to table(1)
add 64000 allow gre from any to any
add 65500 deny ip from any to any

 

в top`e dymmynet загружает на 100% один из процов и система начинает лагать (виснет MPD и прочие радости), при отключении очередей и пайпов все норм. В чем может быть проблема?

[kaN5300]

Переходите на ng_car для шейпинга/полисинга, иначе будете продолжать терять клиентов ИМХО.

[Giga-Byte]

Переходите на ng_car для шейпинга/полисинга, иначе будете продолжать терять клиентов ИМХО.

:)

 

В чем может быть проблема?

автор, глубокое изучение freebsd поможет...

не бойтесь экспериментировать, без этого не получится

1) не пытайтесь шейпить входящий трафик.

он пришел, ничего с ним не сделать, лучше пропустить его (вообще in) и зафильтровать на выходе

2) попробуйте/проведите эксперимент с RED/GRED (random early detection), может, чего-нибудь получится

 

[manpac]

Переходите на ng_car для шейпинга/полисинга, иначе будете продолжать терять клиентов ИМХО.

Так в MPD передаются через биллинг радиус-параметры) Нужно было просто всех таких безлимитчиков (c адресами из сети 172.16.200.0/23) не выпускать за пределы 8 мбитного канала

 

[bsdelnik]

Переходите на ng_car для шейпинга/полисинга, иначе будете продолжать терять клиентов ИМХО.

Насколько я понимаю, на ng_car надо для каждого абонента создавать свою ноду. А если абонентов 10 тысяч?

[IvanI]

20 000 записей в мускуле.

[bsdelnik]

20 000 записей в мускуле.

Что вы имели в виду?

[photon]

NAT лучше делать подсистемами ядра ng_nat или pf, а не демоном natd. При использовании natd происходит дополнительное копирование трафика из ядра в userland. Ядро желательно собрать с опцией DEVICE_POLLING, если пакетрейты большие, то включить polling на сетевухах. Кроме того, проблема может быть в большом количестве одновременных queue. Прежде всего нужно изменить следующие sysctl-переменные:

 

# чтобы в памяти могло одновременно храниться много queue

net.inet.ip.dummynet.max_chain_len = 1024

# режим шейпинга вместо эмуляции медленного соединения

net.inet.ip.dummynet.io_fast = 1

 

ng_car ограничивает скорость на интерфейсе (реальном или виртуальном), а не распределяет полосу поровну между разными IP, поэтому в данном случае он не поможет.

Edited April 15, 2009 by photon

[IvanI]

20 000 записей в мускуле.

Что вы имели в виду?

mpd+ng_car по радиусу получает не только разрешение на соединение но и данные для шейпера - 2 строки.

 

Если включить полинг то на 1 ядро ляжет все сетевое, что не есть гуд.

[photon]

Если включить полинг то на 1 ядро ляжет все сетевое, что не есть гуд.

Откуда такие сведения? Код поллинга MP-safe, причем даже начиная с каких-то версий FreeBSD 6-й ветки. Я лично юзал поллинг на 4-ядерной машине, все параллелилось нормально.

[jab]

Если включить полинг то на 1 ядро ляжет все сетевое, что не есть гуд.

Откуда такие сведения? Код поллинга MP-safe, причем даже начиная с каких-то версий FreeBSD 6-й ветки. Я лично юзал поллинг на 4-ядерной машине, все параллелилось нормально.

top -S не покажете ?

[photon]

Не могу, т.к. не работаю больше там, где юзал такое. Проблемы с SMP у polling точно были во времена 5-й ветки, но в 6-й уже починили.

Edited April 15, 2009 by photon

[jab]

 

Тогда не рассказывайте сказок на ночь. :-)

[photon]

Polling начиная с версий 6.x избавили от giant lock. С другой стороны, интеловские сетевухи и без поллинга должны справляться. Узкое место здесь в основном natd и недонастроенный dummynet.

Edited April 15, 2009 by photon

[jab]

Polling начиная с версий 6.x избавили от giant lock. С другой стороны, интеловские сетевухи и без поллинга должны справляться. Узкое место здесь в основном natd и недонастроенный dummynet.

:-) Сетевухи должны справляться с чем ? Вы беретесь лечить подземный стук. Не зная потоков, типа сетевух, конфигурации.

[IvanI]

Откуда такие сведения? Код поллинга MP-safe, причем даже начиная с каких-то версий FreeBSD 6-й ветки. Я лично юзал поллинг на 4-ядерной машине, все параллелилось нормально.

Вы просто полинг забыли включить на сетевухах (раньше полинг включался тока в ядре а ща в ядре и на сетевухах) :)

[photon]

Поллинг был включен и в ядре, и на сетевухах через ifconfig. Соберите у себя ядро с SMP и DEVICE_POLLING и попробуйте сами. В 5.x ядро не собиралось

если эти опции включены одновременно, нужно было подправлять systm.h, а в 6.x уже и собиралось и работало.

Edited April 16, 2009 by photon

[photon]

:-) Сетевухи должны справляться с чем ? Вы беретесь лечить подземный стук. Не зная потоков, типа сетевух, конфигурации.

Что вы цепляетесь к словам? Лучше научитесь читать. Он же пишет 2xIntel Pro 1000, т.е. это драйвер em(4). 300-400 юзеров online -- значит пакетрейты около 10 kpps, если он конечно не несколько сотен мегабит раздает всем остальным. Для гигабитных сетевух и драйвера с поддержкой interrupt mitigation это ерунда.

Edited April 16, 2009 by photon

[IvanI]

Соберите у себя ядро с SMP и DEVICE_POLLING и попробуйте сами

На боевых серверах freebsd 6.2 полинг выключил и свершилось чудо(производительность увеличилась в 2-4 раза)

[IvanI]

Без полинга speedtest.net 73.94 Mb/s 41.79 Mb/s 5 ms Khimki ~ 50 km

last pid: 99993;  load averages:  0.98,  0.93,  0.86             up 7+01:44:23  12:24:53
75 processes:  5 running, 56 sleeping, 14 waiting
CPU states:  1.0% user,  0.0% nice,  2.5% system, 21.7% interrupt, 74.7% idle
Mem: 35M Active, 120M Inact, 318M Wired, 199M Buf, 1532M Free
Swap: 4096M Total, 4096M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   10 root        1 171   52     0K     8K RUN    3 150.5H 84.77% idle: cpu3
   11 root        1 171   52     0K     8K CPU2   2 147.6H 82.13% idle: cpu2
   16 root        1 -44 -163     0K     8K WAIT   0  94.4H 74.61% swi1: net
   12 root        1 171   52     0K     8K CPU1   1 134.7H 66.75% idle: cpu1
   13 root        1 171   52     0K     8K CPU0   0 104.2H 59.91% idle: cpu0
   22 root        1 -68 -187     0K     8K WAIT   0 376:40  5.27% irq16: em0
   23 root        1 -68 -187     0K     8K WAIT   1 308:45  4.35% irq17: em1
   14 root        1 -32 -151     0K     8K WAIT   0 654:08  0.93% swi4: clock
  574 root        7  20    0 29452K 19920K kserel 2  23.2H  0.00% mpd4
   28 root        1 -68    0     0K     8K -      0  37:41  0.00% dummynet
   17 root        1  96    0     0K     8K -      1  23:50  0.00% yarrow

 

С полингом speedtest.net 28.11 Mb/s 32.18 Mb/s 5 ms Khimki ~ 50 km

last pid:   139;  load averages:  1.10,  0.98,  0.88                    up 7+01:48:01  12:28:31
74 processes:  6 running, 54 sleeping, 14 waiting
CPU states:  0.7% user,  0.0% nice,  3.2% system, 12.8% interrupt, 83.4% idle
Mem: 35M Active, 120M Inact, 318M Wired, 199M Buf, 1532M Free
Swap: 4096M Total, 4096M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   10 root        1 171   52     0K     8K RUN    3 150.6H 91.06% idle: cpu3
   11 root        1 171   52     0K     8K CPU2   2 147.6H 90.92% idle: cpu2
   12 root        1 171   52     0K     8K CPU1   1 134.8H 90.58% idle: cpu1
   16 root        1 -44 -163     0K     8K WAIT   2  94.5H 52.88% swi1: net
   13 root        1 171   52     0K     8K RUN    0 104.2H 44.97% idle: cpu0
   14 root        1 -32 -151     0K     8K WAIT   1 654:28  0.10% swi4: clock
  574 root        6  20    0 29452K 19912K kserel 2  23.3H  0.00% mpd4
   22 root        1 -68 -187     0K     8K WAIT   0 376:44  0.00% irq16: em0
   23 root        1 -68 -187     0K     8K WAIT   1 308:48  0.00% irq17: em1
   28 root        1 -68    0     0K     8K -      1  37:42  0.00% dummynet
   17 root        1  96    0     0K     8K -      3  23:50  0.00% yarrow
  517 root        1  96    0  1404K  1064K select 1  14:27  0.00% syslogd
   35 root        1  20    0     0K     8K syncer 0  10:02  0.00% syncer
   34 root        1  -4    0     0K     8K vlruwt 3   4:33  0.00% vnlru
1183 dhcpd       1  96    0  6900K  6592K select 1   4:22  0.00% dhcpd
   33 root        1 -16    0     0K     8K psleep 3   3:32  0.00% bufdaemon
    4 root        1  -8    0     0K     8K -      3   1:08  0.00% g_down

 

Фря 6.2, тунели шифрованые, тесты с обычного клиентского PPTP speedtest.net на сервер Khimki.

slave# ifconfig | grep -c ffffffff
497
slave# netstat -w 1 -I vlan41
            input       (vlan41)           output
   packets  errs      bytes    packets  errs      bytes colls
      5940     0    4871528       5332     0    2479313     0
      6157     0    5117026       5430     0    2402921     0
      6188     0    5509599       5296     0    2338552     0
      5827     0    5013961       5212     0    2381451     0
      6037     0    5110621       5360     0    2417038     0

 

П.С. на 7.1 производительность в 2-3 раза выше

Edited April 16, 2009 by IvanI

[Giga-Byte]

Переходите на ng_car для шейпинга/полисинга, иначе будете продолжать терять клиентов ИМХО.

Насколько я понимаю, на ng_car надо для каждого абонента создавать свою ноду. А если абонентов 10 тысяч?

тогда ставят Juniper || Cisco || RedBack || etc...

а не FreeBSD на одной машине

Edited April 16, 2009 by Giga-Byte

[jab]

С полингом speedtest.net 28.11 Mb/s 32.18 Mb/s 5 ms Khimki ~ 50 km

:-) Настраивать polling не пробовали ?

[IvanI]

Пробовали - настроен.

Нагрузка поднялась и пришлось отказаться от полинга

[jab]

Пробовали - настроен.

Нагрузка поднялась и пришлось отказаться от полинга

Сомневаюсь что настроен. У меня 6.2-STABLE с polling выдает 800Mbits in+ 800Mbits out при полном pfnat + full view BGP. Суммарно 230kpps, 250kstates.

 

Без polling выдает на 5% больше, но начинаются спецэффекты при выжирании одного ядра кернельным тредом.

[manpac]

Нашел в этой ветке что то похожее, оказывается проблема распространена

Edited April 16, 2009 by manpac