Сбор багов и feature requests

[nickmas]

Отключил модуль cap_ether - нагрузка на проц упала до 2-6 % вместо 25-50%. Но народ по прежнему выкидывает.

Еще вопрос: если stargazer поставить в стороне от общего потока инетрнет трафика на отдельном серваке, поможет ли это разрешить ситуацию?

[madf]

Попробуй собрать в отладочном режиме и посмотреть что он будет в консоль писать.

Количество юзеров тут не при чем.

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

[nickmas]

Попробуй собрать в отладочном режиме и посмотреть что он будет в консоль писать.

Количество юзеров тут не при чем.

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

 

Ни разу не собирал в отладочном режиме. Подскажи команду, пожалуйста.

[madf]

Попробуй собрать в отладочном режиме и посмотреть что он будет в консоль писать.

Количество юзеров тут не при чем.

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

 

Ни разу не собирал в отладочном режиме. Подскажи команду, пожалуйста.

$ build debug
$ make

Можно запускать прямо из сборочного каталога, но тогда в конфиге нужно прописать путь к плагинам в сборочном каталоге и перед запуском устанавливать LD_LIBRARY_PATH=../../lib

А можно сделать sudo make install-bin и запускать ка обычно.

Но нужно иметь в виду что при этом stargazer не становится дэмоном и начинает сыпать в консоль лог, о котором я и говорил. Так что в скрипты запуска имеет смысл добавить перенаправление вывода в файл и оператор & в конце.

[yKpon]

можно ли как исправить уход в нирвану стг после отваливания мускула?

[madf]

можно ли как исправить уход в нирвану стг после отваливания мускула?

Да, но достаточно сложно.

Если кто-то возьмется - рекомендую посмотреть как это сделано в mod_store_postgresql.

[yKpon]

ещё заметил такую вещь, была всего раза 2 за последние 2-3 месяца, stg работает, авторизатор и конфигуратор подключается, правила создаются, но ниодного байта не пропускается, помогает исключительно рестарт биллинга

[Небесный]

ещё заметил такую вещь, была всего раза 2 за последние 2-3 месяца, stg работает, авторизатор и конфигуратор подключается, правила создаются, но ниодного байта не пропускается, помогает исключительно рестарт биллинга

Странно, за два месяца с лихом ни одного случая такого небыло - может причина не в СТГ?

[yKpon]

Странно, за два месяца с лихом ни одного случая такого небыло - может причина не в СТГ?

не исключаю возможно файрволл, но что с ним может быть? всё работает и не трогается, состояние файрволла перепроверял 10 раз когда висело, все правила правильные

[nightfly]

ещё заметил такую вещь, была всего раза 2 за последние 2-3 месяца, stg работает, авторизатор и конфигуратор подключается, правила создаются, но ниодного байта не пропускается, помогает исключительно рестарт биллинга

а каким местом stg по вашему вообще связан с "пропуском трафика"?

 

можно ли как исправить уход в нирвану стг после отваливания мускула?

Да, но достаточно сложно.

Если кто-то возьмется - рекомендую посмотреть как это сделано в mod_store_postgresql.

 

А почему мускул должен вообще отваливаться?

[Небесный]

Вот и я на что-то уже похожее напоролся, сказать однозначно что это СТГ не могу.

Дело было так.

Запустил авторизатор, подключился - проработал где-то часа наверное 6-7 не трогая авторизатор.

Спустя это время отключаюсь авторизатором - кнопка отжимается - статус горит зеленым и говорит, что подключен - скрипт ОнДисконекта не отработался - думаю подожду, ждал минут 5-10. Ничего не изменилось (кнопка отжата - статус зеленый-онлайн, правила на месте - тоесть дисконект не происходит).

Закрыл авторизатор совсем - через положенных 15 сек. скрипт ОнДисконекта в СТГ отработался.

Пробую запустить опять авторизатор - усе нормально работает.

 

Так и не въехал правда в чем была причина, толи виснет авторизатор, толи это СТГ балуется.

Такой случай у себя уже наблюдаю второй раз.

 

Логи

2010-06-13 18:49:01 -- Connect, 10.10.0.2
2010-06-13 23:59:00 -- Disconnect,  session upload: '63010347,81102,0,0,0,0,0,0,0,0' session download: '198165357,1696316,0,0,0,0,0,0,0,0' m$
2010-06-13 23:59:00 -- Connect, 10.10.0.2
2010-06-14 00:15:29 -- Disconnect,  session upload: '789663,145478,0,0,0,0,0,0,0,0' session download: '4416532,7728144,0,0,0,0,0,0,0,0' mont$
2010-06-14 00:17:35 -- Connect, 10.10.0.2
2010-06-14 00:17:37 -- Disconnect,  session upload: '1146,0,0,0,0,0,0,0,0,0' session download: '33434,0,0,0,0,0,0,0,0,0' month upload: '1277$
2010-06-14 00:20:25 -- Connect, 10.10.0.2

[Kucher2]

Небесный, Я видел похожий глюк, когда у клиента был включен брандмауэр Windows и когда были большие потери пакетов на маршруте между клиентом и сервером (китайский кабель, будь он неладен - сменил на Одессу потом).

[Небесный]

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

[madf]

ещё заметил такую вещь, была всего раза 2 за последние 2-3 месяца, stg работает, авторизатор и конфигуратор подключается, правила создаются, но ниодного байта не пропускается, помогает исключительно рестарт биллинга

А чем перехватывается трафик?

[madf]

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

Вполне может быть. При нажатии "Отключиться" отсылается DISCONN_SYN, и если он теряется - отключения не происходит.

[madf]

ещё заметил такую вещь, была всего раза 2 за последние 2-3 месяца, stg работает, авторизатор и конфигуратор подключается, правила создаются, но ниодного байта не пропускается, помогает исключительно рестарт биллинга

а каким местом stg по вашему вообще связан с "пропуском трафика"?

Если перехват с IPQ - то непосредственно.

 

можно ли как исправить уход в нирвану стг после отваливания мускула?

Да, но достаточно сложно.

Если кто-то возьмется - рекомендую посмотреть как это сделано в mod_store_postgresql.

 

А почему мускул должен вообще отваливаться?

Например если он на удаленном хосте.

[nightfly]

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

кхм-кхм

 

Давайте промолчу?

[nightfly]

1. Если перехват с IPQ - то непосредственно.

2. Например если он на удаленном хосте.

 

1. Еще бы divert вспомнили. Я правда не могу придумать ни единой причины по которой их можно и нужно использовать на скоростях более 10 мбит.

2. Попахивает извращением - в отсутствии 100% надежности БД в которой собственно деньги и хранятся если уж на то пошло. Сложно представить себе адекватное поведение старгейзера которому некуда написать деньги/стату в таком случае. Вот что он должен с ними делать? Сохранять несохраненные данные в лог для последующего ручного анализа и акуратно самокиллалиться?

 

Выглядит точно так же как и рассмотрения "адекватного поведения старгейзера" в случае пропажи электропитания или скажем отгорания винта.

[madf]

1. Если перехват с IPQ - то непосредственно.

2. Например если он на удаленном хосте.

 

1. Еще бы divert вспомнили. Я правда не могу придумать ни единой причины по которой их можно и нужно использовать на скоростях более 10 мбит.

2. Попахивает извращением - в отсутствии 100% надежности БД в которой собственно деньги и хранятся если уж на то пошло. Сложно представить себе адекватное поведение старгейзера которому некуда написать деньги/стату в таком случае. Вот что он должен с ними делать? Сохранять несохраненные данные в лог для последующего ручного анализа и акуратно самокиллалиться?

 

Выглядит точно так же как и рассмотрения "адекватного поведения старгейзера" в случае пропажи электропитания или скажем отгорания винта.

Держать в памяти (как он это и делает большую часть времени) и делать попытки пересоединения.

Собсно так он себя и ведет если пропадает связь с PostgreSQL и (не уверен) так-же с FireBird.

[nightfly]

1. Если перехват с IPQ - то непосредственно.

2. Например если он на удаленном хосте.

 

1. Еще бы divert вспомнили. Я правда не могу придумать ни единой причины по которой их можно и нужно использовать на скоростях более 10 мбит.

2. Попахивает извращением - в отсутствии 100% надежности БД в которой собственно деньги и хранятся если уж на то пошло. Сложно представить себе адекватное поведение старгейзера которому некуда написать деньги/стату в таком случае. Вот что он должен с ними делать? Сохранять несохраненные данные в лог для последующего ручного анализа и акуратно самокиллалиться?

 

Выглядит точно так же как и рассмотрения "адекватного поведения старгейзера" в случае пропажи электропитания или скажем отгорания винта.

Держать в памяти (как он это и делает большую часть времени) и делать попытки пересоединения.

Собсно так он себя и ведет если пропадает связь с PostgreSQL и (не уверен) так-же с FireBird.

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

[Kucher2]

Позвольте узнать, почему попытка сохранить данные со стороны биллинга - должна вызывать иронию? Или ему правильнее сразу "отвалиться" по этому поводу?

[nightfly]

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

Не, попытка дело благородное. Иронию вызывает ни что иное как сам факт отваливания базы.

[Ork Yason]

факт отваливания базы - возможен...

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

 

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

 

подобное было на стг с ФБ... в эпоху героической борьбы с 17млн транзаций в день, Максим в курсе... из-за постоянных блокировок, были проблемы с БД... оно жаловалось в лог... но продолжало работать...

[yKpon]

ещё заметил такую вещь, была всего раза 2 за последние 2-3 месяца, stg работает, авторизатор и конфигуратор подключается, правила создаются, но ниодного байта не пропускается, помогает исключительно рестарт биллинга

а каким местом stg по вашему вообще связан с "пропуском трафика"?

Если перехват с IPQ - то непосредственно.

да, через IPQ

[yKpon]

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

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