Перейти к содержимому
Калькуляторы

Умирает FreeBSD шейпер с ipfw ...при загрузке ~40kpps на сетевуху

Доброго времени суток, уважаемые!

Мой сервачок что-то совсем захворал..

При трафике порядка ~230 мбит загибаются процы под 100%.

Сетевые потоки {emX_rx_X} прибиты к процам. По два потока(in/out) на проц. Дамминет прибит к одному процу, но всё равно жрёт 100%...

Плюс ко всему этому иногда (раз в две недели) сервак ещё и зависает намертво сволочь. Температура в норме.. память проверял.

Начитался много всего, если честно уже полная каша в голове.

Вот например вчерашний случай: сервак после загрузки ночных таблиц в память (в 9 вечера, удвоение скорости) поработал под нагрузкой 100% и завис.

Нагрузка на один из процов:

0f5655f07623.jpg

PPS на одной из карточек (сторона юзеров):

881efd52301d.jpg

Трафик на ней же:

5a8b52bf5d46.jpg

И немного ната (pf):

bbbd26b89bb9.jpg

 

Недавно перевели 99% пользователей на реальные ипишники (динамика с пулов dhcp), в таблицах теперь короткие записи вида:

ipfw table 70 add xx.xx.xx.xx/25  70 
ipfw table 40 add xx.xx.xx.xx/25  40

и т.д..

 

В глобальном конфиге ipfw тоже ничего особенного нет (но хз, может и есть). Вот кусочек для 3х мегабит например:

#== 3 Mbit pipe
ipfw pipe 70 config queue 74 bw 3145728bit/s mask dst-ip 0xffffffff gred 0.002/34/75/0.1
ipfw pipe 40 config queue 74 bw 3145728bit/s mask src-ip 0xffffffff gred 0.002/34/75/0.1

 

# === 3 Mbit
ipfw add 15000 pipe tablearg ip from any to "table(70)" out xmit vlan700
ipfw add 15000 pipe tablearg ip from "table(40)" to any in recv vlan700

 

ipfw add 20120 allow ip from any to "table(70)"..
ipfw add 20130 allow ip from "table(40)" to any.

 

Стоит HP DL180G5 1хXeon 5405 + две внешние карты 82572EI PRO/1000 PT Desktop Adapter (em)

яндекс-драйверы...

 Intel(R) PRO/1000 Network Connection 6.9.14.Yandex[$Revision: 1.36.2.17.2.6 $]

тюнинга не много

dev.em.0.rx_int_delay=750
dev.em.0.tx_int_delay=750
dev.em.0.rx_abs_int_delay=1500
dev.em.0.tx_abs_int_delay=1500
dev.em.1.rx_int_delay=750
dev.em.1.tx_int_delay=750
dev.em.1.rx_abs_int_delay=1500
dev.em.1.tx_abs_int_delay=1500
dev.em.0.rx_processing_limit=1024
dev.em.1.rx_processing_limit=1024

net.isr.direct=1
net.isr.direct_force=1

net.inet.ip.dummynet.io_fast=1
net.inet.ip.fw.one_pass=1
net.inet.ip.dummynet.hash_size=1024
net.inet.ip.dummynet.io_fast=1

dev.em.0.rx_kthreads=4
dev.em.1.rx_kthreads=4

 

Если надо ещё что-нить показать, выложу!

Помогите разобраться с нагрузкой!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Чем фильтруются пакеты: ipfw или pf?

В таблицы добавляете по /25, т.к. каждая /25 подсеть используется для своего тарифа?

Т.к. net.inet.ip.fw.one_pass=1 , то до правила 20120 дело не доходит.

Изменено пользователем John_obn

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Чем фильтруются пакеты: ipfw или pf?

В таблицы добавляете по /25, т.к. каждая /25 подсеть используется для своего тарифа?

Т.к. net.inet.ip.fw.one_pass=1 , то до правила 20120 дело не доходит.

Пакеты фильтруются ipfw

Да, каждая /25 подсеть под свой тариф.

До правила 20120 доходит, т.к. под ним есть правила что все те сети что не в таблицах - в режект.

И если вдруг я забыл какую-то сеть вписать, юзеры сидят бкз инета.

Изменено пользователем ex-transfer

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В pf точно ничего не осталось кроме nat? pfctl -sr подтверждает ?

dummynet к какому ядру прибит?

Изменено пользователем John_obn

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ничегошеньки. Вот:

shapper# pfctl -sr
no scrub all
pass all no state

 

По дамминету - который грузил проц на 100% возможно что разобрался сам. Я его почему-то прибивал к 1-му ядру. Прибил к 0-му, он стал жрать... 0% . Наверное какоя бага или фича самого дамминета.

Посмотрим сегодня что ночью произойдёт, когда все хомяки будут за компами и начнуть грузить канал.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

flowtable из ядра выкинуто?

Изменено пользователем vurd

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

flowtable из ядра выкинуто?

нет, не выкинуто. если выкинуть, то какие изменения будут?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо за ссылочки, очень полезные!

В моём случае дело было в следующем:

после 9ти вечера загружался фаер pf с правилами запрета всяких icmp и другой ерунды, касающихся dos атак. В дневном конфиге этого не было в принципе.

После чистки конфига pf от фильтров icmp, и прибития процесса dummynet к нулевому ядру:

[CPU]

0f7ab4811c36.jpg

[PPS]

e0fe74fbeb88.jpg

[Trafic]

593868bfa1a5.jpg

 

Т.е. фактически нагрузка спала в два раза, но, боюсь, и ЭТА нагрузка великовата.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

перейти на ipfw nat/ng_nat.очень помогает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

перейти на ipfw nat/ng_nat.очень помогает.

у меня не ipfw nat, a pf... и не на ng* надо переходить, а вообще искоренять его к чертям ))) именно поэтому почти все хомяки теперь сидят на белых IP. Остались только те рудименты, которые сидят на древних pppoe (cisco 28хх). И их в скором будущем тоже переведу на белые. Кстати, nat-states в потолке 20к... могут ли они пожрать все процы до 50% ?

 

to Vurd:

начитался про flowtable. пока решил его выключить через sysctl. Посмотрим что изменится. Если будет лучше - выкину из ядра.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ipfw nat/ng_nat уже умеют в пул адресов натить?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@ex-transfer

ipfw nat,ng_nat очен лехко работоет в сравнение с пф нат.пф на фрее тежолое работоет,ето не опенбсд.Но пф/нат болше функционал.

У меня ето плохая машина (гигадерево) на ~6xx усера и 3хх/М


#options        INET6                   # IPv6 communications protocols
#options        SCTP                    # Stream Control Transmission Protocol
#options        FLOWTABLE       

########## IPFW/Dummynet
options  IPFIREWALL
options  IPFIREWALL_VERBOSE
options  IPFIREWALL_VERBOSE_LIMIT=0
options  IPFIREWALL_FORWARD
options  IPFIREWALL_DEFAULT_TO_ACCEPT
options  IPFIREWALL_NAT
options  LIBALIAS
options  DUMMYNET
options  ROUTETABLES=8
options  SW_WATCHDOG
#options  ZERO_COPY_SOCKETS
options  NETGRAPH
options  NETGRAPH_BPF
options  NETGRAPH_IFACE
options  NETGRAPH_KSOCKET
options  NETGRAPH_IPFW
options  NETGRAPH_SOCKET
options  NETGRAPH_NETFLOW
options  NETGRAPH_ETHER
options  NETGRAPH_NAT
options  NETGRAPH_TEE
options  NETGRAPH_CAR
options  NETGRAPH_SPLIT

#options  NETGRAPH_PPPOE
#options  NETGRAPH_PPP
#options  NETGRAPH_PPTPGRE
#options  NETGRAPH_L2TP
#options  NETGRAPH_MPPC_ENCRYPTION
#options  NETGRAPH_TCPMSS
#options  NETGRAPH_CISCO
#options  NETGRAPH_ECHO
#options  NETGRAPH_FRAME_RELAY
#options  NETGRAPH_HOLE
#options  NETGRAPH_LMI
#options  NETGRAPH_RFC1490
#options  NETGRAPH_TTY
#options  NETGRAPH_ASYNC
#options  NETGRAPH_UI
#options  NETGRAPH_VJC

# vlan
device vlan

# lagg
device lagg



[/core# sysctl -a | egrep -i 'hw.machine|hw.model|hw.ncpu'
hw.machine: i386
hw.model: Intel(R) Pentium(R) D CPU 3.00GHz
hw.ncpu: 2
hw.machine_arch: i386

core# top -SPH
91 processes:  4 running, 64 sleeping, 23 waiting
CPU 0:  0.0% user,  0.0% nice,  1.1% system, 31.5% interrupt, 67.4% idle
CPU 1:  0.0% user,  0.0% nice,  1.1% system, 29.6% interrupt, 69.3% idle
Mem: 19M Active, 298M Inact, 189M Wired, 32K Cache, 112M Buf, 1483M Free
Swap: 4043M Total, 4043M Free

 PID USERNAME PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
  11 root     171 ki31     0K    16K RUN     1 171.6H 75.88% {idle: cpu1}
  11 root     171 ki31     0K    16K RUN     0 172.8H 72.85% {idle: cpu0}
  12 root     -68    -     0K   192K WAIT    1  32.9H 25.59% {irq261: em1}
  12 root     -68    -     0K   192K CPU0    0  31.3H 24.27% {irq256: em0}
  12 root     -68    -     0K   192K WAIT    0 230:12  3.08% {irq262: em1}
  12 root     -68    -     0K   192K WAIT    1 223:49  2.78% {irq257: em0}
   0 root     -68    0     0K   136K -       1  91:22  0.39% {em1 txq}
   0 root     -68    0     0K   136K -       0  74:08  0.29% {em0 txq}
  12 root     -32    -     0K   192K WAIT    0  66:05  0.00% {swi4: clock}

 

@Dyr

Я незнаю ето,никогда не попробовал. У меня нат на аккцесах а там линукси.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ipfw nat/ng_nat уже умеют в пул адресов натить?

нет. не умеет.

надо явно указывать правила.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ipfw nat,ng_nat очен лехко работоет в сравнение с пф нат.

У меня получилось наоборот - при переходе с ng_nat на pfnat производительность выросла.

В ipfw остались фильтрация и шейпинг через dummynet.

 

Кроме того, существенно упростились правила ipfw - при использовании natd/ngnat/libalias

постоянно приходилось учитывать, прошёл ли уже пакет на внешнем интерфейсе входящий-исходящий NAT.

iptables в Линуксе в этом смысле устроен разумнее - фильтрация и nat изначально разнесены по разным таблицам.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@Ilya

А попробовал ли ipfw nat ?

Каки трафици/пакети у тебя и на какое железо/драйвер тестировал.

pf плохо распределяет нагрузку у меня.

Когда я юзал,ipfw nat работал болше леько и быстро как пфнат.

Сначало поллинг помогал но когда трафика выростил 3хх/м лаг и дроп пояивился ( на BCM5721).

Убрал поллинг,интел картички 82574L поставил и проблем решил.

 

@Dyr

Можно попробоеш с аласи но там долго будеш писат,кривая работа будет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2Ilya Evseev А какие у вас были трансляции? /24 -> /32 на ng_nat и /24 -> /24 на pfnat? Это существенный момент. Производительность растет прямо пропорционально отношению транслируемого префикса к внешним адресам.

 

На сколько я помню pfnat работает на одном ядре. Pf нравится самим конфигом, но тут уж надо выбирать или шашечки, или ехать.

Вопрос о том может ли ipfw nat натить в пул адресов не существенный, ибо можно написать скрипт который раскидает транслируемую подсеть по внешним адресам как вам нужно.

Я вот спрыгнул с ng_nat-а на ipfw nat только из-за конфигов, всё таки в ng_ уж очень через задницу всё; в итоге расписал скриптами трансляцию /16 -> /24 и сижу улыбаюсь.

 

p.s. Для ipfw nat

Изменить размер буфера в /usr/src/sys/netinet/ip_fw.h
#define NAT_BUF_LEN     64*1024

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Разницы между ipfw nat, ng_nat, natd почти нет, они libalias based, разница лишь в интерфейсах управления и путях попадания в них трафика. pf nat - совершенно отдельная реализация nat.

 

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

в итоге расписал скриптами трансляцию /16 -> /24 и сижу улыбаюсь.

 

не покажете?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

в итоге расписал скриптами трансляцию /16 -> /24 и сижу улыбаюсь.

 

не покажете?

 

Да тут ничего сверхъестественного нет :)

Это конечно не настоящий пул в его понимании, а статическая имитация.

 

#Some variables
IP123="XXX.YYY.ZZZ"		<- 3 первых байта внешних адресов (99.124.65)
GRAYIP="XXX.YYY"		<- 2 первых байта серой подсети (172.16)
OUT_VLAN="vlanX"		<- Выходной интерфейс (vlan99)
NATBASE=1000			<- База для нумерации правил в ipfw (1000 + последний байт внешнего адреса)

#Network::ifaces->routed NAT pool at loopback
IP4=1
while [ $IP4 -le 254 ]
do
   /sbin/ifconfig lo0 add $IP123.$IP4/32
   IP4=`expr $IP4 + 1`
done

#Ipfw::NAT config
IP4=1
while [ $IP4 -le 254 ]
do
   NATNUM=`expr $NATBASE + $IP4`
   /sbin/ipfw nat $NATNUM config ip $IP123.$IP4 reset unreg_only same_ports deny_in
   IP4=`expr $IP4 + 1`
done

#Ipfw::NAT rules
IP4=1
SEGIP3=0
while [ $IP4 -le 254 ]
do
   NATNUM=`expr $NATBASE + $IP4`
   /sbin/ipfw add 3$NATNUM nat $NATNUM ip from $GRAYIP.$SEGIP3.0/24 to any out via $OUT_VLAN
   /sbin/ipfw add 3$NATNUM nat $NATNUM ip from any to $IP123.$IP4 in via $OUT_VLAN
   IP4=`expr $IP4 + 1`
   SEGIP3=`expr $SEGIP3 + 1`
done

 

p.s. комментарии по говнокоду приветствуются.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ifconfig lo0

 

действительно нужен?

 

У меня ng_nat и ипов не навешиваю. Вроде работает

 

кстати, еще вопрос созрел, по ipfw nat

 

ipfw add 1000 nat tablearg ... from table(20)....

 

Сработает?

Если да то правила ipfw в предыдущем скрипте резко сократить можно.

 

Минус цикл в скрипте. (кстати у вас три одинаковых цикла, можно наверно в одном пройти)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

без lo0 работает..

у меня так:

nat tablearg ip4 from table(50) to any out xmit vlan905
nat tablearg ip4 from any to table(60) in recv vlan905

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вместо навешивания на lo0 айпишников лучше использовать route add -net ваша_сеть -blackhole. Если только, конечно, вы таким навешиванием не решаете для себя вопрос динамического определения nat-серверов с редистрибьюцией в OSPF.

 

andriko, а ICMP у вас так в nat заходят?

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

P.S. У меня на машинке с PF NAT, ng_netflow и ipfw для шейпинга вечером стабильно упирается в процессор (Core2Duo):

 


#netstat -i -I vlan3050 -dh 1
           input     (vlan3050)           output
  packets  errs idrops      bytes    packets  errs      bytes colls drops
      34K     0     0        17M        37K     0        33M     0     0
      36K     0     0        20M        38K     0        36M     0     0
      35K     0     0        19M        36K     0        34M     0     0




#pfctl -si
No ALTQ support in kernel
ALTQ related functions disabled
Status: Enabled for 111 days 12:55:41         Debug: Urgent

State Table                          Total             Rate
 current entries                   109343
 searches                    702647959654        72911.9/s
 inserts                      22637460908         2349.0/s
 removals                     22637351565         2349.0/s
Counters
 match                        36217355225         3758.2/s
 bad-offset                             0            0.0/s
 fragment                         2538584            0.3/s
 short                             380565            0.0/s
 normalize                         268628            0.0/s
 memory                                 0            0.0/s
 bad-timestamp                          0            0.0/s
 congestion                             0            0.0/s
 ip-option                        2261588            0.2/s
 proto-cksum                      5092401            0.5/s
 state-mismatch                  34002155            3.5/s
 state-insert                          52            0.0/s
 state-limit                            0            0.0/s
 src-limit                        5719293            0.6/s
 synproxy                               0            0.0/s





#top -aSCHIP

last pid: 89186;  load averages:  2.16,  2.14,  2.23                                                                                up 111+12:55:27 19:44:05
115 processes: 6 running, 94 sleeping, 15 waiting
CPU 0:  0.0% user,  0.0% nice, 98.2% system,  0.0% interrupt,  1.8% idle
CPU 1:  0.0% user,  0.0% nice, 99.1% system,  0.9% interrupt,  0.0% idle
Mem: 42M Active, 3098M Inact, 612M Wired, 600K Cache, 418M Buf, 190M Free
Swap: 1024M Total, 1024M Free

 PID USERNAME      PRI NICE   SIZE    RES STATE   C   TIME    CPU COMMAND
   0 root          -68    0     0K   128K RUN     0 911.9H 83.79% {em0 taskq}
   0 root          -68    0     0K   128K -       1 873.3H 82.76% {em1 taskq}
   0 root          -68    0     0K   128K CPU0    0 319.1H 23.68% {dummynet}
  11 root          -32    -     0K   256K RUN     0  52.9H  1.76% {swi4: clock}
  10 root          171 ki31     0K    32K RUN     0 1570.3  0.20% {idle: cpu0}


 

 

Шейпинг отключаешь - трафик возрастает раза в три, но тоже затыкается:

 


netstat -i -I vlan3050 -dh 1
           input     (vlan3050)           output
  packets  errs idrops      bytes    packets  errs      bytes colls drops
      51K     0     0        24M        67K     0        75M     0     0
      49K     0     0        22M        67K     0        77M     0     0
      52K     0     0        22M        71K     0        79M     0     0
      48K     0     0        22M        65K     0        73M     0     0
      50K     0     0        23M        67K     0        77M     0     0
      50K     0     0        24M        67K     0        74M     0     0
      50K     0     0        23M        67K     0        76M     0     0
^C

last pid: 89358;  load averages:  2.35,  2.21,  2.24                                                                                up 111+12:58:15 19:46:53
115 processes: 8 running, 91 sleeping, 16 waiting
CPU 0:  0.0% user,  0.0% nice, 78.3% system,  0.0% interrupt, 21.7% idle
CPU 1:  0.0% user,  0.0% nice,  100% system,  0.0% interrupt,  0.0% idle
Mem: 42M Active, 3098M Inact, 612M Wired, 600K Cache, 418M Buf, 190M Free
Swap: 1024M Total, 1024M Free

 PID USERNAME      PRI NICE   SIZE    RES STATE   C   TIME    CPU COMMAND
   0 root          -68    0     0K   128K CPU1    1 911.9H 100.00% {em0 taskq}
   0 root          -68    0     0K   128K -       0 873.3H 80.18% {em1 taskq}
  10 root          171 ki31     0K    32K RUN     0 1570.3 23.58% {idle: cpu0}
  11 root          -32    -     0K   256K WAIT    0  52.9H  1.66% {swi4: clock}




pfctl -si
No ALTQ support in kernel
ALTQ related functions disabled
Status: Enabled for 111 days 12:58:22         Debug: Urgent

State Table                          Total             Rate
 current entries                   106670
 searches                    702680919454        72914.1/s
 inserts                      22637729678         2349.0/s
 removals                     22637623008         2349.0/s
Counters
 match                        36234158096         3759.9/s
 bad-offset                             0            0.0/s
 fragment                         2538586            0.3/s
 short                             380565            0.0/s
 normalize                         268628            0.0/s
 memory                                 0            0.0/s
 bad-timestamp                          0            0.0/s
 congestion                             0            0.0/s
 ip-option                        2261624            0.2/s
 proto-cksum                      5092674            0.5/s
 state-mismatch                  34003285            3.5/s
 state-insert                          52            0.0/s
 state-limit                            0            0.0/s
 src-limit                        5719293            0.6/s
 synproxy                               0            0.0/s

 

И как назло, из ядра убрал hwpc-интерфейс профайлера, так что и модуль не подгрузить :(

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Гм, забавно.

 

Нашёл клиента, у которого сходу аж 17000 сессий (по pfctl -sS) было. Стоило его ограничить с помощью ipfw до "src-addr 50", нагрузка резко (хоть и не принципиально) снизилась:

 


last pid: 89796;  load averages:  1.36,  1.39,  1.76                                                                                up 111+13:11:35 20:00:13
115 processes: 3 running, 96 sleeping, 16 waiting
CPU 0:  1.5% user,  0.0% nice, 67.7% system,  0.4% interrupt, 30.5% idle
CPU 1:  0.4% user,  0.0% nice, 77.1% system,  2.6% interrupt, 19.9% idle
Mem: 42M Active, 3044M Inact, 602M Wired, 34M Cache, 418M Buf, 220M Free
Swap: 1024M Total, 1024M Free

 PID USERNAME      PRI NICE   SIZE    RES STATE   C   TIME    CPU COMMAND
   0 root          -68    0     0K   128K -       1 912.1H 83.50% {em0 taskq}
   0 root          -68    0     0K   128K -       0 873.5H 71.39% {em1 taskq}
  10 root          171 ki31     0K    32K CPU0    0 1570.3 28.47% {idle: cpu0}
  10 root          171 ki31     0K    32K RUN     1 1566.9 18.55% {idle: cpu1}




# netstat -i -I vlan3050 -dh 1
           input     (vlan3050)           output
  packets  errs idrops      bytes    packets  errs      bytes colls drops
      56K     0     0        30M        67K     0        74M     0     0
      56K     0     0        29M        70K     0        75M     0     0
      56K     0     0        30M        69K     0        75M     0     0
      53K     0     0        28M        67K     0        73M     0     0


 

Зарезать всем, что ли, количество одновременных сессий...?

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.