madf

Еще, какая версия конфигуратора использовалась? Наблюдалась ли эта проблема с конфигуратором предыдущей версии?

Что такое "внезапный стоп"?

Жаждаю подробностей. Какая версия, какое хранилише используется? Я так понимаю все эти изменения делает какой-то скрипт? Может это он бочинит? И чем конвертировалось?

Как-то так: if [ "$param" = "tariff" ]; then export LANG=en_US.UTF-8 /etc/stargazer/plugins/sgconf/sgconf set -s 127.0.0.1 -p 5555 -a ******* -w ****** -u $login -m 'Уважаемый пользователь, ваш тариф '$oldValue', был изменен на '$newValue fi (ес-сно, вместо en_US.UTF-8 подставить свою локаль).

Собрать отладочную версию, сделать ulimit -c unlimited, воспроизвести баг, получить core-файл и заслать его мне вместе с бинарниками на faust@stg.dp.ua

sgconf пытается сконвертировать текст из текущей локали. Возможно что общесистемно локаль не установлена. Попробей сделать export LANG=<your_locale> перед вызовом конфигуратора.

Я то что, оно само ведь прошло. Жаль, конечно, что не удалось причину зунать.

Можно сделать нулевую абонку в тарифе, а в полночь кроном запускать скрипт который будет пробегать по всем пользователям и либо грепом из log (файловая база), либо запросом из tb_sessions_log проверять наличие коннектов за сегодня и снимать абонку в "ручном" режиме. Если нужна зависимость от тарифов - еще в тарифы заглядывать.

Такс. Я в этой версии конфигуратор не ломал, только ремонтировал. Проверь что у тебя от старой версии плагинов не осталось. И библиотек. И опиши свою конфигурацию. Патчи никакие на исходники не накладывал?

Можно тупо написать плагин в котором поставить нотификаторы на изменение freeMb и отключать/включать юзера. К стати очень простой плагин, даже без внутреннего потока. Буквально 2-3 функции. И будет вам реалтаймовость и все такое.

подозреваю что увидеть их можно только при помощи sgconfxml либо нативным конфигуратором. Есть чувствие что --d0 берет данные не из базы, хотя нада сорц посмотреть. Не из базы. Из памяти. Это ж данные за сессию, а не месячные.

Ну, это конечно гон уже писать раз в минуту стату. madf, не могли бы вы немного рассказать как СТЖ держит в памяти данные о трафике, и как можно было бы эти данные вытянуть - чисто для личного развития. Отчего ж не рассказать, раскажу. Очень просто держит. В приватных членах класса USER - шаблонных переменных типа USER_PROPERTY<тип> (см. user_property.h). Из методов класса USER (см. user.h) доступ можно получить непосредственно по именам, как это, например, сделано в методе записи статистики: int USER::WriteStat() { STG_LOCKER lock(&mutex, __FILE__, __LINE__); USER_STAT us; us.up = up; us.down = down; us.cash = cash; us.freeMb = freeMb; us.lastCashAdd = lastCashAdd; us.lastCashAddTime = lastCashAddTime; us.passiveTime = passiveTime; us.lastActivityTime = lastActivityTime; printfd(__FILE__, "USER::WriteStat()\n"); if (store->SaveUserStat(us, login)) { WriteServLog("Cannot write stat for user %s.", login.c_str()); WriteServLog("%s", store->GetStrError().c_str()); printfd(__FILE__, "Cannot write stat for user %s.\n", login.c_str()); printfd(__FILE__, "%s\n", store->GetStrError().c_str()); return -1; } lastWriteStat = stgTime; return 0; } (перемнные up, down, cash. freeMb, и т.д.). "Снаружи", из методов других классов доступ можно получить через публичный член класса property (см. user_property.h), используя методы Get и Set. Например: user_iter u; if (users->FindByName("vasya_pupkin", &u)) { return -1; } double cash = u->property.cash.Get(); u->property.freeMb.Set(100, currAdmin, "vasya_pupkin", store, "100 грн на шару!"); currAdmin - указатель на переменную типа ADMIN (см. admin.h), описывающую админа который получил доступ к системе. store - указатель на переменную класса BASE_STORE (см. base_store.h), предоставляющую интерфейс к БД. Последний параметр у Set - текстовый комментарий к изменению. Добавлю, что данные о трафике (up и down) представлены типами DIR_TRAFF (см. user_traff.h), представляющими собой класс-обертку над массивом типа uint64_t[DIR_NUM], где DIR_NUM - максимальное количество направлений тарификации в системе.

Очень даже логично - и тогда это решает вопрос с тем, что порог у тарифных планах разные. Но, вот как для красоты сделать, чтобы четко рубало при достижении порога. madf, если я не ошибаюсь, стж изначально держит трафик в памяти, потом при записи в стату - память обнуляется? Идея - но для этого нужно реализовывать отдельный процесс, которые будет всегда следить за трафиком - и этот же процесс будет рубать пользователя. Держит в памяти и не обнуляет при записи. Обнуляет в момент перехода через полночь или при отключении авторизатора. И то - только за сессию. Месачный обнуляется при переходе через месяц. Зачем отдельный? Stargazer и так следит за трафиком.

Для реалтайма надо установить нотификатор на изменения property.freeMb и при переходе через 0 выполнять действия. Но это значительное вмешательство в код. И да, он действительно пишет в соответстсвии со StatWritePeriod. И на 500 нормально, и на 6000 нормально. В т.ч. нормально на файловой базе и на PostgreSQL. По MySQL у меня данных нет, но думаю что и там нормально.

возникла мысль find-ом лазить в файл stat пользователя (БД - файловая). при достижении величины больше тарифного плана, то отключать пользователя. но как поступать, когда несколько тарифных планов с разной "абонплатой/объём трафика"? ЗЫ: я так понимаю ни у кого такой задачи не стояло. т.е. все (или большинство) просто продают трафик помегабайтно. у нас просто схема предоплаты 1го числа за определенный объём, а сверх лимита очень быстро деньги убегают. Зачем так сложно? В stat есть поле FreeMb. Сравниваем его с нулем и принимаем решение.

Это где? На сервере? На клиенте? Опишите топологию сети более детально. Где какие адреса и как они маршрутизируются в узловых точках.

Чесно говоря, ни разу такого не наблюдал. Если повторяется регулярно - прошу прислать бектрейсы отладочной сборки в момент проявления бага. Получить их можно так: $ gdb /path/to/stargazer (gdb) attach <pid_of_stargazer> ... (gdb) thread apply all bt (gdb) quit И прислать выхлоп мне на мыло: faust@stg.dp.ua. Попробую разобраться.

Вроде ничего не придумывается кроме как по крону опрашивать список на предмет отсутствия FreeMB и делать им disable. Ну еще можно подпатчить метод IsInetable в файле user.cpp чтобы он срабатывал по этому признаку.

Эта связка у нас используется на самом маленьком сервере в тестовом режиме уже почти год. В базе всего 900 юзеров, пиковый онлайн где-то 300 юзеров. Детальная статистика пишется для 76% онлайновых пользователей (отключена у большинства безлимитчиков). Раньше писалась для всех. Момент когда начали отключать установить не удалось, по этому тут данные не очень достоверные. Сейчас в базе данные начиная с 1 января 2010 года. База занимает 112 Гб на диске. Из них 96 Гб - таблица детальной статистики. В базу добавлено 3 дополнительных индекса по полям: tb_sessions_data.fk_session_log tb_detail_stats.fk_user tb_detail_stats.from_time Так же из базы убран один лишний индекс, ключ и поле: tb_detail_stats.pk_detail_stat (рекомендую это и для пользователей FireBird). Таблица детальной статистики содержит 361186726 записей. Время выполнения типичного запроса на получение детальной статистики составляет от 300 до 400 мс. Сам запрос: SELECT tb_detail_stats.from_time, MAX(tb_detail_stats.till_time) AS till_time, tb_detail_stats.dir_num, SUM(tb_detail_stats.download) AS download, SUM(tb_detail_stats.upload) AS upload, SUM(tb_detail_stats.cost) AS cost FROM tb_detail_stats WHERE tb_detail_stats.fk_user = (select pk_user from tb_users where name='*****') AND tb_detail_stats.from_time >= '2010-04-04 21:00:00' AND tb_detail_stats.from_time <= '2010-04-05 20:59:59' GROUP BY tb_detail_stats.from_time, tb_detail_stats.dir_num ORDER BY tb_detail_stats.from_time ASC, tb_detail_stats.dir_num ASC; (да, знаю, там лучше использовать BETWEEN но это не влияет на время выполнения запроса). СУБД тюнилась по параметрам: shared_buffers = 384MB maintenance_work_mem = 256MB max_fsm_pages = 16000000 checkpoint_segments = 15 effective_cache_size = 1024MB "Ест" примерно 400 Мб оперативки. База пережила битые сектора на диске и миграцию на новый практически без простоя.

Подозреваю проблемы с маршрутизацией. А вообще неплохо было бы знаки препинания расставлять, а то смысл не очень доходит. Ну и на предложения разбивать

Каждый день.

Это проблема самого конфигуратора.

Любой меньше 2. Например 1.5.

rlm_stg поставляемый со Stargazer'ом не совместим с FreeRADIUS ветки 2

По поводу правил: файрвол расположен на одном сервере с биллингом или используется rscriptd?