Andrey_open Опубликовано 11 октября, 2009 · Жалоба не у кого нет проблемы дропов icmp на интерфейсе туннеля?, через обычный пптпд все ок, через аццел примерно 30-40% потерь Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cayz Опубликовано 13 октября, 2009 · Жалоба На 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. Детально не разбирался в чём проблемы, да и честно говоря не очень то и знаю куда смотреть, нет опыта борьбы с такими вещами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 13 октября, 2009 (изменено) · Жалоба нужно accel брать из git: accel-pptp 0.8.4 * supports 2.6.31 kernel * included 430-persist.patch (theMIROn) Изменено 13 октября, 2009 пользователем DemYaN Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 16 октября, 2009 · Жалоба может кто-нибудь подсказать к чему относится данная ошибка? 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivantey Опубликовано 16 октября, 2009 · Жалоба это значит что есть уже процесс с такого же айпишника. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrey_open Опубликовано 16 октября, 2009 · Жалоба не у кого нет проблемы дропов icmp на интерфейсе туннеля?, через обычный пптпд все ок, через аццел примерно 30-40% потерь В 0.8.4 это похоже пофикшено Новый баг, но, имхо из-за ядра - через рандомное время сервер просто зависал, на всех четырех ядрах 0.0% id - лечилось ребутом. Сегодня заметил в dmesg: dst cache overflow. Погуглил нашел патч, 8 часов уже работает, ~1000 коннектов, трафик 170 мбит/сек, ядро 2.6.30. Посмотрим что будет в ЧНН. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shicoy Опубликовано 16 октября, 2009 · Жалоба не у кого нет проблемы дропов icmp на интерфейсе туннеля?, через обычный пптпд все ок, через аццел примерно 30-40% потерь В 0.8.4 это похоже пофикшено Новый баг, но, имхо из-за ядра - через рандомное время сервер просто зависал, на всех четырех ядрах 0.0% id - лечилось ребутом. Сегодня заметил в dmesg: dst cache overflow. Погуглил нашел патч, 8 часов уже работает, ~1000 коннектов, трафик 170 мбит/сек, ядро 2.6.30. Посмотрим что будет в ЧНН. А у вас какое ядро стоит? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrey_open Опубликовано 16 октября, 2009 · Жалоба не у кого нет проблемы дропов icmp на интерфейсе туннеля?, через обычный пптпд все ок, через аццел примерно 30-40% потерь В 0.8.4 это похоже пофикшено Новый баг, но, имхо из-за ядра - через рандомное время сервер просто зависал, на всех четырех ядрах 0.0% id - лечилось ребутом. Сегодня заметил в dmesg: dst cache overflow. Погуглил нашел патч, 8 часов уже работает, ~1000 коннектов, трафик 170 мбит/сек, ядро 2.6.30. Посмотрим что будет в ЧНН. А у вас какое ядро стоит? gentoo 2.6.30 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 16 октября, 2009 · Жалоба а чего за патч? я нагуглил только для 2.6.10 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrey_open Опубликовано 16 октября, 2009 · Жалоба патч http://www.ssi.bg/~ja/routes-2.6.30-16.diff к сожалению сегодня система опять слегла :( но уже по другому поводу - проблемы с драйвером sky2 на сервере с радиусом :( поэтому краш тест не получился, думаю после выходных заменить платформу там и попробовать еще раз :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 17 октября, 2009 · Жалоба 2.6.31.4 не пробовали? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrey_open Опубликовано 17 октября, 2009 · Жалоба нет. откатился на 2.6.26, которое до этого было с обычным pptp, так как зависоны сегодня опять были :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrey_open Опубликовано 17 октября, 2009 · Жалоба в общем добрался я до консоли в момент зависона. Процесс pppd отхавывает 100% одного из ядер и все - система ложится ( куда копать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrey_open Опубликовано 18 октября, 2009 · Жалоба загрузил ядро с nosmp. Работает стабильно, производительность на порядок выше чем стандартный поптоп, но 3 ядра в утиль это сильно жестко :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 18 октября, 2009 · Жалоба Andrey_open 4 ядра будут работать для собссно пптп в 2 случаях: 1) на сетевухе имеется 4 очереди пакетов с 4 прерываниями 2) удастся при помощи танцев с бубном реализовать round-robin алгоритм 3) стоит 4 сетевухи Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 19 октября, 2009 · Жалоба Andrey_open 4 ядра будут работать для собссно пптп в 2 случаях: 1) на сетевухе имеется 4 очереди пакетов с 4 прерываниями 2) удастся при помощи танцев с бубном реализовать round-robin алгоритм 3) стоит 4 сетевухи На самом деле 4 сетевухи и bonding самое то в данной ситуации. Только, насколько я понял, у человека с smp оно валится в панику - потому все ухищрения по балансингу на процессорные ядра до решения проблемы икс идут лесом. o_O Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 19 октября, 2009 · Жалоба Или 1 сетевуха с 4 очередями прерываний... Хотя ИМХО адекватнее все же это все разнести на 2 разных не особо мощных тазика т.к. нагрузка растет не только пропорционально ппс, но и пропорционально кол-ву туннелей. И при постоянном ппс при 750 юзерах процу куда хуже живется, чем при 600... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrey_open Опубликовано 20 октября, 2009 · Жалоба 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 ядрами, производительность примерно одинаковая у всех, но ее все же мало :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 20 октября, 2009 · Жалоба хз, вот система с обычным пптпд: А что в /proc/interrupts? По всем 4 ядрам прерывания сетевух раскиданы? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrey_open Опубликовано 20 октября, 2009 · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 20 октября, 2009 · Жалоба NiTr0 Andrey_open не важно что там куда раскидано по двум причинам: 1) слишком низкая нагрузка (с аффинити f прерывания происходят по по очереди на четырех cpu, работа усредняется и попадает в статистику в виде "работающих" четырех ядер, но в конкретный момент всегда работает только одно) 2) обычный poptop работает в userspace - и нагрузкой по части сети можно вообще пренебречь на фоне накладных расходов Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrey_open Опубликовано 20 октября, 2009 · Жалоба NiTr0 Andrey_open не важно что там куда раскидано по двум причинам: 1) слишком низкая нагрузка (с аффинити f прерывания происходят по по очереди на четырех cpu, работа усредняется и попадает в статистику в виде "работающих" четырех ядер, но в конкретный момент всегда работает только одно) 2) обычный poptop работает в userspace - и нагрузкой по части сети можно вообще пренебречь на фоне накладных расходов понятно, что ничего не понятно :) что смотреть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 20 октября, 2009 (изменено) · Жалоба В том-то и дело, что у меня при affinity f прерывания приходят только на одно ядро... Соответственно, при этом вся обработка пакетов, начиная с получения с буффера сетевухи оканчивая иптейблсом/шейпером, проходит на этом ядре. Как будет распараллеливаться нагрузка при round-robin - т.е. будет ли сетевуха генерить новые прерывания до окончания полной обработки пакета или нет - проверить по указанным причинам не смог. Изменено 20 октября, 2009 пользователем NiTr0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 20 октября, 2009 · Жалоба кажисть нужно возобновить эксперименты с ppp_generic_smp ... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 20 октября, 2009 · Жалоба Как будет распараллеливаться нагрузка при 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) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...