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

Высокая нагрузка на проц FreBSD 8-PF-ALTQ помогите разобраться!

Уважаемые ГУРУ!

Долго бьюсь с проблемой, читал много тем с форума и инета, не могу победить свой сервачок:

Стоит две сетевушки em0 (alias vlan700) и em1 (alias vlan250)

На vlan700 - транспорт до всех 3750, на vlan250 - куча реальных адресов/32 маске (алиасами) - транспорт на бордер

Задача сервера: шейпинг и НАТ для небольшого количества трафика (около 120 Мбит)

Все клиенты терминируются на 3750, предоставляется влан-на-абонента (opt82, dhcp-snooping). На сервер долетают пакеты с серыми адресами, попадают в НАТ, и режутся altq.

 

При включенном net.isr.direct=1 возникает

# netstat -w1 -i vlan250
            input        (Total)           output
   packets  errs      bytes    packets  errs      bytes colls
      9971   242    5081867       9385     0    5042877     0
      9906   197    5141062       9237     0    5120116     0
      9837   161    4993819       9042     0    4976199     0
     10107   419    5337893       9334     0    5291947     0
      9809   223    4874975       9165     0    4874842     0
      9854   310    5190356       9036     0    5076692     0
      9868   177    5270392       9192     0    5171840     0
      9646   272    4920796       8871     0    4879827     0

 

У юзеров тормозят странички web конечно ЖУТКО.

 

При net.isr.direct=0 Пакеты не выпадают:

# netstat -w1 -i vlan250
            input        (Total)           output
   packets  errs      bytes    packets  errs      bytes colls
     12887     0    5156078      12058     0    5408769     0
     12709     0    5135044      12014     0    5260029     0
     12640     0    5214073      11876     0    5294148     0
     12466     0    5166291      11604     0    5114483     0
     12675     0    5223386      12075     0    5583122     0
     12728     0    5379418      11923     0    5396520     0
     12865     0    5499945      12081     0    5491322     0

 

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

# ping 10.11.10.49
PING 10.11.10.49 (10.11.10.49): 56 data bytes
64 bytes from 10.11.10.49: icmp_seq=0 ttl=64 time=473.065 ms
64 bytes from 10.11.10.49: icmp_seq=1 ttl=64 time=445.350 ms
64 bytes from 10.11.10.49: icmp_seq=2 ttl=64 time=465.794 ms
64 bytes from 10.11.10.49: icmp_seq=3 ttl=64 time=474.941 ms

 

 

Вот кусочек конфига для трех клиентов:

set skip on lo0
set block-policy return
set optimization normal
set limit { states 300000, frags 600000 }
set limit table-entries 600000

altq on vlan700 cbq bandwidth 10240000Kb queue { inqueue }
altq on vlan250 cbq bandwidth 10240000Kb queue { inqueue }
queue inqueue bandwidth 100% cbq(default) {\
user1, \
user2, \
user3 \
}
queue user1 bandwidth 2048Kb
queue user2 bandwidth 2048Kb
queue user3 bandwidth 1024Kb

nat on vlan250 inet from { 172.16.16.0/23, 172.16.18.0/23 } to any -> realIP/28 source-hash

pass quick from 172.16.20.4 to any queue  user1
pass quick from any to 172.16.20.4 queue  user1
pass quick from 172.16.20.3 to any queue  user2
pass quick from any to 172.16.20.3 queue  user2
pass quick from 172.16.8.40 to any queue  user3
pass quick from any to 172.16.8.40 queue  user3

 

Нагрузка на проц с net.isr.direct=0:

last pid:  1288;  load averages:  0.48,  0.84,  0.69                                                                                                
114 processes: 6 running, 87 sleeping, 21 waiting
CPU 0:  3.7% user,  0.0% nice, 12.4% system,  0.0% interrupt, 83.9% idle
CPU 1:  2.6% user,  0.0% nice,  3.4% system, 39.6% interrupt, 54.3% idle
CPU 2:  0.0% user,  0.0% nice,  0.0% system, 98.1% interrupt,  1.9% idle
CPU 3:  0.7% user,  0.0% nice, 10.5% system,  0.0% interrupt, 88.8% idle
Mem: 25M Active, 12M Inact, 144M Wired, 504K Cache, 30M Buf, 1791M Free
Swap: 4096M Total, 4096M Free

  PID USERNAME  PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   12 root      -44    -     0K   352K CPU2    2  62:50 94.92% {swi1: netisr 0}
   11 root      171 ki31     0K    64K RUN     0  56:05 93.41% {idle: cpu0}
   11 root      171 ki31     0K    64K CPU3    3  54:01 90.87% {idle: cpu3}
   11 root      171 ki31     0K    64K CPU1    1  57:25 56.10% {idle: cpu1}
  886 nobody     48    0  8016K  3680K select  0   7:45  7.81% softflowd
    0 root      -68    0     0K   128K -       0  10:37  5.52% {em1 taskq}
  884 nobody     47    0  8016K  3608K select  1   4:21  4.88% softflowd
   11 root      171 ki31     0K    64K RUN     2  11:12  2.29% {idle: cpu2}
   12 root      -32    -     0K   352K WAIT    1   5:57  0.10% {swi4: clock}
    0 root      -68    0     0K   128K -       3  17:20  0.00% {em0 taskq}
   12 root      -68    -     0K   352K WAIT    1   1:34  0.00% {irq258: bge0}
   13 root      -16    -     0K    16K -       1   0:09  0.00% yarrow
    7 root       44    -     0K    16K pftm    1   0:07  0.00% pfpurge
  578 root       44    0 14736K  4556K select  1   0:03  0.00% ospfd
  689 root       44    0 24308K  6360K select  0   0:03  0.00% snmpd
  983 root       44    0 17708K  5820K wait    1   0:02  0.00% mc
  966 ex         44    0 45280K  6300K select  1   0:01  0.00% sshd
  412 _pflogd    44    0  7080K  1716K bpf     3   0:01  0.00% pflogd
   12 root      -32    -     0K   352K WAIT    0   0:00  0.00% {swi4: clock}
    3 root       -8    -     0K    16K -       1   0:00  0.00% g_up
    2 root       -8    -     0K    16K -       0   0:00  0.00% g_event
    4 root       -8    -     0K    16K -       3   0:00  0.00% g_down
   12 root      -32    -     0K   352K WAIT    0   0:00  0.00% {swi4: clock}
   18 root       44    -     0K    16K syncer  0   0:00  0.00% syncer
  601 root       44    0  5864K  1500K select  1   0:00  0.00% syslogd
   12 root      -32    -     0K   352K WAIT    0   0:00  0.00% {swi4: clock}
   21 root       44    -     0K    16K flowcl  3   0:00  0.00% flowcleaner
   14 root      -64    -     0K   512K -       0   0:00  0.00% {usbus4}
   14 root      -64    -     0K   512K -       3   0:00  0.00% {usbus7}
   14 root      -64    -     0K   512K -       0   0:00  0.00% {usbus3}
   14 root      -64    -     0K   512K -       0   0:00  0.00% {usbus0}
   14 root      -64    -     0K   512K -       0   0:00  0.00% {usbus5}
   14 root      -64    -     0K   512K -       0   0:00  0.00% {usbus6}
   12 root      -64    -     0K   352K WAIT    0   0:00  0.00% {irq14: ata0}
   14 root      -64    -     0K   512K -       0   0:00  0.00% {usbus2}

 

Куда рыть?! Может я PF неправильно конфигурю?

Edited by ex-transfer

Share this post


Link to post
Share on other sites
перенеси всё на dummynet, и забудь про pf

я наоборот с dummynet'а перенес все на pf (это нелегкого стоило, т.к. написать скрипт автодобавления юзера в pf в разы сложнее чем в ipfw)

параллельный вопрос: как бороться с задержками в dummynet с маленькими скоростями в pipe? Если это можно решить - перейду на ipfw. Но дело кроется не в нем, по-моему

Share this post


Link to post
Share on other sites

А что за "маленькие скорости" в dummynet?

Общие рекомендации - используй one_pass, таблицы ну и GRED наше всё.

 

 

Share this post


Link to post
Share on other sites
перенеси всё на dummynet, и забудь про pf

я наоборот с dummynet'а перенес все на pf (это нелегкого стоило, т.к. написать скрипт автодобавления юзера в pf в разы сложнее чем в ipfw)

параллельный вопрос: как бороться с задержками в dummynet с маленькими скоростями в pipe? Если это можно решить - перейду на ipfw. Но дело кроется не в нем, по-моему

PF использует глобальные блокировки и фактически получается однопоточным.

Насколько маленькие скорости в pipe?

Как тут правильно посоветовали gred и подбор размера очереди под требуемую скорость. Вот не плохая мурзилка http://osboy.blog.ru/33351283.html по данному вопросу для начала.

Edited by XeonVs

Share this post


Link to post
Share on other sites

GRED -- далеко не самое главное. Обладатели Cisco SCE вообще полисинг делают, и юзеры не жалуются. Важно, чтобы для классификации трафика использовались хэши на основе пользовательских IP-адресов. В ipfw это реализуется динамическими пайпами или правилом вида pipe tablearg. Примеры легко найти на данном форуме. В противном случае, каждый пакет будет пробегать тысячи правил, и процессорное время будет расходоваться так же неоптимально, как в pf/ALTQ. Кроме того, в ipfw меньше проблем с гигантскими блокировками, чем в pf.

Edited by photon

Share this post


Link to post
Share on other sites
А что за "маленькие скорости" в dummynet?

Общие рекомендации - используй one_pass, таблицы ну и GRED наше всё.

"Маленькие" - это до 1024 кбита, (слава аллаху, что сейчас тарифы с такими скоростями уже не существуют, но вот пример такого тарифа, у него задержки были около 400мс):

ipfw add 228 pipe 228 ip from any to 172.16.5.2 in via vlan190                                                                                                                   
ipfw add 229 pipe 229 ip from 172.16.5.2 to any in via vlan700                                                                                                                   
ipfw pipe 228 config bw 128Kbit/s queue 100                                                                                                                                      
ipfw pipe 229 config bw 128Kbit/s queue 100

 

ONE_PASS - я так понимаю, опция в ядре должна быть?

Можно рабочий пример для GRED например для скорости 2Мбита?

И нужны ли тонкие настройки в самой ФРЕ? Я имею в виду тонкий тюнинг сетевой подсистемы для IPFW ?

 

p.s. вообще спасибо всем за комменты и советы. Начинаю заново "знакомиться" с IPFW

Edited by ex-transfer

Share this post


Link to post
Share on other sites
А что за "маленькие скорости" в dummynet?

Общие рекомендации - используй one_pass, таблицы ну и GRED наше всё.

"Маленькие" - это до 1024 кбита, (слава аллаху, что сейчас тарифы с такими скоростями уже не существуют, но вот пример такого тарифа, у него задержки были около 400мс):

ipfw add 228 pipe 228 ip from any to 172.16.5.2 in via vlan190                                                                                                                   
ipfw add 229 pipe 229 ip from 172.16.5.2 to any in via vlan700                                                                                                                   
ipfw pipe 228 config bw 128Kbit/s queue 100                                                                                                                                      
ipfw pipe 229 config bw 128Kbit/s queue 100

 

ONE_PASS - я так понимаю, опция в ядре должна быть?

Можно рабочий пример для GRED например для скорости 2Мбита?

И нужны ли тонкие настройки в самой ФРЕ? Я имею в виду тонкий тюнинг сетевой подсистемы для IPFW ?

 

p.s. вообще спасибо всем за комменты и советы. Начинаю заново "знакомиться" с IPFW

one-pass sysctl переменная net.inet.ip.fw.one_pass

 

Правильно что большие задержки, очередь-то здоровая.

для 128к и 100мсек. будет примерно так: queue 8 gred 0.002/1/2/0.1

 

 

как-то так:

ipfw table 10 flush
ipfw table 10 add 172.16.5.2/32 28
ipfw table 10 add 172.16.5.3/32 29
.....
.....

ipfw table 11 flush
ipfw table 11 add 172.16.5.2/32 228
ipfw table 11 add 172.16.5.3/32 229
....
....


ipfw pipe 28 config queue 32 bw 1Mbit/s mask dst-ip 0xffffffff gred 0.002/8/16/0.1
ipfw pipe 228 config queue 32 bw 1Mbit/s mask src-ip 0xffffffff gred 0.002/8/16/0.1
ipfw pipe 29 config queue 68 bw 2Mbit/s mask dst-ip 0xffffffff gred 0.002/17/34/0.1
ipfw pipe 229 config queue 68 bw 2Mbit/s mask src-ip 0xffffffff gred 0.002/17/34/0.1

ipfw add 705 pipe tablearg ip from any to "table(10)" out xmit vlan0
ipfw add 705 pipe tablearg ip from "table(11)" to any in recv vlan0

Edited by XeonVs

Share this post


Link to post
Share on other sites

XeonVs

Огромное спасибо за примерчик! Уже начитался про ipfw table, пора приниматься за практическое применение. Ядро пересобрал с поддержкой dummynet.

На pf наверное оставлю только НАТ, ipfw - только шейперство. ПОсмотрим на результаты... Сегодня-завтра-отпишусь

Share this post


Link to post
Share on other sites
XeonVs

Огромное спасибо за примерчик! Уже начитался про ipfw table, пора приниматься за практическое применение. Ядро пересобрал с поддержкой dummynet.

На pf наверное оставлю только НАТ, ipfw - только шейперство. ПОсмотрим на результаты... Сегодня-завтра-отпишусь

лучше вообще убрать(разделить функционал по разным машинкам) pf, если не нужны его специфичные фичи. ipfw nat справится.
Edited by XeonVs

Share this post


Link to post
Share on other sites
XeonVs

Огромное спасибо за примерчик! Уже начитался про ipfw table, пора приниматься за практическое применение. Ядро пересобрал с поддержкой dummynet.

На pf наверное оставлю только НАТ, ipfw - только шейперство. ПОсмотрим на результаты... Сегодня-завтра-отпишусь

лучше вообще убрать(разделить функционал по разным машинкам) pf, если не нужны его специфичные фичи. ipfw nat справится.

Я тоже так думаю, сервачок под выделенный НАТ уже в пути ))

Юзеров-то у нас всего ~2000

Share this post


Link to post
Share on other sites

XeonVs

непонятно, зачем Вы в конфиге заполняете таблицы с различными скоростями для юзеров в рамке одной таблицы?

ipfw table 10 add 172.16.5.2/32 28
ipfw table 10 add 172.16.5.3/32 29

Последнее число, как я понял из man'а - это указатель к какой pipe привязать?

Share this post


Link to post
Share on other sites

Ну это просто пример асимметричного шэйпинга 1/2Mbps

Последнее число - пресловутый tablearg, оч. полезная вещь, и не только в pipe/queue

Edited by Deac

Share this post


Link to post
Share on other sites
Я тоже так думаю, сервачок под выделенный НАТ уже в пути ))

Юзеров-то у нас всего ~2000

На такое количество клиентов и 100mbps должно хватить одного сервера ipfw+dummynet+netflow+pfnat.

Второй сервер здесь может быть нужен только на тот случай, если первый сломается.

Share this post


Link to post
Share on other sites
Я тоже так думаю, сервачок под выделенный НАТ уже в пути ))

Юзеров-то у нас всего ~2000

На такое количество клиентов и 100mbps должно хватить одного сервера ipfw+dummynet+netflow+pfnat.

Второй сервер здесь может быть нужен только на тот случай, если первый сломается.

Оттестировал! Пока ни потерь, ни тормозов в web.

Во:

shapper# netstat -w1 -i vlan250
            input        (Total)           output
   packets  errs      bytes    packets  errs      bytes colls
      9732     0    6562222       9512     0    6788224     0
     10069     0    6829139       9872     0    7066174     0
     10139     0    6874054       9609     0    7108733     0
     10681     0    7467601      10785     0    7717429     0
      9715     0    6521394       9613     0    6771326     0
      9750     0    6626889       9690     0    6842818     0
     10779     0    7062299      10567     0    7291172     0
     10229     0    7091838       9824     0    7313028     0
     10097     0    7003873       9935     0    7216538     0
     10401     0    6977869      10325     0    7234084     0

Скорости режутся практически идеально. Нагрузка на процы менее 15% !!!

last pid: 39061;  load averages:  0.08,  0.17,  0.15                                                                                                     up 0+23:34:47  17:02:21
138 processes: 5 running, 107 sleeping, 26 waiting
CPU 0:  2.6% user,  0.0% nice,  5.3% system, 14.9% interrupt, 77.2% idle
CPU 1:  2.6% user,  0.0% nice,  5.3% system,  0.9% interrupt, 91.2% idle
CPU 2:  2.6% user,  0.0% nice,  1.8% system,  1.8% interrupt, 93.9% idle
CPU 3:  0.0% user,  0.0% nice,  4.4% system,  0.0% interrupt, 95.6% idle
Mem: 39M Active, 201M Inact, 330M Wired, 296K Cache, 213M Buf, 1403M Free
Swap: 4096M Total, 4096M Free

  PID USERNAME  PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   11 root      171 ki31     0K    64K CPU1    1  20.7H 97.85% {idle: cpu1}
   11 root      171 ki31     0K    64K CPU3    3  19.4H 95.36% {idle: cpu3}
   11 root      171 ki31     0K    64K CPU2    2  19.7H 87.35% {idle: cpu2}
   11 root      171 ki31     0K    64K RUN     0  18.4H 86.13% {idle: cpu0}
   12 root      -44    -     0K   416K WAIT    1 455:00  6.69% {swi1: netisr 0}
    0 root       45    0     0K   176K WAIT    2  52:43  1.66% {em1_rx_0}
  905 nobody     46    0  8016K  3684K select  1  94:07  1.51% softflowd
  903 nobody     45    0  8016K  3648K select  0  84:54  1.51% softflowd
    0 root       45    0     0K   176K WAIT    1  49:03  1.17% {em0_rx_1}
    0 root       45    0     0K   176K WAIT    3  49:31  0.93% {em0_rx_0}
    0 root       45    0     0K   176K WAIT    1  52:28  0.78% {em1_rx_1}
   12 root      -32    -     0K   416K WAIT    2  21:12  0.10% {swi4: clock}
    0 root      -68    0     0K   176K -       2  41:29  0.00% {dummynet}
   12 root      -68    -     0K   416K WAIT    0  13:11  0.00% {irq258: bge0}
   12 root       16    -     0K   416K WAIT    2   5:18  0.00% {swi16: em0_tx}
   12 root       16    -     0K   416K WAIT    1   4:49  0.00% {swi16: em1_tx}

 

Тестю дальше, на нагрузке поболее....

Share this post


Link to post
Share on other sites

Толи ещё будет, у Луиджи там "планов громадьё", пока правда больше ломает чем строит. :)

 

Share this post


Link to post
Share on other sites
ipfw table 10 flush

ipfw pipe 28 config queue 32 bw 1Mbit/s mask dst-ip 0xffffffff gred 0.002/8/16/0.1
ipfw pipe 228 config queue 32 bw 1Mbit/s mask dst-ip 0xffffffff gred 0.002/8/16/0.1
ipfw pipe 29 config queue 68 bw 2Mbit/s mask dst-ip 0xffffffff gred 0.002/17/34/0.1
ipfw pipe 229 config queue 68 bw 2Mbit/s mask dst-ip 0xffffffff gred 0.002/17/34/0.1

ipfw add 705 pipe tablearg ip from any to "table(10)" out xmit vlan0
ipfw add 705 pipe tablearg ip from "table(11)" to any in recv vlan0

Только для труб 228 и 229 dst сменить на src .... :) А то шейпиться будет не скорость от клиента, а скорость _к_ www.microsoft.com

Share this post


Link to post
Share on other sites

ГУРУ, вопрос может и глубый, но как вы пропускаете в инет ТОЛЬКО юзеров из таблиц, а остальных рубите?

У меня не выходит каменный цветок. Ткните кусочком конфига

Share this post


Link to post
Share on other sites

Не использовать IPFIREWALL_DEFAULT_TO_ACCEPT

уже убрал ) хана халявщикам!

Share this post


Link to post
Share on other sites
Не использовать IPFIREWALL_DEFAULT_TO_ACCEPT
Это очень и очень глупо. Особенно если сервер где то там куда надо добираться.

Лучше one pass 1 и правила 65533 65534 запрещающие все что не попало выше в клиентских сетях

 

Share this post


Link to post
Share on other sites

Ознакомься что делает вышеуказанная опция.

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

Все контролируемые мной сервера более или менее удалены, некоторые больше чем на 100км.

Есть общепринятые правила внесения изменений в файервол, читай маны, доки, материала достаточно и обязательно обкатывай всё на стенде.

Если уж чувствуешь свою неготовость - имей "удалённые руки".

 

Share this post


Link to post
Share on other sites
Ознакомься что делает вышеуказанная опция.

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

Все контролируемые мной сервера более или менее удалены, некоторые больше чем на 100км.

Есть общепринятые правила внесения изменений в файервол, читай маны, доки, материала достаточно и обязательно обкатывай всё на стенде.

Если уж чувствуешь свою неготовость - имей "удалённые руки".

Указанная функция включает правило по умолчанию 65535 deny from any to any

По остальному если ты такой идеальный что никогда не катаешься за 100 км потому что "ой все пропало" я тебе завидую

А у меня например биллинг управляет правилами ipfw и ежедневно необходимо добавлять изменять общие правила а иногда и обновлять систему. А после обновления может оказаться что синтаксис в rc.firewall самую чуточку изменился а net.inet.ip.fw.enable 1

У меня лично валидола бы не хватило так работать с сервером за 100 км.

Edited by denis_vid

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this