Wingman Опубликовано 18 сентября, 2009 (изменено) · Жалоба Помогите подтюнить, пожалуйста =) Железо: 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MagMike Опубликовано 18 сентября, 2009 · Жалоба 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 пакетов/с. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 18 сентября, 2009 · Жалоба Собсно вопрос решился.. Контрак отключил, но главное - очистил 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 где-то подкрутить надо, подозреваю? =) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 18 сентября, 2009 (изменено) · Жалоба Мля мля мля!! На серваке с натом сетевухи PCI, какая там проп. способность шины PCI? не 266 ли мбит/с? Щас как раз затык на 240-250 мбит + там харды всякие... Ыыы, блин, если только в сетевках дело - я эту конструкцию доведу до 500 мбит-с с парой тысяч юзеров как минимум! =))) ыыы /* убежал в щенячьем восторге :D */ Изменено 18 сентября, 2009 пользователем Wingman Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 18 сентября, 2009 · Жалоба Wingman при 1000 сессий прокачивает ~350 мбит/с, 45 кппс, и процы просто отдыхают не совсем правильно смотрите - надо смотреть загрузку цпу%, в частности si%. То, что в этих строках 0% - ничего не значит. Вот когда не 0 - тогда уже всё плохо. Пропускная способность PCI, можно считать - гигабит, но общий на все устройсва, которые там висят. Периферия южного моста обычно не использует полосу внешней шины PCI. Другой вопрос что там за сетевухи.... если они, например, не offload'ят checksumming - то и на 200 мбитах всё остановится. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 18 сентября, 2009 · Жалоба мм... Сетевушки там Intel 82540EM, e1000 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cayz Опубликовано 21 сентября, 2009 · Жалоба Прошу помощи. 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 вырубил, пробовал без шифрования - результат не изменялся. Возможно что-то накосячил, но не могу увидеть в чём. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Vitaly7777 Опубликовано 21 сентября, 2009 · Жалоба С чем может быть связана ошибка "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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maxxxxu Опубликовано 22 сентября, 2009 · Жалоба кто-то собирал 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
XLighter Опубликовано 22 сентября, 2009 · Жалоба xeb в курсе. Ждем. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 22 сентября, 2009 · Жалоба 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 мбит не поднимается, хотя по внешним данным запас по процессору есть, адаптеры тож далеки от своих пропускных способностей. Заранее спасибо. Буду благодарен за любой пинок в верном направлении. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cayz Опубликовано 23 сентября, 2009 (изменено) · Жалоба Не всё сказал... Модуль для 2.6.18 в Debian не хотел подключаться, выдавал ошибку. Пересобрал ядро пропатчив прилагаемым патчем для 2.6.18, а в патче походу одна из предыдущих версий, модуль подключился, но работать не хотел. Сейчас воткнул ядро 2.6.26, пропатчил руками, всё заработало! Буду тестить. Изменено 23 сентября, 2009 пользователем Cayz Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MagMike Опубликовано 23 сентября, 2009 · Жалоба Загрузка процессоров выше 50% не поднимается.как и чем смотрите? 50% - суммарная загрузка (то, что показывает vmstat) или через mpstat/top ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
a0d75 Опубликовано 23 сентября, 2009 · Жалоба Сделайте пожалуйста нормальный ebuild версии 0.8.3 для генты. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 23 сентября, 2009 · Жалоба Загрузка процессоров выше 50% не поднимается.как и чем смотрите? 50% - суммарная загрузка (то, что показывает vmstat) или через mpstat/top ? В реальном времени htop или top. + Рисую rrd графики, собирая стат по mpstat. Забыл еще указать, что если на самом сервере запускаю wget - долбит десятки мегабит. А уже на клиенте без всяких шейперов со стороны сервера - болт. При запуске wget прыгает до порядка 10-12 мегабит и падает ниже восьми в среднем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 25 сентября, 2009 · Жалоба 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) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 25 сентября, 2009 (изменено) · Жалоба Попытался заюзать бондинг для распараллеливания нагрузки по ядрам - в итоге получил при сравнительно низкой загрузке (до 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 25 сентября, 2009 · Жалоба С чем может быть связана ошибка "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 это значит что соединение с заданными идентификаторами уже существует, такое бывает с глючными роутерами, которые полностью не оборвав предыдщее соединение открывают новое с тем-же самым идентификатором соединения Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 25 сентября, 2009 · Жалоба mtu 1492mru 1492 возможно mtu слишком большой, поставь 1436, ну и mru соответсвенно Не всё сказал... Модуль для 2.6.18 в Debian не хотел подключаться, выдавал ошибку. Пересобрал ядро пропатчив прилагаемым патчем для 2.6.18, а в патче походу одна из предыдущих версий, модуль подключился, но работать не хотел. Сейчас воткнул ядро 2.6.26, пропатчил руками, всё заработало! Буду тестить. во-первых, патч для 2.6.18 уже морально устарел, это патч одной из первых версии accel-pptp, соответсвенно забагованный, во-вторых, зачем ты 2.6.26 то патчишь ? модуль просто собирай и вперёд Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maxxxxu Опубликовано 25 сентября, 2009 · Жалоба только 2 дня назад поставил 0.8.3 с ядром 2.6.29.6, т.к. с 2.6.31 не компилилось, но огромное спасибо за проделанную работу! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 25 сентября, 2009 · Жалоба Попытался заюзать бондинг для распараллеливания нагрузки по ядрам - в итоге получил при сравнительно низкой загрузке (до 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, если есть необходимость можно восстановить Я думаю было бы полезно. Сам сейчас вкручиваю бондинг. Правда по принципу маков или айпишников, что не должно вносить реордеринга пакетов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
a0d75 Опубликовано 28 сентября, 2009 (изменено) · Жалоба Поделитесь статистикой производительности, чтобы знать к чему стремиться. Вот мои данные: Сервер 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cayz Опубликовано 30 сентября, 2009 (изменено) · Жалоба во-вторых, зачем ты 2.6.26 то патчишь ? модуль просто собирай и вперёд Уже понял, просто собирал под 2.6.18, потом ставил 2.6.26, и промухал ./configure для pptpd, вот ничего и не работало. Сейчас неделя uptime, всё красиво работает. Огромное спасибо! Изменено 30 сентября, 2009 пользователем Cayz Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 1 октября, 2009 · Жалоба Кто-нибудь пользует 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 Как видно сейчас размеры буферов закатил в максимум. Возможно есть мнения, что это неверно? И напоследок - гугл не помог - можно ли как-то поймать хотя бы текст паники, если не дамп ядра. Во Фре помнится можно заставить слить при панике дамп в каталог и потом его бэктрейсить. Какие варианты в Линукс, кроме глазеть на монитор? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shicoy Опубликовано 2 октября, 2009 · Жалоба Какие варианты в Линукс, кроме глазеть на монитор? Обсуждалось в этой же теме, несколькими страницами раньше. Tip: выводить системные сообщения на com-порт. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...