[Wingman]

Помогите подтюнить, пожалуйста =)

 

Железо:

2x Intel® Xeon® CPU E5410 @ 2.33GHz (8 ядер)

Память: 8 гиг

Сеть: 2x pci-e 80003ES2LAN, e1000e.ko 0.3.3.4-k4

kernel-2.6.30-gentoo-r6 #4 SMP

accel-pptp-0.8.3

 

При 550-600 сессий и потоке трафика ~150 mbit/s (30-40 kpps всего!) подскакивают до 90-100% ksoftirqd, pptpctrl, events...

Игры с `ethtool -C ethX rx-usecx` позволили выиграть ещё с сотню сессий и с пяток кппс, но этого же один хрен ОЧЕНЬ МАЛО для такого монстра ;(

Что ещё комп напрягает - уже затрудняюсь придумать...

До этого эта же машинка натила и шейпила. Сейчас вынес нат и шейпер на отдельный сервант, Iptables на этом почти пустые:

 

# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

# iptables -L -n -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

# iptables -L -n -t mangle
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
MARK       all  --  93.ххх.ххх.0/22      0.0.0.0/0           MARK xset 0x2/0xffffffff
MARK       all  --  93.ххх.ххх.0/22      0.0.0.0/0           MARK xset 0x3/0xffffffff
MARK       all  --  93.ххх.ххх.0/22      0.0.0.0/0           MARK xset 0x3/0xffffffff

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

 

Из узких мест, по идее, остались только сам accel-pptp и небольшой advanced-routing: отправляет прямые ip в влан инета, и "кривые" на нат.

Всевозможные security в ядре поотрубал.

 

Подскажите, что ещё подкрутить, сейчас этот монстрилло работает всего лишь раза в полтора лучше полудесктопных core quad'ов с гигом памяти, аж обидно...

 

 

Update: сейчас заметил закономерность: загрузка (и скорость прокачки клиентом через серв) очень сильно падает, когда я добавляю сервер в днс (Юзеры конектятся к vpn.provider.net), и более-менее ровная и не совсем уж критическая, когда из днс я его убираю (хотя старые сессии остаются висеть и трафик не уменьшается). Может быть, конечно, показалось - мало времени наблюдал - но сейчас попробую поубирать из ip-up и ip-down вообще всё

Изменено 18 сентября, 2009 пользователем Wingman

[MagMike]

1. что показывает

cat  /proc/sys/net/ipv4/netfilter/ip_conntrack_count

если несколько десятков тысяч,

отключите conntrack (iptables -t raw -I PREROUTING -j NOTRACK) для тех соединений, для которых оно не нужно.

2. возможно, заменить сетевые на другие.

для примера. сетевая Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02)

и прием и передача сидят на одном прерывании.

           CPU0       CPU1       CPU2       CPU3
25: 2117329339 2117676851         74         67   PCI-MSI-edge      eth0

даже если распределить это прерывание на все процессоры, то как только обработка на 100% залезает в softirq, то ротация процессоров прекращается, обработкой занимается один процессор.

 

поставил двухпортовую E1G42ETBLK (Portville Dual) Intel® Gigabit ET Dual Port (lspci определяется как Intel Corporation 82576 Gigabit Network Connection)

модуль ядра - igb.

 

           CPU0       CPU1       CPU2       CPU3
25:  146799498   77439938   77302882   77399041   PCI-MSI-edge      eth0-tx-0
26:      62892     171260      59380      58811   PCI-MSI-edge      eth0-tx-1
27:      53266      49923     155849      50577   PCI-MSI-edge      eth0-tx-2
28:      64327      61636      61438     169610   PCI-MSI-edge      eth0-tx-3
29:   81686893   39032382   38255781   38252879   PCI-MSI-edge      eth0-rx-0
30:   36889519   81753409   36912858   36903842   PCI-MSI-edge      eth0-rx-1
31:   37431066   38242615   81572707   37441971   PCI-MSI-edge      eth0-rx-2
32:   37827197   38646325   37854640   82995494   PCI-MSI-edge      eth0-rx-3

т.е. в карточке по 4 очереди на прием и отправку. и каждая - своим прерыванием обрабатывается.

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

в итоге

250мбит, 38000 пакетов в секунду, softirq - примерно по 40-50% на каждом процессоре. остальное - idle.

на 82566DM-2 тоже было 100% softirq. 160мбит, 25000 пакетов/с.

[Wingman]

Собсно вопрос решился.. Контрак отключил, но главное - очистил ip-up и ip-down от всякого старого мусора (например, от `tc qdisc del dev ...` при подключении - сдуру изначально оставил такое, решив, что вреда не будет...

 

Ну так вот, такой производительности ВПН-а я ещё не видел! =) при 1000 сессий прокачивает ~350 мбит/с, 45 кппс, и процы просто отдыхают:

25686 root      20   0  3316 2072  900 R    2  0.0   0:01.02 top
    1 root      20   0  1676  580  508 S    0  0.0   0:00.78 init
    2 root      15  -5     0    0    0 S    0  0.0   0:00.00 kthreadd
    3 root      RT  -5     0    0    0 S    0  0.0   0:00.20 migration/0
    4 root      15  -5     0    0    0 S    0  0.0   5:25.65 ksoftirqd/0
    5 root      RT  -5     0    0    0 S    0  0.0   0:00.12 migration/1
    6 root      15  -5     0    0    0 S    0  0.0   4:42.38 ksoftirqd/1
    7 root      RT  -5     0    0    0 S    0  0.0   0:00.16 migration/2
    8 root      15  -5     0    0    0 S    0  0.0   5:07.36 ksoftirqd/2
...............

 

Моему счастью не было бы предела, если бы не одно но... Теперь всё упёрлось в BGP.

Там стоит четырех-ядерный комп, на котором только quagga и плоский роутинг. Прокачивает в сумме ~800 мбит с двух аплинков. С нагрузкой всё в порядке после аналогичных шаманств =) Но как-то так выходит, что БГП, похоже, не отдаёт слишком большую скорость на один и тот же IP. То есть, на ВПНе за натом скорость в лучшем случае мегабит 5-10, а при подключении с внешним ипом - 50-60 мбит/с... Ну и проблема не в нате как таковом, т.к. непосредственно с натящего сервера с внешней сетевухи скачка идёт с точно такой же скоростью.

 

Посоветуйте что-нибуть пожалуйста) sysctl где-то подкрутить надо, подозреваю? =)

[Wingman]

Мля мля мля!!

На серваке с натом сетевухи PCI, какая там проп. способность шины PCI? не 266 ли мбит/с? Щас как раз затык на 240-250 мбит + там харды всякие...

 

Ыыы, блин, если только в сетевках дело - я эту конструкцию доведу до 500 мбит-с с парой тысяч юзеров как минимум! =)))

 

ыыы /* убежал в щенячьем восторге :D */

Изменено 18 сентября, 2009 пользователем Wingman

[vitalyb]

Wingman

при 1000 сессий прокачивает ~350 мбит/с, 45 кппс, и процы просто отдыхают

не совсем правильно смотрите - надо смотреть загрузку цпу%, в частности si%. То, что в этих строках 0% - ничего не значит. Вот когда не 0 - тогда уже всё плохо.

 

Пропускная способность PCI, можно считать - гигабит, но общий на все устройсва, которые там висят. Периферия южного моста обычно не использует полосу внешней шины PCI. Другой вопрос что там за сетевухи.... если они, например, не offload'ят checksumming - то и на 200 мбитах всё остановится.

 

[Wingman]

мм...

Сетевушки там Intel 82540EM, e1000

[Cayz]

Прошу помощи.

Debian 4 Linux version 2.6.18-6-amd64, pptp-accel 0.8.3 в качестве pptp сервера

При подключении клиента к серверу всё проходит нормально, поднимается ppp интерфейс, но нормально это всё работает от нескольких секунд до не больше минуты. Перестаёт ходить трафик по туннелю. Если запустить пинг на стороне клиента и tcpdump-ом смотреть ppp интерфейс на стороне сервера, то видно, что на сервер приходят icmp echo request пакеты, но ответа там нет. В таком состоянии это может висеть несколько минут, после чего сессия рубится на стороне клиента (виндовый клиент сам каким-то образом решает, что пора рубить) или висит сколь-угодно долго если клиент pptp-linux.

На родном pptpd при тех же конфигах работает так как должно быть.

 

daemon.log

Sep 21 11:22:44 webserver pptpd[16360]: CTRL: Client 10.92.170.8 control connection started
Sep 21 11:22:44 webserver pptpd[16360]: CTRL: Starting call (launching pppd, opening GRE)
Sep 21 11:22:44 webserver pptp[16361]: Plugin pptp.so loaded.
Sep 21 11:22:44 webserver pptp[16361]: PPTP plugin version 0.8.3 compiled for pppd-2.4.4, linux-2.6.18
Sep 21 11:22:44 webserver pptp[16361]: pppd 2.4.4 started by root, uid 0
Sep 21 11:22:44 webserver pptp[16361]: using channel 55
Sep 21 11:22:44 webserver pptp[16361]: Using interface ppp0
Sep 21 11:22:44 webserver pptp[16361]: Connect: ppp0 <--> pptp (10.92.170.8)
Sep 21 11:22:44 webserver pptp[16361]: sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <auth chap MS-v2> <magic 0x7a6898a2> <pcomp> <accomp>]
Sep 21 11:22:44 webserver pptp[16361]: rcvd [LCP ConfReq id=0x0 <mru 1400> <magic 0x745c13f6> <pcomp> <accomp> <callback CBCP>]
Sep 21 11:22:44 webserver pptp[16361]: sent [LCP ConfRej id=0x0 <callback CBCP>]
Sep 21 11:22:44 webserver pptp[16361]: rcvd [LCP ConfReq id=0x1 <mru 1400> <magic 0x745c13f6> <pcomp> <accomp>]
Sep 21 11:22:44 webserver pptp[16361]: sent [LCP ConfAck id=0x1 <mru 1400> <magic 0x745c13f6> <pcomp> <accomp>]
Sep 21 11:22:47 webserver pptp[16361]: sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <auth chap MS-v2> <magic 0x7a6898a2> <pcomp> <accomp>]
Sep 21 11:22:47 webserver pptp[16361]: rcvd [LCP ConfAck id=0x1 <mru 1492> <asyncmap 0x0> <auth chap MS-v2> <magic 0x7a6898a2> <pcomp> <accomp>]
Sep 21 11:22:47 webserver pptp[16361]: sent [LCP EchoReq id=0x0 magic=0x7a6898a2]
Sep 21 11:22:47 webserver pptp[16361]: sent [CHAP Challenge id=0x91 <ccf496daae8df88a4df77d4b61af7a46>, name = "webserver"]
Sep 21 11:22:47 webserver pptpd[16360]: CTRL: Ignored a SET LINK INFO packet with real ACCMs!
Sep 21 11:22:47 webserver pptp[16361]: rcvd [LCP Ident id=0x2 magic=0x745c13f6 "MSRASV5.10"]
Sep 21 11:22:47 webserver pptp[16361]: rcvd [LCP Ident id=0x3 magic=0x745c13f6 "MSRAS-0-CAYZCOMP"]
Sep 21 11:22:47 webserver pptp[16361]: rcvd [LCP EchoRep id=0x0 magic=0x745c13f6]
Sep 21 11:22:47 webserver pptp[16361]: rcvd [CHAP Response id=0x91 <0668855b35309c01f2901a81bd23f7390000000000000000bf18492c01d41fae0e333ac8c13c
14cbc7ba5055ac26865d00>, name = "test1"]
Sep 21 11:22:47 webserver pptp[16361]: sent [CHAP Success id=0x91 "S=3A99F5A53ACF3BCC55030438718C96F4B65F21B5 M=Access granted"]
Sep 21 11:22:47 webserver pptp[16361]: sent [CCP ConfReq id=0x1 <mppe +H -M +S +L -D -C>]
Sep 21 11:22:47 webserver pptp[16361]: rcvd [CCP ConfReq id=0x4 <mppe +H +M +S +L -D +C>]
Sep 21 11:22:47 webserver pptp[16361]: sent [CCP ConfNak id=0x4 <mppe +H -M +S -L -D -C>]
Sep 21 11:22:47 webserver pptp[16361]: rcvd [IPCP ConfReq id=0x5 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
Sep 21 11:22:47 webserver pptp[16361]: sent [IPCP TermAck id=0x5]
Sep 21 11:22:47 webserver pptp[16361]: rcvd [CCP ConfNak id=0x1 <mppe +H -M +S -L -D -C>]
Sep 21 11:22:47 webserver pptp[16361]: sent [CCP ConfReq id=0x2 <mppe +H -M +S -L -D -C>]
Sep 21 11:22:47 webserver pptp[16361]: rcvd [CCP ConfReq id=0x6 <mppe +H -M +S -L -D -C>]
Sep 21 11:22:47 webserver pptp[16361]: sent [CCP ConfAck id=0x6 <mppe +H -M +S -L -D -C>]
Sep 21 11:22:47 webserver pptp[16361]: rcvd [CCP ConfAck id=0x2 <mppe +H -M +S -L -D -C>]
Sep 21 11:22:47 webserver pptp[16361]: MPPE 128-bit stateless compression enabled
Sep 21 11:22:47 webserver pptp[16361]: sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 192.168.10.1>]
Sep 21 11:22:47 webserver pptp[16361]: rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
Sep 21 11:22:47 webserver pptp[16361]: sent [IPCP ConfReq id=0x2 <addr 192.168.10.1>]
Sep 21 11:22:47 webserver pptp[16361]: rcvd [IPCP ConfAck id=0x2 <addr 192.168.10.1>]
Sep 21 11:22:48 webserver pptp[16361]: rcvd [IPCP ConfReq id=0x7 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
Sep 21 11:22:48 webserver pptp[16361]: sent [IPCP ConfRej id=0x7 <ms-dns1 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
Sep 21 11:22:48 webserver pptp[16361]: rcvd [IPCP ConfReq id=0x8 <addr 0.0.0.0>]
Sep 21 11:22:48 webserver pptp[16361]: sent [IPCP ConfNak id=0x8 <addr 192.168.10.10>]
Sep 21 11:22:48 webserver pptp[16361]: rcvd [IPCP ConfReq id=0x9 <addr 192.168.10.10>]
Sep 21 11:22:48 webserver pptp[16361]: sent [IPCP ConfAck id=0x9 <addr 192.168.10.10>]
Sep 21 11:22:48 webserver pptp[16361]: local  IP address 192.168.10.1
Sep 21 11:22:48 webserver pptp[16361]: remote IP address 192.168.10.10
Sep 21 11:22:48 webserver pptp[16361]: pptpd-logwtmp.so ip-up ppp0 test1 10.92.170.8
Sep 21 11:22:48 webserver pptp[16361]: Script /etc/ppp/ip-up started (pid 16379)
Sep 21 11:25:17 webserver pptp[16361]: No response to 4 echo-requests
Sep 21 11:25:17 webserver pptp[16361]: Serial link appears to be disconnected.
Sep 21 11:25:17 webserver pptp[16361]: pptpd-logwtmp.so ip-down ppp0
Sep 21 11:25:17 webserver pptp[16361]: Connect time 2.5 minutes.
Sep 21 11:25:17 webserver pptp[16361]: Sent 1697 bytes, received 75235 bytes.
Sep 21 11:25:17 webserver pptp[16361]: MPPE disabled
Sep 21 11:25:17 webserver pptp[16361]: sent [LCP TermReq id=0x2 "MPPE disabled"]
Sep 21 11:25:17 webserver pptp[16361]: sent [LCP TermReq id=0x3 "MPPE disabled"]
Sep 21 11:25:17 webserver pptp[16361]: rcvd [Compressed data] 91 59 81 b4 c1 1b 70 31 ...
Sep 21 11:25:17 webserver pptp[16361]: Discarded non-LCP packet when LCP not open
Sep 21 11:25:18 webserver pptp[16361]: rcvd [Compressed data] 91 5a 26 20 6d 2e 99 ac ...
Sep 21 11:25:18 webserver pptp[16361]: Discarded non-LCP packet when LCP not open
Sep 21 11:25:18 webserver pptp[16361]: rcvd [Compressed data] 91 5b 70 85 14 84 9b af ...
Sep 21 11:25:18 webserver pptp[16361]: Discarded non-LCP packet when LCP not open
Sep 21 11:25:19 webserver pptp[16361]: rcvd [Compressed data] 91 5c 14 ce 02 44 9b e9 ...
Sep 21 11:25:19 webserver pptp[16361]: Discarded non-LCP packet when LCP not open
Sep 21 11:25:19 webserver pptp[16361]: rcvd [Compressed data] 91 5d 36 20 f9 19 25 c1 ...
Sep 21 11:25:19 webserver pptp[16361]: Discarded non-LCP packet when LCP not open
Sep 21 11:25:19 webserver pptp[16361]: rcvd [Compressed data] 91 5e 18 e8 48 00 15 cer pptp[16361]: Discarded non-LCP packet when LCP not open
Sep 21 11:25:20 webserver pptp[16361]: rcvd [Compressed data] 91 5f 8f 31 5c 76 df 8b ...
Sep 21 11:25:20 webserver pptp[16361]: Discarded non-LCP packet when LCP not open
Sep 21 11:25:20 webserver pptp[16361]: sent [LCP TermReq id=0x4 "MPPE disabled"]
Sep 21 11:25:20 webserver pptp[16361]: Connection terminated.
Sep 21 11:25:20 webserver pptp[16361]: Modem hangup
Sep 21 11:25:20 webserver pptp[16361]: Waiting for 1 child processes...
Sep 21 11:25:20 webserver pptp[16361]:   script /etc/ppp/ip-up, pid 16379
Sep 21 11:25:25 webserver pptp[16361]: sending SIGTERM to process 16379
Sep 21 11:25:25 webserver pptp[16361]: Exit.
Sep 21 11:25:25 webserver pptpd[16360]: CTRL: Reaping child PPP[16361]
Sep 21 11:25:25 webserver pptpd[16360]: CTRL: Client pppd TERM sending
Sep 21 11:25:25 webserver pptpd[16360]: CTRL: Client pppd finish wait
Sep 21 11:25:25 webserver pptpd[16360]: CTRL: Client 10.92.170.8 control connection finished

 

pptpd-options

nodeflate
mtu 1492
mru 1492
auth
+mschap-v2
+mschap
+pap
+mppe
noproxyarp
#lock
nologfd
debug

Форум перечитывал, вроде проблемы такой не у кого не было, делал по readme, модуль ip_gre вырубил, пробовал без шифрования - результат не изменялся. Возможно что-то накосячил, но не могу увидеть в чём.

[Vitaly7777]

С чем может быть связана ошибка "CTRL: failed to connect PPTP socket (Operation already in progress)" ?

изредка возникает при использовании accel-pptpd, раньше не наблюдалась

Наблюдается такая же проблема. Соединения нет, а процесс остается. При повторной попытке подключиться - ошибка 800 и сообщение "CTRL: failed to connect PPTP socket (Operation already in progress)" в /var/log/messages

[maxxxxu]

кто-то собирал accel-pptp под 2.6.31 ядро?

выдает такие ошибки:

# make server

echo Building kernel module

Building kernel module

(cd kernel/driver; make )

make[1]: Entering directory `/mnt/sda9/source/accel-pptp-0.8.3/kernel/driver'

using "/usr/src/linux" kernel headers

make -C /usr/src/linux SUBDIRS=/mnt/sda9/source/accel-pptp-0.8.3/kernel/driver modules

make[2]: Entering directory `/usr/src/linux-2.6.31'

CC [M] /mnt/sda9/source/accel-pptp-0.8.3/kernel/driver/pptp.o

/mnt/sda9/source/accel-pptp-0.8.3/kernel/driver/pptp.c: In function 'pptp_xmit':

/mnt/sda9/source/accel-pptp-0.8.3/kernel/driver/pptp.c:386: error: 'struct sk_buff' has no member named 'dst'

/mnt/sda9/source/accel-pptp-0.8.3/kernel/driver/pptp.c:387: error: 'struct sk_buff' has no member named 'dst'

/mnt/sda9/source/accel-pptp-0.8.3/kernel/driver/pptp.c: In function 'pptp_rcv':

/mnt/sda9/source/accel-pptp-0.8.3/kernel/driver/pptp.c:551: error: 'struct sk_buff' has no member named 'dst'

/mnt/sda9/source/accel-pptp-0.8.3/kernel/driver/pptp.c:552: error: 'struct sk_buff' has no member named 'dst'

make[3]: *** [/mnt/sda9/source/accel-pptp-0.8.3/kernel/driver/pptp.o] Error 1

make[2]: *** [_module_/mnt/sda9/source/accel-pptp-0.8.3/kernel/driver] Error 2

make[2]: Leaving directory `/usr/src/linux-2.6.31'

make[1]: *** [all] Error 2

make[1]: Leaving directory `/mnt/sda9/source/accel-pptp-0.8.3/kernel/driver'

make: *** [module] Error 2

 

[XLighter]

xeb в курсе. Ждем. :)

[heap]

1. что показывает

cat  /proc/sys/net/ipv4/netfilter/ip_conntrack_count

если несколько десятков тысяч,

отключите conntrack (iptables -t raw -I PREROUTING -j NOTRACK) для тех соединений, для которых оно не нужно.

2. возможно, заменить сетевые на другие.

для примера. сетевая Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02)

и прием и передача сидят на одном прерывании.

           CPU0       CPU1       CPU2       CPU3
25: 2117329339 2117676851         74         67   PCI-MSI-edge      eth0

даже если распределить это прерывание на все процессоры, то как только обработка на 100% залезает в softirq, то ротация процессоров прекращается, обработкой занимается один процессор.

 

поставил двухпортовую E1G42ETBLK (Portville Dual) Intel® Gigabit ET Dual Port (lspci определяется как Intel Corporation 82576 Gigabit Network Connection)

модуль ядра - igb.

 

           CPU0       CPU1       CPU2       CPU3
25:  146799498   77439938   77302882   77399041   PCI-MSI-edge      eth0-tx-0
26:      62892     171260      59380      58811   PCI-MSI-edge      eth0-tx-1
27:      53266      49923     155849      50577   PCI-MSI-edge      eth0-tx-2
28:      64327      61636      61438     169610   PCI-MSI-edge      eth0-tx-3
29:   81686893   39032382   38255781   38252879   PCI-MSI-edge      eth0-rx-0
30:   36889519   81753409   36912858   36903842   PCI-MSI-edge      eth0-rx-1
31:   37431066   38242615   81572707   37441971   PCI-MSI-edge      eth0-rx-2
32:   37827197   38646325   37854640   82995494   PCI-MSI-edge      eth0-rx-3

т.е. в карточке по 4 очереди на прием и отправку. и каждая - своим прерыванием обрабатывается.

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

в итоге

250мбит, 38000 пакетов в секунду, softirq - примерно по 40-50% на каждом процессоре. остальное - idle.

на 82566DM-2 тоже было 100% softirq. 160мбит, 25000 пакетов/с.

Если удалось найти решение - поделитесь опытом. Тоже не могу понять:

сервер с двумя 4-х головыми ксеонами: Intel® Xeon® CPU E5410 @ 2.33GHz

Есть карточки встроенные: два порта Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12)

И не встроенные: двухпортовая Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)

Пара портов на входе (так как именно там было узкое место по процессору) собрана в bonding. Трафло распределяется между сетевыми в бондинге достаточно равномерно. Интерапты сетевых привязаны каждый к своему ядру процессора. Загрузка процессоров выше 50% не поднимается. При этом не могу потянуть сквозь пптп соединение даже 10 мбит. В пиках прыгает до десятки и сползает ниже.

 

В слову - используется НАТ и шейпинг при помощи tbf. Но на тестируемом интерфейсе прибивал все - а эффект тот же.

 

Чувствую, что нужно где-то покрутить sysctl, но пока не могу найти где. Может всезнающий ALL наставит на путь истинный. Ибо аналогично количество туннелей 500-800, трафик выше 250 мбит не поднимается, хотя по внешним данным запас по процессору есть, адаптеры тож далеки от своих пропускных способностей.

 

Заранее спасибо. Буду благодарен за любой пинок в верном направлении.

[Cayz]

Не всё сказал... Модуль для 2.6.18 в Debian не хотел подключаться, выдавал ошибку. Пересобрал ядро пропатчив прилагаемым патчем для 2.6.18, а в патче походу одна из предыдущих версий, модуль подключился, но работать не хотел. Сейчас воткнул ядро 2.6.26, пропатчил руками, всё заработало! Буду тестить.

Изменено 23 сентября, 2009 пользователем Cayz

[MagMike]

Загрузка процессоров выше 50% не поднимается.

как и чем смотрите? 50% - суммарная загрузка (то, что показывает vmstat) или через mpstat/top ?

 

[a0d75]

Сделайте пожалуйста нормальный ebuild версии 0.8.3 для генты.

[heap]

Загрузка процессоров выше 50% не поднимается.

как и чем смотрите? 50% - суммарная загрузка (то, что показывает vmstat) или через mpstat/top ?

В реальном времени htop или top. + Рисую rrd графики, собирая стат по mpstat. Забыл еще указать, что если на самом сервере запускаю wget - долбит десятки мегабит. А уже на клиенте без всяких шейперов со стороны сервера - болт. При запуске wget прыгает до порядка 10-12 мегабит и падает ниже восьми в среднем.

[xeb]

commit 69c0f151027d7a8fb872394e7c1062d9e402b5f4
Author: Kozlov Dmitry <dima@server>
Date:   Fri Sep 25 10:52:07 2009 +0400

    accel-pptp 0.8.4
    * supports 2.6.31 kernel
    * included 430-persist.patch (theMIROn)

[xeb]

Попытался заюзать бондинг для распараллеливания нагрузки по ядрам - в итоге получил при сравнительно низкой загрузке (до 30-40% на ядро) кучу следующих ошибок в логе клиента (классический поптоп):

Sep  6 13:32:35 NiTr0 pptp[24721]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 5974028 (expecting 5974027, lost or reordered)
(.....................)
Sep  6 13:32:35 NiTr0 pptp[24721]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 5974053 (expecting 5974027, lost or reordered)
Sep  6 13:32:35 NiTr0 pptp[24721]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 5974054 (expecting 5974027, lost or reordered)
Sep  6 13:32:36 NiTr0 pptp[24721]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 5974141 (expecting 5974140, lost or reordered)
Sep  6 13:32:36 NiTr0 pptp[24721]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 5974142 (expecting 5974140, lost or reordered)
(.....................)
Sep  6 13:32:36 NiTr0 pptp[24721]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 5974172 (expecting 5974140, lost or reordered)
Sep  6 13:32:36 NiTr0 pptp[24721]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 5974173 (expecting 5974140, lost or reordered)

Такое наблюдалось и до распараллеливания, но обычно не в таком количестве (хотя периодически были всплески потерь - чем обусловленные неизвестно). При этом скорость через туннель низкая, 5-10 мбит/сек...

Соответственно вопрос - кто съедает пакеты?

С бондингом нет никакого механизма, чтобы сохнанить порядок пакетов, судя по всему на это и ругается т.к. буферизировать и переупорядочивать, емнип, pptp не умеет. Подозреваю, балансировка у Вас на коммутаторе per-packet, а надо бы per-flow.

 

В крайнем случае можно поднять два pptpd - каждый на своем интерфейсе и балансировать DNS'ом.

механизм буферизации был исключен начиная с версии 0.8.2, если есть необходимость можно восстановить

Изменено 25 сентября, 2009 пользователем xeb

[xeb]

С чем может быть связана ошибка "CTRL: failed to connect PPTP socket (Operation already in progress)" ?

изредка возникает при использовании accel-pptpd, раньше не наблюдалась

Наблюдается такая же проблема. Соединения нет, а процесс остается. При повторной попытке подключиться - ошибка 800 и сообщение "CTRL: failed to connect PPTP socket (Operation already in progress)" в /var/log/messages

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

[xeb]

mtu 1492

mru 1492

возможно mtu слишком большой, поставь 1436, ну и mru соответсвенно

 

Не всё сказал... Модуль для 2.6.18 в Debian не хотел подключаться, выдавал ошибку. Пересобрал ядро пропатчив прилагаемым патчем для 2.6.18, а в патче походу одна из предыдущих версий, модуль подключился, но работать не хотел. Сейчас воткнул ядро 2.6.26, пропатчил руками, всё заработало! Буду тестить.

во-первых, патч для 2.6.18 уже морально устарел, это патч одной из первых версии accel-pptp, соответсвенно забагованный,

во-вторых, зачем ты 2.6.26 то патчишь ? модуль просто собирай и вперёд

[maxxxxu]

только 2 дня назад поставил 0.8.3 с ядром 2.6.29.6, т.к. с 2.6.31 не компилилось, но огромное спасибо за проделанную работу!

[heap]

Попытался заюзать бондинг для распараллеливания нагрузки по ядрам - в итоге получил при сравнительно низкой загрузке (до 30-40% на ядро) кучу следующих ошибок в логе клиента (классический поптоп):

Sep  6 13:32:35 NiTr0 pptp[24721]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 5974028 (expecting 5974027, lost or reordered)
(.....................)
Sep  6 13:32:35 NiTr0 pptp[24721]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 5974053 (expecting 5974027, lost or reordered)
Sep  6 13:32:35 NiTr0 pptp[24721]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 5974054 (expecting 5974027, lost or reordered)
Sep  6 13:32:36 NiTr0 pptp[24721]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 5974141 (expecting 5974140, lost or reordered)
Sep  6 13:32:36 NiTr0 pptp[24721]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 5974142 (expecting 5974140, lost or reordered)
(.....................)
Sep  6 13:32:36 NiTr0 pptp[24721]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 5974172 (expecting 5974140, lost or reordered)
Sep  6 13:32:36 NiTr0 pptp[24721]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 5974173 (expecting 5974140, lost or reordered)

Такое наблюдалось и до распараллеливания, но обычно не в таком количестве (хотя периодически были всплески потерь - чем обусловленные неизвестно). При этом скорость через туннель низкая, 5-10 мбит/сек...

Соответственно вопрос - кто съедает пакеты?

С бондингом нет никакого механизма, чтобы сохнанить порядок пакетов, судя по всему на это и ругается т.к. буферизировать и переупорядочивать, емнип, pptp не умеет. Подозреваю, балансировка у Вас на коммутаторе per-packet, а надо бы per-flow.

 

В крайнем случае можно поднять два pptpd - каждый на своем интерфейсе и балансировать DNS'ом.

механизм буферизации был исключен начиная с версии 0.8.2, если есть необходимость можно восстановить

Я думаю было бы полезно. Сам сейчас вкручиваю бондинг. Правда по принципу маков или айпишников, что не должно вносить реордеринга пакетов.

[a0d75]

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

Сервер HP DL140G6, (4-х ядерный Xeon 1.60GHz, 1гб памяти, 2 встроенные сетевые карты Broadcom). Ядро 2.6.30-gentoo-r6, accel-pptp-0.8.3, xl2tpd, ripd, ospfd. Шейпит (tbf на даунлоад), полисит (ingress на аплоад) и натит клиентов. В моменты пиковой загрузки (около 500 клиентов онлайн) результаты следующие:

 

cat /proc/net/stat/ipt_netflow
Flows: active 7762 (peak 13338 reached 0d0h27m ago), mem 424K
Hash: size 327680 (mem 1280K), metric 1.0, 1.0, 1.0, 1.0. MemTraf: 2063564 pkt, 1158998 K (pdu 23, 6773).
Timeout: active 300, inactive 15. Maxflows 2000000
Rate: 81307156 bits/sec, 18216 packets/sec; Avg 1 min: 80796299 bps, 18123 pps; 5 min: 78258431 bps, 17396 pps
...
top - 22:47:45 up 11:31,  3 users,  load average: 0.68, 0.44, 0.44
Tasks: 1168 total,   1 running, 1167 sleeping,   0 stopped,   0 zombie
Cpu0  :  3.0%us,  9.5%sy,  0.0%ni, 87.5%id,  0.0%wa,  0.0%hi,  0.0%si, 0.0%st
Cpu1  :  1.3%us,  1.3%sy,  0.0%ni, 97.4%id,  0.0%wa,  0.0%hi,  0.0%si, 0.0%st
Cpu2  :  1.7%us,  0.7%sy,  0.0%ni, 44.0%id,  0.0%wa,  3.0%hi, 50.7%si, 0.0%st
Cpu3  :  0.3%us,  0.3%sy,  0.0%ni, 56.7%id,  0.0%wa,  1.4%hi, 41.2%si, 0.0%st
Mem:   1034352k total,  1002720k used,    31632k free,    12412k buffers
Swap:  1003960k total,        0k used,  1003960k free,   680820k cached
...
vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
0  0      0  33640  12444 680820    0    0     1    34   43  233  2 14 83  0
0  0      0  33572  12444 680820    0    0     0    36 13870 2455  1 26 73  0
1  0      0  33396  12452 680812    0    0     0    84 15086 2342  0 24 74  2
1  0      0  32748  12452 680824    0    0     0    32 14136 2170  2 28 70  0
0  0      0  32748  12452 680824    0    0     0     8 14084 2470  0 26 74  0
0  0      0  32748  12452 680824    0    0     0    40 15297 2760  0 26 74  0
0  0      0  32748  12452 680824    0    0     0    24 14729 2794  1 24 75  0
1  0      0  32748  12460 680816    0    0     0    92 16449 2801  1 31 67  1
0  0      0  32748  12460 680824    0    0     0    20 15302 2717  1 25 73  0
0  0      0  32748  12460 680824    0    0     0    24 16310 2900  0 19 81  0

mpstat 1
Linux 2.6.30-gentoo-r6         28.09.2009      _i686_  (4 CPU)

22:48:22     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal %guest   %idle
22:48:23     all    1,25    0,00    0,75    1,50    1,00   28,82    0,00   0,00   66,67
22:48:24     all    0,51    0,00    0,77    0,00    0,26   24,30    0,00   0,00   74,17
22:48:25     all    0,25    0,00    0,50    0,00    1,01   24,62    0,00   0,00   73,62
22:48:26     all    0,50    0,00    0,50    0,00    0,99   21,84    0,00   0,00   76,18
22:48:27     all    1,01    0,00    4,53    0,50    0,76   18,89    0,00   0,00   74,31
22:48:28     all    3,26    0,00    8,52    0,25    0,00   25,31    0,00   0,00   62,66
22:48:29     all    0,25    0,00    1,50    1,00    0,75   24,31    0,00   0,00   72,18
22:48:30     all    1,02    0,00    0,51    0,00    1,27   21,83    0,00   0,00   75,38
22:48:31     all    0,75    0,00    0,75    0,50    1,74   25,37    0,00   0,00   70,90
22:48:32     all    0,25    0,00    0,00    0,00    0,76   23,80    0,00   0,00   75,19
22:48:33     all    1,01    0,00    0,51    0,00    0,76   27,59    0,00   0,00   70,13
22:48:34     all    1,48    0,00    0,25    0,74    0,99   28,64    0,00   0,00   67,90
22:48:35     all    0,76    0,00    0,25    0,00    1,01   22,67    0,00   0,00   75,31
22:48:36     all    0,51    0,00    0,51    0,00    1,77   22,47    0,00   0,00   74,75

Что делал:

echo 65536 > /sys/module/nf_conntrack_ipv4/parameters/hashsize

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=10800
net.netfilter.nf_conntrack_max=1048576
net.ipv4.tcp_window_scaling = 1
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

ethtool -G eth0 rx 511
ethtool -G eth1 rx 511

 

Клиенты приходят по одному влану, в интернет уходят с другого. Сначала оба влана были на одной сетевой и производительность была почти в 2 раза ниже, ядро обрабатывающее прерывания от сетевой карты было постоянно в 100%si. После задействования двух сетевых сразу получил результат приведенный выше. К сожалению больше пока не могу нагрузить.

Изменено 28 сентября, 2009 пользователем a0d75

[Cayz]

во-вторых, зачем ты 2.6.26 то патчишь ? модуль просто собирай и вперёд

Уже понял, просто собирал под 2.6.18, потом ставил 2.6.26, и промухал ./configure для pptpd, вот ничего и не работало.

Сейчас неделя uptime, всё красиво работает.

Огромное спасибо!

Изменено 30 сентября, 2009 пользователем Cayz

[heap]

Кто-нибудь пользует bonding на сервачках с accel? Как впечатления?

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

 

Плюс хочу спросить - как подобрать размеры аппаратных буферов на карточка?

Карточки Intel Corporation 82571EB Gigabit Ethernet Controller и Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet

Драйвер на бродком к слову собрал с оффсайта.

# ethtool -i eth0

driver: e1000

version: 7.3.20-k2-NAPI

firmware-version: 5.6-2

bus-info: 0000:0a:00.0

# ethtool -g eth0

Ring parameters for eth0:

Pre-set maximums:

RX: 4096

RX Mini: 0

RX Jumbo: 0

TX: 4096

Current hardware settings:

RX: 4096

RX Mini: 0

RX Jumbo: 0

TX: 4096

 

# ethtool -i eth1

driver: bnx2

version: 1.6.9

firmware-version: 3.5.12 ipms 1.6.0

bus-info: 0000:03:00.0

 

# ethtool -g eth1

Ring parameters for eth1:

Pre-set maximums:

RX: 1020

RX Mini: 0

RX Jumbo: 0

TX: 255

Current hardware settings:

RX: 1020

RX Mini: 0

RX Jumbo: 0

TX: 255

 

 

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

И напоследок - гугл не помог - можно ли как-то поймать хотя бы текст паники, если не дамп ядра. Во Фре помнится можно заставить слить при панике дамп в каталог и потом его бэктрейсить. Какие варианты в Линукс, кроме глазеть на монитор?

[shicoy]

Какие варианты в Линукс, кроме глазеть на монитор?

Обсуждалось в этой же теме, несколькими страницами раньше. Tip: выводить системные сообщения на com-порт.