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

у меня все ядра без SMP на NAS с accel-pptp.

с SMP не пробовал.

 

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


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

Да, паники время от времени вылазят, причем я не заметил никакой закономерности, непонятно, accel-pptp ли виноват =(

заметил, что в паниках таки виновен SMP (проверьте пожалуйста мое предположение загрузив ядро с опцией "nosmp")

достаточно долго бьюсь с этой проблемой, тест показал - в ЧНН возникает вис при использовании SMP практически каждый день, при этом на одном ядре машина может работать месяцами без остановок.

оказывает влияние большой pps по pptp (проводил экспиременты с дополнительным количеством "висящих" сессий - если pps маленький, виса не происходит. accel-pptp также ситуацию не улучшил).

 

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


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

Да, паники время от времени вылазят, причем я не заметил никакой закономерности, непонятно, accel-pptp ли виноват =(
заметил, что в паниках таки виновен SMP (проверьте пожалуйста мое предположение загрузив ядро с опцией "nosmp")

К сожалению, тогда смысла нет для меня: быстродействие сильно упадёт.

А по поводу l2tp под *nix кто что может сказать? Есть смысл? Насколько стабильно и "быстродейственно"? =)

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


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

замечен баг:

1. Клиент подключается по впну с локального адреса 10.10.10.5, если из пула ему выдать адрес 10.10.10.5 = Паника

2. Под нагрузкой, когда закрывается сесия, если моментально переподключиться, так же может возникнуть паника, совпадает ip.

 

Уже тестим новую версию модуля.

 

 

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


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

замечен баг:

1. Клиент подключается по впну с локального адреса 10.10.10.5, если из пула ему выдать адрес 10.10.10.5 = Паника

2. Под нагрузкой, когда закрывается сесия, если моментально переподключиться, так же может возникнуть паника, совпадает ip.

 

Уже тестим новую версию модуля.

Как будут результаты - отпишите плз.

Вообще я ухожу от ВПНов, но все же...

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


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

замечен баг:

1. Клиент подключается по впну с локального адреса 10.10.10.5, если из пула ему выдать адрес 10.10.10.5 = Паника

2. Под нагрузкой, когда закрывается сесия, если моментально переподключиться, так же может возникнуть паника, совпадает ip.

 

Уже тестим новую версию модуля.

Где можно взять новую версию модуля, не подскажите?

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


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

svn checkout https://accel-pptp.svn.sourceforge.net/svnroot/accel-pptp/branch/0.8 accel-pptp-0.8

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

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


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

------------------------------------------------------------------------

r39 | xeb | 2008-12-15 22:36:06 +0000 (Пнд, 15 Дек 2008) | 2 lines

 

opimized channel allocation, have to increase performance on heavy load

 

------------------------------------------------------------------------

r38 | xeb | 2008-12-15 13:52:13 +0000 (Пнд, 15 Дек 2008) | 2 lines

 

hash tables replaced with rb_tree which is much faster on heavy load

Всем привет!

Народ! Кто заинтересован в развитии accel-pptp просьба потестить при возможности на нагрузке версию 0.8 (r39/r38).

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

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


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

xeb

На следующей неделе обновлюсь, но у меня нагрузки больше 350 конектов нет, т.к. рассчитывал нагрузку без accel-pptp

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


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

------------------------------------------------------------------------

r39 | xeb | 2008-12-15 22:36:06 +0000 (Пнд, 15 Дек 2008) | 2 lines

 

opimized channel allocation, have to increase performance on heavy load

 

------------------------------------------------------------------------

r38 | xeb | 2008-12-15 13:52:13 +0000 (Пнд, 15 Дек 2008) | 2 lines

 

hash tables replaced with rb_tree which is much faster on heavy load

Всем привет!

Народ! Кто заинтересован в развитии accel-pptp просьба потестить при возможности на нагрузке версию 0.8 (r39/r38).

Затестим, однако можно ли решить проблему с кернел паником на многопроцессорных/многоядерных системах? Какая дополнительная информация нужна?

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


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

Всем привет!

Народ! Кто заинтересован в развитии accel-pptp просьба потестить при возможности на нагрузке версию 0.8 (r39/r38).

Какие люди ! :)

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


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

Какие люди ! :)
Привет привет :)
однако можно ли решить проблему с кернел паником на многопроцессорных/многоядерных системах?
этим и занимаюсь
Какая дополнительная информация нужна?
что он говорит при панике

r40 | xeb | 2008-12-18 08:55:22 +0000 (Чтв, 18 Дек 2008) | 3 lines

* fixed incorrect bitmap operation on channel deallocation
* using big callid ring buffer for preventing callid collision

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


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

А ни у кого не было проблем с клиентами на МакОС или длинковскими роутерами? Начали наблюдаться, пока копаем. 40-ая версия.

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


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

Какая дополнительная информация нужна?
что он говорит при панике

 

Полного вывода нет, вот кусочек:

http://tomilino.net/IMG338.jpg

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

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


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

у меня несколько другой вывод паники:

 

Code: c6 04 10 00 89 e8 89 97 54 01 00 00 8b 1c 24 8b 74 24 04 8b

<0>Kernel panic: Aiee, killing interrupt handler!

In interrupt handler - not syncing

<0>Rebooting in 30 seconds..

 

но в принципе идея таже.

а также волнует сам факт того, что паника происходит и без accel-pptpd, даже со стандартным pptpd

 

вполне возможно, что эта ошибка связана с GRE/PPTP conntrack, ну или либо просто кусок кода перетянули в accel-pptp не разбираясь в его смысле :)

P.S. специально чтобы не фотографировать монитор (гы-гы, порадовало) используйте serial console и какую-нибудь терминальную программу логирование на другом конце... в конце концов это же так просто!

 

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


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

Да, просто, очень просто, но меня рядом не было, заранее не предусмотрели, попросил парня-помошника сфоткать =)

 

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


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

accel-pptp в данных паниках не виноват.

Курить вдумчиво это - http://bugzilla.kernel.org/show_bug.cgi?id=11718

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


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

accel-pptp в данных паниках не виноват.

Курить вдумчиво это - http://bugzilla.kernel.org/show_bug.cgi?id=11718

парирую ваши аргументы :)

есть такие варианты, где терминация на одной машине, а шейпинг и роутинг на другой. виснет, однако, терминирующая машина, и только в SMP.

т.е. там практически только pptpd и форвардинг на бордер. (а на бордере один хрен шейпер sfq, а не htb)

да и да и ядро на терминировании стоит 2.4.37 (где hrtimers в помине небыло)

включаешь SMP - виснет.

проблеме думается мне сто лет в обед...

 

интересно кстати, узнать, виснет ли в аналогичных условиях терминирование pppoe?

а вот кстати аналогичная проблема с l2tp. недавняя. исправленая.

https://kerneltrap.org/mailarchive/linux-ne...008/2/11/811644

Изменено пользователем [anp/hsw]

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


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

парирую ваши аргументы :)

есть такие варианты, где терминация на одной машине, а шейпинг и роутинг на другой. виснет, однако, терминирующая машина, и только в SMP.

т.е. там практически только pptpd и форвардинг на бордер. (а на бордере один хрен шейпер sfq, а не htb)

да и да и ядро на терминировании стоит 2.4.37 (где hrtimers в помине небыло)

Тогда покажите полный вывод паник.

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


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

вот, пожалуйста:

 

unable to handle kernel NULL pointer dereference at virtual address 000000ee

*pde = 2d2ff001

*pte = 00000000

Oops: 0002

CPU: 2

EIP: 0010:[<f8917a93>] Not tainted

EFLAGS: 00010246

eax: 00000000 ebx: 000000ee ecx: c0468c08 edx: 000000ee

esi: f6ee8180 edi: de2a6980 ebp: 00000000 esp: e4c85d54

ds: 0018 es: 0018 ss: 0018

Process pppd (pid: 15566, stackpage=e4c85000)

Stack: 00000000 f6ee8180 e4c84000 de2a6980 f8917e11 de2a6980 efed13d4 00000000

00000000 00000000 efed13d4 f6062e80 efed13c0 cd0698a8 00000000 00000000

f8a759a0 f8a75a10 efed13ac 00000070 f88932c7 f6ee8180 c7793800 f6f84800

Call Trace: [<f8917e11>] [<f88932c7>] [<c0335f70>] [<f8902096>] [<f8902640>]

[<c032212f>] [<c0335f70>] [<c0335f70>] [<c0322517>] [<c0335f70>] [<f8902698>]

[<c0335dda>] [<c0335f70>] [<c0334580>] [<c0322611>] [<c0334580>] [<c0334580>]

[<c0334256>] [<c0334580>] [<c0317bd5>] [<c0317d23>] [<c0317ea0>] [<c0128546>]

[<c010b8a2>] [<c010e4b8>]

 

Code: c6 04 10 00 89 e8 89 97 54 01 00 00 8b 1c 24 8b 74 24 04 8b

<0>Kernel panic: Aiee, killing interrupt handler!

In interrupt handler - not syncing

<0>Rebooting in 30 seconds..

 

Unable to handle kernel NULL pointer dereference at virtual address 00000114

*pde = 3674a001

*pte = 00000000

Oops: 0002

CPU: 0

EIP: 0010:[<f892aa93>] Not tainted

EFLAGS: 00010246

eax: 00000000 ebx: 00000114 ecx: c0468b08 edx: 00000114

esi: d5e75a80 edi: e3f9d680 ebp: 00000000 esp: f6743ca8

ds: 0018 es: 0018 ss: 0018

Process pppd (pid: 1936, stackpage=f6743000)

Stack: 00000000 d5e75a80 f6742000 e3f9d680 f892ae11 e3f9d680 f6ef76d4 00000000

c031cb94 f6743cfc f6ef76d4 f732c680 f6742000 f73c9000 00000000 00000000

f8a191a0 f8a19210 f6ef76ac 00000070 f88932c7 d5e75a80 f51ed000 f73c9000

Call Trace: [<f892ae11>] [<c031cb94>] [<f88932c7>] [<c0335f70>] [<f8902096>]

[<f8902640>] [<c032212f>] [<c0335f70>] [<c0335f70>] [<c0322517>] [<c0335f70>]

[<f8902698>] [<c0335dda>] [<c0335f70>] [<c0334580>] [<c0322611>] [<c0334580>]

[<c0334580>] [<c0334256>] [<c0334580>] [<c0317bd5>] [<c0317d23>] [<c0317ea0>]

[<c0128546>] [<c010b8a2>] [<c010e4b8>] [<c0160018>] [<c0142de1>] [<c0166fc0>]

[<c03102a6>] [<c0166190>] [<c01095db>]

 

Code: c6 04 10 00 89 e8 89 97 54 01 00 00 8b 1c 24 8b 74 24 04 8b

<0>Kernel panic: Aiee, killing interrupt handler!

In interrupt handler - not syncing

<0>Rebooting in 30 seconds..

 

на данной машине более не экспирементировал с SMP (обьект повышеной важности, так сказать)

 

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


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

[anp/hsw], на какой версии ядра/accel-pptp падение smp проверялось и сколько коннектов было ?

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

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


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

[anp/hsw], на какой версии ядра/accel-pptp падение smp проверялось и сколько коннектов было ?

accel-pptp не используется, баловался в качестве теста. ядро было 2.6.18, accel-pptp - последний на момент тестирования. коннектов по-разному, бывало и 400 спокойно держал, но когда всеже падал и перезагружался - происходило быстрое наращивание соединений - вис уже по достижении 150, если по времени то это от 1 до 30 минут (в зависимости от времени суток)

впрочем, вис при аналогичных условиях и обычный "неускореный" pptpd.

висло даже на ядрах 2.4.x (ну и досих пор виснет, просто SMP не юзаю)

 

не имел возможности компилировать ядра с "frame pointers" - ибо, "продакшен", да и отлаживать некогда, надо поднимать и запускать по новой сервер :)

 

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


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

хм 2.6.18, видимо дело было давно, тогда accel-pptp был гораздо забагованней

 

------------------------------------------------------------------------

r42 | xeb | 2008-12-25 12:36:38 +0000 (Чтв, 25 Дек 2008) | 2 lines

 

allocating zeroed memory for callid array

 

------------------------------------------------------------------------

r41 | xeb | 2008-12-25 11:43:25 +0000 (Чтв, 25 Дек 2008) | 2 lines

 

callid rb_tree raplaced with linear array for maximum performane

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


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

а не мог бы кто-нибудь сделать backport accel-pptp для ядер 2.4? тогда я бы я смог проверить его под действительно БОЛЬШОЙ нагрузкой....

... но к сожалению бы не смог собрать ядро с frame pointers, и вытерпеть больше 1 oops'а - ибо продакшен :)

 

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


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

в принципе я когда-то делал accel-pptp для ядра 2.4, правда давно не обновлял и думаю это уже не актуально ....

а что мешает использовть 2.6 ядра ?

 

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


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

Join the conversation

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

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

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

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

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

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

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