[Andrey_open]

не у кого нет проблемы дропов icmp на интерфейсе туннеля?, через обычный пптпд все ок, через аццел примерно 30-40% потерь

[Cayz]

На 2.6.31.3 (взял тут http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31.3/) Debian, accel-pptp не собирается(

/usr/src/accel-pptp/accel-pptp-0.8.3# make server
echo Building kernel module
Building kernel module
(cd kernel/driver; make )
make[1]: Entering directory `/usr/src/accel-pptp/accel-pptp-0.8.3/kernel/driver'
using "/lib/modules/2.6.31-02063103-generic/build" kernel headers
make -C /lib/modules/2.6.31-02063103-generic/build SUBDIRS=/usr/src/accel-pptp/accel-pptp-0.8.3/kernel/driver modules
make[2]: Entering directory `/usr/src/linux-headers-2.6.31-02063103-generic'
  CC [M]  /usr/src/accel-pptp/accel-pptp-0.8.3/kernel/driver/pptp.o
/usr/src/accel-pptp/accel-pptp-0.8.3/kernel/driver/pptp.c: In function ‘pptp_xmit’:
/usr/src/accel-pptp/accel-pptp-0.8.3/kernel/driver/pptp.c:386: error: ‘struct sk_buff’ has no member named ‘dst’
/usr/src/accel-pptp/accel-pptp-0.8.3/kernel/driver/pptp.c:387: error: ‘struct sk_buff’ has no member named ‘dst’
/usr/src/accel-pptp/accel-pptp-0.8.3/kernel/driver/pptp.c: In function ‘pptp_rcv’:
/usr/src/accel-pptp/accel-pptp-0.8.3/kernel/driver/pptp.c:551: error: ‘struct sk_buff’ has no member named ‘dst’
/usr/src/accel-pptp/accel-pptp-0.8.3/kernel/driver/pptp.c:552: error: ‘struct sk_buff’ has no member named ‘dst’
make[3]: *** [/usr/src/accel-pptp/accel-pptp-0.8.3/kernel/driver/pptp.o] Ошибка 1
make[2]: *** [_module_/usr/src/accel-pptp/accel-pptp-0.8.3/kernel/driver] Ошибка 2
make[2]: Leaving directory `/usr/src/linux-headers-2.6.31-02063103-generic'
make[1]: *** [all] Ошибка 2
make[1]: Leaving directory `/usr/src/accel-pptp/accel-pptp-0.8.3/kernel/driver'
make: *** [module] Ошибка 2

 

До этого работало на ядре 2.6.26 - 2 недели тихо и спокойно, последние 2 дня непонятности какие-то с ядром, причем не тогда когда нагрузка максимальная, а в любой самый неудобный момент.

 

Из того что в последнее время я делал с сервером - это 1) ставил accel-pptp 0.8.3, но с ним оно работало и не падало почти 2 недели ничего не менял. 2) Изменил способ подсчета трафика, до этого снимал через ipq, на кануне перевёл на fprobe-ulog.

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

 

[DemYaN]

нужно accel брать из git:

 

accel-pptp 0.8.4

 

* supports 2.6.31 kernel

* included 430-persist.patch (theMIROn)

Изменено 13 октября, 2009 пользователем DemYaN

[[anp/hsw]]

может кто-нибудь подсказать к чему относится данная ошибка?

Oct 16 00:00:18 mega pptpd[30363]: CTRL: Client 192.168.10.17 control connection finished

Oct 16 00:00:28 mega pptpd[30368]: CTRL: Client 192.168.10.17 control connection started

Oct 16 00:00:29 mega pptpd[30368]: CTRL: failed to connect PPTP socket (Operation already in progress)

Oct 16 00:00:29 mega pptpd[30368]: CTRL: Reaping child PPP[0]

 

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

accel-pptp 0.8.3, ядро 2.4.37

 

 

[Ivantey]

это значит что есть уже процесс с такого же айпишника.

[Andrey_open]

не у кого нет проблемы дропов icmp на интерфейсе туннеля?, через обычный пптпд все ок, через аццел примерно 30-40% потерь

В 0.8.4 это похоже пофикшено

 

Новый баг, но, имхо из-за ядра - через рандомное время сервер просто зависал, на всех четырех ядрах 0.0% id - лечилось ребутом. Сегодня заметил в dmesg: dst cache overflow. Погуглил нашел патч, 8 часов уже работает, ~1000 коннектов, трафик 170 мбит/сек, ядро 2.6.30. Посмотрим что будет в ЧНН.

[shicoy]

не у кого нет проблемы дропов icmp на интерфейсе туннеля?, через обычный пптпд все ок, через аццел примерно 30-40% потерь

В 0.8.4 это похоже пофикшено

 

Новый баг, но, имхо из-за ядра - через рандомное время сервер просто зависал, на всех четырех ядрах 0.0% id - лечилось ребутом. Сегодня заметил в dmesg: dst cache overflow. Погуглил нашел патч, 8 часов уже работает, ~1000 коннектов, трафик 170 мбит/сек, ядро 2.6.30. Посмотрим что будет в ЧНН.

А у вас какое ядро стоит?

[Andrey_open]

не у кого нет проблемы дропов icmp на интерфейсе туннеля?, через обычный пптпд все ок, через аццел примерно 30-40% потерь

В 0.8.4 это похоже пофикшено

 

Новый баг, но, имхо из-за ядра - через рандомное время сервер просто зависал, на всех четырех ядрах 0.0% id - лечилось ребутом. Сегодня заметил в dmesg: dst cache overflow. Погуглил нашел патч, 8 часов уже работает, ~1000 коннектов, трафик 170 мбит/сек, ядро 2.6.30. Посмотрим что будет в ЧНН.

А у вас какое ядро стоит?

gentoo 2.6.30

[Max P]

а чего за патч? я нагуглил только для 2.6.10

[Andrey_open]

патч http://www.ssi.bg/~ja/routes-2.6.30-16.diff

 

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

[Max P]

2.6.31.4 не пробовали?

[Andrey_open]

нет. откатился на 2.6.26, которое до этого было с обычным pptp, так как зависоны сегодня опять были :(

[Andrey_open]

в общем добрался я до консоли в момент зависона. Процесс pppd отхавывает 100% одного из ядер и все - система ложится ( куда копать?

[Andrey_open]

загрузил ядро с nosmp. Работает стабильно, производительность на порядок выше чем стандартный поптоп, но 3 ядра в утиль это сильно жестко :)

[NiTr0]

Andrey_open

4 ядра будут работать для собссно пптп в 2 случаях:

1) на сетевухе имеется 4 очереди пакетов с 4 прерываниями

2) удастся при помощи танцев с бубном реализовать round-robin алгоритм

3) стоит 4 сетевухи

[heap]

Andrey_open

4 ядра будут работать для собссно пптп в 2 случаях:

1) на сетевухе имеется 4 очереди пакетов с 4 прерываниями

2) удастся при помощи танцев с бубном реализовать round-robin алгоритм

3) стоит 4 сетевухи

На самом деле 4 сетевухи и bonding самое то в данной ситуации. Только, насколько я понял, у человека с smp оно валится в панику - потому все ухищрения по балансингу на процессорные ядра до решения проблемы икс идут лесом. o_O

[NiTr0]

Или 1 сетевуха с 4 очередями прерываний... Хотя ИМХО адекватнее все же это все разнести на 2 разных не особо мощных тазика т.к. нагрузка растет не только пропорционально ппс, но и пропорционально кол-ву туннелей. И при постоянном ппс при 750 юзерах процу куда хуже живется, чем при 600...

[Andrey_open]

Andrey_open

4 ядра будут работать для собссно пптп в 2 случаях:

1) на сетевухе имеется 4 очереди пакетов с 4 прерываниями

2) удастся при помощи танцев с бубном реализовать round-robin алгоритм

3) стоит 4 сетевухи

хз, вот система с обычным пптпд:

 

top - 09:26:58 up 1 day, 15:19, 1 user, load average: 0.13, 0.18, 0.18

Tasks: 445 total, 2 running, 443 sleeping, 0 stopped, 0 zombie

Cpu0 : 1.0%us, 2.0%sy, 0.0%ni, 93.0%id, 0.0%wa, 0.0%hi, 4.0%si, 0.0%st

Cpu1 : 0.3%us, 3.0%sy, 0.0%ni, 90.7%id, 0.0%wa, 0.7%hi, 5.3%si, 0.0%st

Cpu2 : 1.0%us, 1.7%sy, 0.0%ni, 93.0%id, 0.0%wa, 0.7%hi, 3.6%si, 0.0%st

Cpu3 : 0.3%us, 1.7%sy, 0.0%ni, 92.4%id, 0.0%wa, 1.7%hi, 4.0%si, 0.0%st

Mem: 2070444k total, 365768k used, 1704676k free, 111764k buffers

Swap: 2056312k total, 0k used, 2056312k free, 86800k cached

 

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

7 root 15 -5 0 0 0 S 1 0.0 22:46.35 ksoftirqd/1

29036 root 20 0 1732 592 488 S 1 0.0 0:03.28 pptpctrl

28475 root 20 0 1732 592 488 R 1 0.0 0:31.31 pptpctrl

29231 root 20 0 1732 592 488 S 1 0.0 0:01.73 pptpctrl

443 root 20 0 1732 592 488 S 1 0.0 2:35.50 pptpctrl

26188 root 20 0 1732 636 488 S 1 0.0 0:26.11 pptpctrl

26973 root 20 0 1732 596 488 S 1 0.0 4:34.46 pptpctrl

27952 root 20 0 1732 592 488 S 1 0.0 0:17.32 pptpctrl

28979 root 20 0 1732 592 488 S 1 0.0 0:01.48 pptpctrl

29485 root 20 0 1732 596 488 S 1 0.0 0:01.12 pptpctrl

30079 root 20 0 1732 592 488 S 1 0.0 0:02.55 pptpctrl

30705 root 20 0 1732 632 488 S 1 0.0 1:47.02 pptpctrl

30847 root 20 0 2632 1392 900 R 1 0.1 0:00.07 top

947 root 20 0 1732 644 488 S 0 0.0 3:02.43 pptpctrl

 

2 сетевухи:

00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02)

03:02.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)

 

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

 

На самом деле 4 сетевухи и bonding самое то в данной ситуации. Только, насколько я понял, у человека с smp оно валится в панику - потому все ухищрения по балансингу на процессорные ядра до решения проблемы икс идут лесом. o_O

в том то и проблема что паники как таковой нет, просто все виснет :( а как дебажить ядро я не в курсе :(

 

Или 1 сетевуха с 4 очередями прерываний... Хотя ИМХО адекватнее все же это все разнести на 2 разных не особо мощных тазика т.к. нагрузка растет не только пропорционально ппс, но и пропорционально кол-ву туннелей. И при постоянном ппс при 750 юзерах процу куда хуже живется, чем при 600...

тазиков и так 3 штуки, не хотелось ставить еще один поэтому решил поэкспериментировать с акцелл. сейчас на 2х машинах стоит акцелл с ядром в режиме nosmp и на одном обычный поптом с 4 ядрами, производительность примерно одинаковая у всех, но ее все же мало :(

 

[NiTr0]

хз, вот система с обычным пптпд:

А что в /proc/interrupts? По всем 4 ядрам прерывания сетевух раскиданы?

[Andrey_open]

vpn6 ~ # cat /proc/interrupts

CPU0 CPU1 CPU2 CPU3

0: 141 119 145 123 IO-APIC-edge timer

1: 1 0 1 1 IO-APIC-edge i8042

8: 20 19 19 22 IO-APIC-edge rtc0

9: 0 0 0 0 IO-APIC-fasteoi acpi

12: 0 1 0 2 IO-APIC-edge i8042

14: 0 0 0 0 IO-APIC-edge ide0

15: 0 0 0 0 IO-APIC-edge ide1

17: 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1

18: 228411472 228407051 228224552 228278723 IO-APIC-fasteoi uhci_hcd:usb3, uhci_hcd:usb7, eth0

19: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb6

21: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb4

23: 1 0 0 1 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb5

26: 227270777 227274347 227458064 227401836 PCI-MSI-edge eth1

27: 199003 199853 198609 200681 PCI-MSI-edge ahci

NMI: 0 0 0 0 Non-maskable interrupts

LOC: 182231120 182046550 181336203 181321568 Local timer interrupts

SPU: 0 0 0 0 Spurious interrupts

RES: 2704518 2708252 2706721 2705979 Rescheduling interrupts

CAL: 4061 4143 4184 4043 Function call interrupts

TLB: 10168 9395 23186 22168 TLB shootdowns

TRM: 0 0 0 0 Thermal event interrupts

ERR: 0

MIS: 0

 

[vitalyb]

NiTr0

Andrey_open

 

не важно что там куда раскидано по двум причинам:

1) слишком низкая нагрузка (с аффинити f прерывания происходят по по очереди на четырех cpu, работа усредняется и попадает в статистику в виде "работающих" четырех ядер, но в конкретный момент всегда работает только одно)

2) обычный poptop работает в userspace - и нагрузкой по части сети можно вообще пренебречь на фоне накладных расходов

 

[Andrey_open]

NiTr0

Andrey_open

 

не важно что там куда раскидано по двум причинам:

1) слишком низкая нагрузка (с аффинити f прерывания происходят по по очереди на четырех cpu, работа усредняется и попадает в статистику в виде "работающих" четырех ядер, но в конкретный момент всегда работает только одно)

2) обычный poptop работает в userspace - и нагрузкой по части сети можно вообще пренебречь на фоне накладных расходов

понятно, что ничего не понятно :) что смотреть?

[NiTr0]

В том-то и дело, что у меня при affinity f прерывания приходят только на одно ядро... Соответственно, при этом вся обработка пакетов, начиная с получения с буффера сетевухи оканчивая иптейблсом/шейпером, проходит на этом ядре.

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

Изменено 20 октября, 2009 пользователем NiTr0

[xeb]

кажисть нужно возобновить эксперименты с ppp_generic_smp ...

[vitalyb]

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

не совсем корректный вопрос, но суть понятна, соответственно ответ - нет, не будет, только одно ядро в квант времени, или другое ядро, но уже в следующий квант времени. Т.е. хоть 64 ядра там, но работают они по очереди. Так "балансировать" мало того, что смысла нет, так еще и вредно - неэффективно работает CPU кеш, а это светит относительно медленной обработкой и дропами.

 

 54:   14692072          1          0          0   PCI-MSI-edge      eth2-TxRx-0
55:          0       5753          1          0   PCI-MSI-edge      eth2-TxRx-1
56:          0          0       5753          1   PCI-MSI-edge      eth2-TxRx-2
57:          1          0          0       5753   PCI-MSI-edge      eth2-TxRx-3
58:          1          1          4          1   PCI-MSI-edge      eth2
59:       7616          8      12603       6140   PCI-MSI-edge      eth0
60:          1    2107585      38954       1536   PCI-MSI-edge      eth1
61:     771273         36     120620          5   PCI-MSI-edge      eth3-TxRx-0
62:          1     771341     119634          3   PCI-MSI-edge      eth3-TxRx-1
63:          0          6     771290     327861   PCI-MSI-edge      eth3-TxRx-2
64:          0        172          8    1098960   PCI-MSI-edge      eth3-TxRx-3
65:          0          0          4          1   PCI-MSI-edge      eth3

eth0 и eth1 - бортовые Intel 82573, прерывание одно, eth2 и eth3 - Intel 82575, умеет один интерфейс обрабатывать 4 ядрами.

 

Случай, когда affinity f прерывания приходят только на одно ядро тоже бывает. ИМХО, список виновных: драйвер, старое ядро, кривой BIOS (видел такое в начале 2.6.20-ых с MSI)