Stg-2.406

[keshaLG 5]

......1.5 Гб - это совсем не много, у меня почти 200 Гб ...

и сколько стартует СТГ на ней времени? у меня получилось:

2010-03-06 04:03:47 -- Storage plugin: postgresql_store v.1.2. Loading successfull.
2010-03-06 04:05:48 -- Users started successfully.

после 10ти дней работы, вообще один процесс postgres залочил таблицу stat-ов.

попытался остановить СТГ в логах :

2010-03-16 11:49:42 -- Cannot write stat for user natalka.

2010-03-16 11:49:42 -- ERROR: character 0xbe of encoding "WIN1251" has no equivalent in "MULE_INTERNAL"

 

2010-03-16 11:49:50 -- Cannot write stat for user toxa.

2010-03-16 11:49:50 -- ERROR: canceling statement due to user request

 

2010-03-16 11:49:52 -- Cannot write stat for user vbondar.

2010-03-16 11:49:52 -- ERROR: character 0xbe of encoding "WIN1251" has no equivalent in "MULE_INTERNAL"

ну убил все, слил дамп, пересоздал базу с нуля.

Время старта плагина уменьшилось до 2х сек.

вот теперь сижу и думаю, как будет корректней проапгрейдиться?

А то такими глюками, как-то в "продакшн" не хочется лезть... и Вообще "оно" себя чувствует под нагрузкой?

[madf 279]

......1.5 Гб - это совсем не много, у меня почти 200 Гб ...

и сколько стартует СТГ на ней времени? у меня получилось:

2010-03-06 04:03:47 -- Storage plugin: postgresql_store v.1.2. Loading successfull.
2010-03-06 04:05:48 -- Users started successfully.

после 10ти дней работы, вообще один процесс postgres залочил таблицу stat-ов.

попытался остановить СТГ в логах :

2010-03-16 11:49:42 -- Cannot write stat for user natalka.

2010-03-16 11:49:42 -- ERROR: character 0xbe of encoding "WIN1251" has no equivalent in "MULE_INTERNAL"

 

2010-03-16 11:49:50 -- Cannot write stat for user toxa.

2010-03-16 11:49:50 -- ERROR: canceling statement due to user request

 

2010-03-16 11:49:52 -- Cannot write stat for user vbondar.

2010-03-16 11:49:52 -- ERROR: character 0xbe of encoding "WIN1251" has no equivalent in "MULE_INTERNAL"

ну убил все, слил дамп, пересоздал базу с нуля.

Время старта плагина уменьшилось до 2х сек.

вот теперь сижу и думаю, как будет корректней проапгрейдиться?

А то такими глюками, как-то в "продакшн" не хочется лезть... и Вообще "оно" себя чувствует под нагрузкой?

Сколько стартует уже не помню, аптайм 147 дней. Если залочить таблицу (например VACUUM FULL) Stargazer не сможет в нее ничего писать. Но будет продолжать нормально работать. И после того как таблица разлочится он все необходимое в нее запишет. Нагрузка в этом сегменте небольшая, всего 200 онлайнеров в пике. По этому Stargazer "кушает" около 7% проца, а PostgreSQL либо в нулях либо около 14% в зависимости от того что там происходит. Для быстрого доступа к данным добавил индексы на fk_user и from_time в таблицу tb_detail_stat.

База такая накопилась с сентября (или августа) прошлого года.

[Cayz 0]

Недавно перешёл с версии stg-2.402.9.7 на stg-2.406 (методом обновления только библиотек и бинарников командой "install-bin" ). После обновления обнаружил проблему, которую описывали уже в этой ветке (win конфигуратор не обновляет поле "Баланс" и поля "D "направление"" )...

 

Мой "хинт" перестает работать, когда начинается новый месяц . Вот другой фикс в конфигураторе, вроде как 3 месяца без глюков http://depositfiles.com/ru/files/i70bbmh2g, при этом в сервере можно всё вернуть обратно.

Ну там на самом деле проблема на стороне плагина. Точнее даже на стороне самого Stargazer'а

Может это и проблема, но у меня получилось, что не проблема, а на оборот. Использовал эту фичу с обновлением по другому, теперь любые изменения аккаунтов в таблице обновлятся сразу после изменения, нет необходимости давить кнопку refresh. Очень кстати удобно.

[morfey 82]

Що новенького буде в авторизаторі в 2.407 ?

[madf 279]

Недавно перешёл с версии stg-2.402.9.7 на stg-2.406 (методом обновления только библиотек и бинарников командой "install-bin" ). После обновления обнаружил проблему, которую описывали уже в этой ветке (win конфигуратор не обновляет поле "Баланс" и поля "D "направление"" )...

 

Мой "хинт" перестает работать, когда начинается новый месяц . Вот другой фикс в конфигураторе, вроде как 3 месяца без глюков http://depositfiles.com/ru/files/i70bbmh2g, при этом в сервере можно всё вернуть обратно.

Ну там на самом деле проблема на стороне плагина. Точнее даже на стороне самого Stargazer'а

Может это и проблема, но у меня получилось, что не проблема, а на оборот. Использовал эту фичу с обновлением по другому, теперь любые изменения аккаунтов в таблице обновлятся сразу после изменения, нет необходимости давить кнопку refresh. Очень кстати удобно.

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

Хотя такое возможно только если при внесении изменений произойдет ошибка но конфигуратору уйдет ответ что все ок.

[madf 279]

Що новенького буде в авторизаторі в 2.407 ?

В авторизаторі? Думаю нічого. Буду просувати qia.

[morfey 82]

Правильно

 

Доречі в нас в мережі з'являється багато лінуксоїдів, так що qia потрібен )

[slavakil 0]

Здравствуйте!

Недавно начал пользоваться Stg-2.406.....

Начались какие то проблемы...

Работает неделю норма...потом растет нагрузка на проц...на сервак пинг ужасный...перезагрузил...опять неделя норма...

Вчера обнаружил авторизатор inetaccess Ver. 2.61.8 написал сам сообщение "Incorrect request DISCONN_SYN" сразу начоло глючить пропал инет....перезагрузил опять норма..!

Что это такое и как с ним бороться!

Помогите! Заранее спасибо!

[madf 279]

Здравствуйте!

Недавно начал пользоваться Stg-2.406.....

Начались какие то проблемы...

Работает неделю норма...потом растет нагрузка на проц...на сервак пинг ужасный...перезагрузил...опять неделя норма...

Вчера обнаружил авторизатор inetaccess Ver. 2.61.8 написал сам сообщение "Incorrect request DISCONN_SYN" сразу начоло глючить пропал инет....перезагрузил опять норма..!

Что это такое и как с ним бороться!

Помогите! Заранее спасибо!

О такой проблеме известно и она уже решена. Ждите релиза.

[keshaLG 5]

а у кого уже "продакшн", нельзя ли патч выложить?

[madf 279]

а у кого уже "продакшн", нельзя ли патч выложить?

Проще выложить текущий срез исходников. Если надо - могу заслать на почту.

[napTu 4]

>>О такой проблеме известно и она уже решена. Ждите релиза.

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

 

madf, а проблема с обнулением некторых файлов stat и conf текстовой(файловой) БД, при падении STG, уже решена?

 

Еще вы кому то обещали помочь со сборкой sgconf_xml, если не затруднит, подшаманьте пожалуйста http://icenet.net.ua/sgconf_xml.tar.gz, в частности для freebsd

у меня почему то останавливается на

gmake: *** Нет правила для сборки цели `blowfish.h', требуемой для `common.o'. Останов.

...добавляю...

т.к. обнаружилось что новый sgconf совместим со старым STG, то необходимость в sgconf_xml отпадает

[madf 279]

>>О такой проблеме известно и она уже решена. Ждите релиза.

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

 

madf, а проблема с обнулением некторых файлов stat и conf текстовой(файловой) БД, при падении STG, уже решена?

 

Еще вы кому то обещали помочь со сборкой sgconf_xml, если не затруднит, подшаманьте пожалуйста http://icenet.net.ua/sgconf_xml.tar.gz, в частности для freebsd

у меня почему то останавливается на

gmake: *** Нет правила для сборки цели `blowfish.h', требуемой для `common.o'. Останов.

...добавляю...

т.к. обнаружилось что новый sgconf совместим со старым STG, то необходимость в sgconf_xml отпадает

Ну опции RemoveBak и ReadBak модуля store_files никто не отменял. Хотя в определенных случаях и они могут слажать.

Никак не доходят руки сделать по нормальному. К стати, каким бы троллем не был vop, но по этому вопросу он совершенно прав.

 

По поводу релиза. У вас есть возможность ускорить его. Людей как всегда не хватает. Так что если есть опыт в программировании - можно подключиться к разработке

 

sgconf_xml погляжу. Но думаю что после релиза он будет больше не нужен

[keshaLG 5]

второй вопрос по использованию StoreModule-я "store_postgresql":

 

попрежнему обкатываю новый релиз (2.406) под centos 5 (у него postgresql 8.1.18),

заметил, что в базе все события, в частности сессии юзеров, пишутся с отставанием на 3 часа:

[root@stg httpd]# psql -U user -d stg -q -c "(Select * from tb_detail_stats ORDER BY from_time DESC )"|less
pk_detail_stat | fk_user | dir_num |       ip        | download | upload |  cost  |      from_time      |      till_time
----------------+---------+---------+-----------------+----------+--------+--------+---------------------+---------------------
          3424 |     263 |       0 | 72.233.69.4     |     3999 |   5516 | 0.0000 | 2010-04-11 11:10:00 | 2010-04-11 11:20:00
          3425 |     263 |       0 | 91.198.36.16    |     7503 |   5194 | 0.0000 | 2010-04-11 11:10:00 | 2010-04-11 11:20:00
          3426 |     263 |       0 | 194.0.88.26     |  1289193 | 153154 | 0.0055 | 2010-04-11 11:10:00 | 2010-04-11 11:20:00

Когда на сервер в данный момент времени, время и часовой пояс выставлен правильно:

[root@stg httpd]# date
Вск Апр 11 14:23:16 EEST 2010
[root@stg httpd]#

Пробывал в postgresql.conf вписать: timezone = 'Europe/Helsinki' - не помогло.

Уважаемое community подскажите, куда рыть?

 

PS STG в свой лог пишет правельное время...

Самое интересное, то что уже в "продакшне" работает копия с этой виртуалки и там все пишет правильно)

[madf 279]

второй вопрос по использованию StoreModule-я "store_postgresql":

 

попрежнему обкатываю новый релиз (2.406) под centos 5 (у него postgresql 8.1.18),

заметил, что в базе все события, в частности сессии юзеров, пишутся с отставанием на 3 часа:

[root@stg httpd]# psql -U user -d stg -q -c "(Select * from tb_detail_stats ORDER BY from_time DESC )"|less
pk_detail_stat | fk_user | dir_num |       ip        | download | upload |  cost  |      from_time      |      till_time
----------------+---------+---------+-----------------+----------+--------+--------+---------------------+---------------------
          3424 |     263 |       0 | 72.233.69.4     |     3999 |   5516 | 0.0000 | 2010-04-11 11:10:00 | 2010-04-11 11:20:00
          3425 |     263 |       0 | 91.198.36.16    |     7503 |   5194 | 0.0000 | 2010-04-11 11:10:00 | 2010-04-11 11:20:00
          3426 |     263 |       0 | 194.0.88.26     |  1289193 | 153154 | 0.0055 | 2010-04-11 11:10:00 | 2010-04-11 11:20:00

Когда на сервер в данный момент времени, время и часовой пояс выставлен правильно:

[root@stg httpd]# date
Вск Апр 11 14:23:16 EEST 2010
[root@stg httpd]#

Пробывал в postgresql.conf вписать: timezone = 'Europe/Helsinki' - не помогло.

Уважаемое community подскажите, куда рыть?

 

PS STG в свой лог пишет правельное время...

Самое интересное, то что уже в "продакшне" работает копия с этой виртуалки и там все пишет правильно)

Затрудняюсь как-то это прокомментировать

[den68 0]

а у кого уже "продакшн", нельзя ли патч выложить?

Проще выложить текущий срез исходников. Если надо - могу заслать на почту.

 

Пришли мне пожалуйста.

 

Давно не заглядывал, по этому хочу спросить:

как в текущем билде обстоит работа с:

1. радиусом (надежность, версии радиуса с которыми работает)

2. mysql модуль не переписывали

- ?

[madf 279]

а у кого уже "продакшн", нельзя ли патч выложить?

Проще выложить текущий срез исходников. Если надо - могу заслать на почту.

 

Пришли мне пожалуйста.

 

Давно не заглядывал, по этому хочу спросить:

как в текущем билде обстоит работа с:

1. радиусом (надежность, версии радиуса с которыми работает)

2. mysql модуль не переписывали

- ?

Из изменений по радиусу только исправления сборки под FreeBSD. FreeRADIUS второй ветки все еще не поддерпживается.

MySQL не трогал.

[keshaLG 5]

...

1. радиусом (надежность, версии радиуса с которыми работает)

...

завел под Centos 5 cо штатным радиусом:

[root@stg stargazer]# rpm -q freeradius
freeradius-1.1.3-1.5.el5_4

что заметил тоже (как писалось тут ):

"общение" pptpd+freeradius-а с STG происходит как-то медленно... в моем случае:

Apr 19 09:37:36 stg pppd[3829]: Connect: ppp0 <--> /dev/pts/1
Apr 19 09:37:44 stg pppd[3829]: MPPE 128-bit stateless compression enabled

т.е. 8 сек и это на тестовой системе, которая простаивает... интересно, что же будет под нагрузкой и как можно это дело оптимизировать?

[den68 0]

т.е. 8 сек и это на тестовой системе, которая простаивает... интересно, что же будет под нагрузкой и как можно это дело оптимизировать?

 

Шифрование убери для начала...

[den68 0]

Из изменений по радиусу только исправления сборки под FreeBSD. FreeRADIUS второй ветки все еще не поддерпживается.

MySQL не трогал.

 

Спасибо, пришли плз. на почту текущий билд, попробуем медленно на него ...

[keshaLG 5]

Шифрование убери для начала...

Простите, а зачем???

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

 

Ну допустим убрал, и?

...
Apr 19 12:34:51 stg pppd[4449]: Connect: ppp0 <--> /dev/pts/3

Apr 19 12:34:59 stg pppd[4449]: local  IP address 172.17.17.1
Apr 19 12:34:59 stg pppd[4449]: remote IP address 172.17.17.200
Apr 19 12:34:59 stg pppd[4449]: pptpd-logwtmp.so ip-up ppp0 test 10.9.2.2

 

Те же 8 сек авторизации... Подчеркиваю, сервер еще без нагрузки!

[madf 279]

Из изменений по радиусу только исправления сборки под FreeBSD. FreeRADIUS второй ветки все еще не поддерпживается.

MySQL не трогал.

 

Спасибо, пришли плз. на почту текущий билд, попробуем медленно на него ...

stg-2.407-rc1

[madf 279]

Шифрование убери для начала...

Простите, а зачем???

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

 

Ну допустим убрал, и?

...
Apr 19 12:34:51 stg pppd[4449]: Connect: ppp0 <--> /dev/pts/3

Apr 19 12:34:59 stg pppd[4449]: local  IP address 172.17.17.1
Apr 19 12:34:59 stg pppd[4449]: remote IP address 172.17.17.200
Apr 19 12:34:59 stg pppd[4449]: pptpd-logwtmp.so ip-up ppp0 test 10.9.2.2

 

Те же 8 сек авторизации... Подчеркиваю, сервер еще без нагрузки!

Наверное, имелось в виду не MPPE а шифрование протокола обмена данными между плагином со стороны FreeRADIUS и STG.