nickmas Опубликовано: 7 июня, 2010 Опубликовано: 7 июня, 2010 Отключил модуль cap_ether - нагрузка на проц упала до 2-6 % вместо 25-50%. Но народ по прежнему выкидывает. Еще вопрос: если stargazer поставить в стороне от общего потока инетрнет трафика на отдельном серваке, поможет ли это разрешить ситуацию?
madf Опубликовано: 7 июня, 2010 Опубликовано: 7 июня, 2010 Попробуй собрать в отладочном режиме и посмотреть что он будет в консоль писать. Количество юзеров тут не при чем. Вынесение Stargazer'а из общего трафика мысль правильная, но тут она вряд-ли поможет, т.к. потерь пакетов и лагов по ним я не вижу.
nickmas Опубликовано: 7 июня, 2010 Опубликовано: 7 июня, 2010 Попробуй собрать в отладочном режиме и посмотреть что он будет в консоль писать. Количество юзеров тут не при чем. Вынесение Stargazer'а из общего трафика мысль правильная, но тут она вряд-ли поможет, т.к. потерь пакетов и лагов по ним я не вижу. Ни разу не собирал в отладочном режиме. Подскажи команду, пожалуйста.
madf Опубликовано: 7 июня, 2010 Опубликовано: 7 июня, 2010 Попробуй собрать в отладочном режиме и посмотреть что он будет в консоль писать. Количество юзеров тут не при чем. Вынесение Stargazer'а из общего трафика мысль правильная, но тут она вряд-ли поможет, т.к. потерь пакетов и лагов по ним я не вижу. Ни разу не собирал в отладочном режиме. Подскажи команду, пожалуйста. $ build debug $ make Можно запускать прямо из сборочного каталога, но тогда в конфиге нужно прописать путь к плагинам в сборочном каталоге и перед запуском устанавливать LD_LIBRARY_PATH=../../lib А можно сделать sudo make install-bin и запускать ка обычно. Но нужно иметь в виду что при этом stargazer не становится дэмоном и начинает сыпать в консоль лог, о котором я и говорил. Так что в скрипты запуска имеет смысл добавить перенаправление вывода в файл и оператор & в конце.
yKpon Опубликовано: 8 июня, 2010 Опубликовано: 8 июня, 2010 можно ли как исправить уход в нирвану стг после отваливания мускула?
madf Опубликовано: 8 июня, 2010 Опубликовано: 8 июня, 2010 можно ли как исправить уход в нирвану стг после отваливания мускула? Да, но достаточно сложно. Если кто-то возьмется - рекомендую посмотреть как это сделано в mod_store_postgresql.
yKpon Опубликовано: 13 июня, 2010 Опубликовано: 13 июня, 2010 ещё заметил такую вещь, была всего раза 2 за последние 2-3 месяца, stg работает, авторизатор и конфигуратор подключается, правила создаются, но ниодного байта не пропускается, помогает исключительно рестарт биллинга
Небесный Опубликовано: 13 июня, 2010 Опубликовано: 13 июня, 2010 ещё заметил такую вещь, была всего раза 2 за последние 2-3 месяца, stg работает, авторизатор и конфигуратор подключается, правила создаются, но ниодного байта не пропускается, помогает исключительно рестарт биллинга Странно, за два месяца с лихом ни одного случая такого небыло - может причина не в СТГ?
yKpon Опубликовано: 13 июня, 2010 Опубликовано: 13 июня, 2010 Странно, за два месяца с лихом ни одного случая такого небыло - может причина не в СТГ? не исключаю возможно файрволл, но что с ним может быть? всё работает и не трогается, состояние файрволла перепроверял 10 раз когда висело, все правила правильные
nightfly Опубликовано: 13 июня, 2010 Опубликовано: 13 июня, 2010 ещё заметил такую вещь, была всего раза 2 за последние 2-3 месяца, stg работает, авторизатор и конфигуратор подключается, правила создаются, но ниодного байта не пропускается, помогает исключительно рестарт биллинга а каким местом stg по вашему вообще связан с "пропуском трафика"? можно ли как исправить уход в нирвану стг после отваливания мускула? Да, но достаточно сложно. Если кто-то возьмется - рекомендую посмотреть как это сделано в mod_store_postgresql. А почему мускул должен вообще отваливаться?
Небесный Опубликовано: 13 июня, 2010 Опубликовано: 13 июня, 2010 Вот и я на что-то уже похожее напоролся, сказать однозначно что это СТГ не могу. Дело было так. Запустил авторизатор, подключился - проработал где-то часа наверное 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 Опубликовано: 14 июня, 2010 Опубликовано: 14 июня, 2010 Небесный, Я видел похожий глюк, когда у клиента был включен брандмауэр Windows и когда были большие потери пакетов на маршруте между клиентом и сервером (китайский кабель, будь он неладен - сменил на Одессу потом).
Небесный Опубликовано: 14 июня, 2010 Опубликовано: 14 июня, 2010 Может быть, потому что использую технологию Доксис - тут потеря пакетов это привычное дело. Но, первый случай словил такой у себя на работе - а рабочий комп от сервака в метрах 2-х.
madf Опубликовано: 14 июня, 2010 Опубликовано: 14 июня, 2010 ещё заметил такую вещь, была всего раза 2 за последние 2-3 месяца, stg работает, авторизатор и конфигуратор подключается, правила создаются, но ниодного байта не пропускается, помогает исключительно рестарт биллинга А чем перехватывается трафик?
madf Опубликовано: 14 июня, 2010 Опубликовано: 14 июня, 2010 Может быть, потому что использую технологию Доксис - тут потеря пакетов это привычное дело. Но, первый случай словил такой у себя на работе - а рабочий комп от сервака в метрах 2-х. Вполне может быть. При нажатии "Отключиться" отсылается DISCONN_SYN, и если он теряется - отключения не происходит.
madf Опубликовано: 14 июня, 2010 Опубликовано: 14 июня, 2010 ещё заметил такую вещь, была всего раза 2 за последние 2-3 месяца, stg работает, авторизатор и конфигуратор подключается, правила создаются, но ниодного байта не пропускается, помогает исключительно рестарт биллинга а каким местом stg по вашему вообще связан с "пропуском трафика"? Если перехват с IPQ - то непосредственно. можно ли как исправить уход в нирвану стг после отваливания мускула? Да, но достаточно сложно. Если кто-то возьмется - рекомендую посмотреть как это сделано в mod_store_postgresql. А почему мускул должен вообще отваливаться? Например если он на удаленном хосте.
nightfly Опубликовано: 14 июня, 2010 Опубликовано: 14 июня, 2010 Может быть, потому что использую технологию Доксис - тут потеря пакетов это привычное дело. Но, первый случай словил такой у себя на работе - а рабочий комп от сервака в метрах 2-х. кхм-кхм Давайте промолчу?
nightfly Опубликовано: 14 июня, 2010 Опубликовано: 14 июня, 2010 1. Если перехват с IPQ - то непосредственно. 2. Например если он на удаленном хосте. 1. Еще бы divert вспомнили. Я правда не могу придумать ни единой причины по которой их можно и нужно использовать на скоростях более 10 мбит. 2. Попахивает извращением - в отсутствии 100% надежности БД в которой собственно деньги и хранятся если уж на то пошло. Сложно представить себе адекватное поведение старгейзера которому некуда написать деньги/стату в таком случае. Вот что он должен с ними делать? Сохранять несохраненные данные в лог для последующего ручного анализа и акуратно самокиллалиться? Выглядит точно так же как и рассмотрения "адекватного поведения старгейзера" в случае пропажи электропитания или скажем отгорания винта.
madf Опубликовано: 14 июня, 2010 Опубликовано: 14 июня, 2010 1. Если перехват с IPQ - то непосредственно. 2. Например если он на удаленном хосте. 1. Еще бы divert вспомнили. Я правда не могу придумать ни единой причины по которой их можно и нужно использовать на скоростях более 10 мбит. 2. Попахивает извращением - в отсутствии 100% надежности БД в которой собственно деньги и хранятся если уж на то пошло. Сложно представить себе адекватное поведение старгейзера которому некуда написать деньги/стату в таком случае. Вот что он должен с ними делать? Сохранять несохраненные данные в лог для последующего ручного анализа и акуратно самокиллалиться? Выглядит точно так же как и рассмотрения "адекватного поведения старгейзера" в случае пропажи электропитания или скажем отгорания винта. Держать в памяти (как он это и делает большую часть времени) и делать попытки пересоединения. Собсно так он себя и ведет если пропадает связь с PostgreSQL и (не уверен) так-же с FireBird.
nightfly Опубликовано: 14 июня, 2010 Опубликовано: 14 июня, 2010 1. Если перехват с IPQ - то непосредственно. 2. Например если он на удаленном хосте. 1. Еще бы divert вспомнили. Я правда не могу придумать ни единой причины по которой их можно и нужно использовать на скоростях более 10 мбит. 2. Попахивает извращением - в отсутствии 100% надежности БД в которой собственно деньги и хранятся если уж на то пошло. Сложно представить себе адекватное поведение старгейзера которому некуда написать деньги/стату в таком случае. Вот что он должен с ними делать? Сохранять несохраненные данные в лог для последующего ручного анализа и акуратно самокиллалиться? Выглядит точно так же как и рассмотрения "адекватного поведения старгейзера" в случае пропажи электропитания или скажем отгорания винта. Держать в памяти (как он это и делает большую часть времени) и делать попытки пересоединения. Собсно так он себя и ведет если пропадает связь с PostgreSQL и (не уверен) так-же с FireBird. так и представил себе картину - окровавленый старгейзер истекая кровью памятью героически бореться за существование. Прямо все по Дарвину
Kucher2 Опубликовано: 14 июня, 2010 Опубликовано: 14 июня, 2010 Позвольте узнать, почему попытка сохранить данные со стороны биллинга - должна вызывать иронию? Или ему правильнее сразу "отвалиться" по этому поводу?
nightfly Опубликовано: 14 июня, 2010 Опубликовано: 14 июня, 2010 Позвольте узнать, почему попытка сохранить данные со стороны биллинга - должна вызывать иронию? Не, попытка дело благородное. Иронию вызывает ни что иное как сам факт отваливания базы.
Ork Yason Опубликовано: 14 июня, 2010 Опубликовано: 14 июня, 2010 факт отваливания базы - возможен... и судя из философии самого продукта - база данных ему нужна при запуске, чтоб считать данные, и в последствии для записи изменений, на случай внезапной "смерти" стг а потому вариант, что БД вдруг исчезло, и стг - от этого поплохело - не верный... он должон пытацо соединицо... а если не получилось, то героически пытацо дальше... на непосредственную ее работу - подсчет траффика это не должно влиять подобное было на стг с ФБ... в эпоху героической борьбы с 17млн транзаций в день, Максим в курсе... из-за постоянных блокировок, были проблемы с БД... оно жаловалось в лог... но продолжало работать...
yKpon Опубликовано: 14 июня, 2010 Опубликовано: 14 июня, 2010 ещё заметил такую вещь, была всего раза 2 за последние 2-3 месяца, stg работает, авторизатор и конфигуратор подключается, правила создаются, но ниодного байта не пропускается, помогает исключительно рестарт биллинга а каким местом stg по вашему вообще связан с "пропуском трафика"? Если перехват с IPQ - то непосредственно. да, через IPQ
yKpon Опубликовано: 14 июня, 2010 Опубликовано: 14 июня, 2010 а потому вариант, что БД вдруг исчезло, и стг - от этого поплохело - не верный... он должон пытацо соединицо... а если не получилось, то героически пытацо дальше... на непосредственную ее работу - подсчет траффика это не должно влиять пусть даже после некоторого времени когда у него кончится место в памяти пусть героически падает, но не сразу же после падения связи с мускулом
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВойти
Уже зарегистрированы? Войдите здесь.
Войти сейчас