Лoги stargazer (Cannot.Couldn`t и Error)

[DarkLan]

1. Error: Bind admin socket failed

На форуме уже поднимался этот вопрос. Решается, как все сказали при помощи замены порта на админа.

или численные shutdown. Не один с вариантом устроит кого либо не может, и меня в том числе.

 

2. Cannot write stat for user

После остановки stargazer пишет вот такое. Что это значит - понятно, а вот почему оно возникает - нет.

 

3. Couldn`t save user stat

Еще одно интересное явления...

 

4. Admin "admin" ip: User "nameuser": "disabled" paramete

Этот лог вообще убил. Не имеет значения, отключил пользователя или нет - результат тот же. (ну и понятно, что пользователь сидит далее в Инете, игнорируя админа с бубеном...).

[madf]

1. Возникает только в двух случаях:

• запуск после аварийного останова;
  
• запуск второй копии Stargazer.
  

Я, конечно, могу сделать SO_SOCK_REUSE (или как там тот параметр называется), но считаю что это аварийная, неправильная ситуация. По этому не делаю.

 

2. Возникает потому что невозможно записать данные в базу.

3. Надо глянуть кто такое пишет. Должно быть Cannot save user's stat или что-то такое. По идее 2 и 3 идут последовательно. Первый от плагина БД, второй от ядра системы.

4. Вопроса не понял. Что за проблема с этим сообщением?

[RIt]

использую MySQL и вот тоже заметило о ошибке: Cannot write stat for user

 

чего не хватает? пароли правильны, права назначены на бд.

[madf]

Мало ли чего там MySQL не хватает... Я давно говорю о том что mod_store_mysql используйте на свой страх и риск.

[RIt]

Что рекомендуем? мы все время юзали мускул.

[madf]

Что рекомендуем? мы все время юзали мускул.

Если SQL даром не нужен - файлы. На сегодня это самое быстрое, безгеморройное, компактное и производительное решение. Но по ним сложно делать аналитику.

Если нужен SQL и сеть небольшая (скажем, до 1000 абонов) - FireBird. Сравнительно быстрая и надежная СУБД. Будет занимать больше места чем файлы, работать медленнее, требовать присмотра. Но предоставляет SQL и, как следствие, любую аналитику какая только в голову взбредет. При должном "уходе" будет нормально работать и в больших сетях.

Если нужен SQL и сеть большая (скажем, более 1000 абонов) - PostgreSQL. На сегодня самая "мощная" из открытых/свободных СУБД. Занимает больше места чем файлы, производительность целиком зависит от настройки. Требует грамотного "ухода" и постоянного присмотра.

 

Впрочем, если детальная статистика не пишется (или регулярно чистится) то и FireBird и PostgreSQL будут работать одинаково хорошо даже без дополнительной настройки и не требовать особых "телодвижений".

[RIt]

спасибо за дельный совет. хоть база и меньше 1000аб, попробуем PostgreSQL. Настройками разберемся. При подключению stargazer проблем не возникает? все работает и настраивается как на Mysql ? вопросы детские, но лучше спросить перед подготовкой дискуссией с дирекцией.

[nightfly]

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

 

Cannot write stat for user

Давайте угадаю - у вас linux. Очевидно бубунто-дебиано образный. Там изначально больной mysql-client. Лечится пересборкой.

[Alexey Osipov]

Cannot write stat for user

Давайте угадаю - у вас linux. Очевидно бубунто-дебиано образный. Там изначально больной mysql-client. Лечится пересборкой.

 

Во имя справедливости дополнительно сообщаю: бывают исключения из правил. Ubuntu Server 10.04, штатный mysql, stargazer, работает нормально. Правда размер базы даже до 100 пользователей не дотягивает.

[madf]

спасибо за дельный совет. хоть база и меньше 1000аб, попробуем PostgreSQL. Настройками разберемся. При подключению stargazer проблем не возникает? все работает и настраивается как на Mysql ? вопросы детские, но лучше спросить перед подготовкой дискуссией с дирекцией.

По подключению не возникает.

Но настраивается иначе. Начнем с того что mod_store_mysql сам создает свои таблицы, а для mod_store_postgresql нужно сперва создать структуру базы с помощью прилагаемого sql-файла. Далее, сервер MySQL обычно не требует какой-либо настройки после установки, а сервер PostgreSQL желательно настроить, т.к. настройки по умолчанию рассчитаны на запуск на любом оборудовании. Например на мобильном телефоне. Естественно, у вас на сервере оперативной памяти побольше будет чем в мобильнике, значит и параметры стоит подкрутить. Оно, конечно, и так будет работать, но может тормозить. О том какие параметры и как подкрутить есть десятки статей в инете.

Nightfly тут пугает страшными аббревиатурами, но он не совсем прав. В случае если база небольшая, дополнительный мониторинг и обслуживание, обычно, не требуется.

[RIt]

Давайте угадаю - у вас linux. Очевидно бубунто-дебиано образный. Там изначально больной mysql-client. Лечится пересборкой.

 

"бубунто или деб" использую только на ПК робочих. на шлюзе стоит freebsd 8.2 R. Обновляться думаем до S, может в этом заморочка.

[RIt]

...

 

данке, майн либе фрайнд

[nightfly]

2 madf

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

Если база небольшая - до 10-20к абонентов, отлично справляется и мускуль при правильном подходе, который называется "не трогать его руками" и "дотянуть индексы".

 

2 RIt

на шлюзе стоит freebsd 8.2 R. Обновляться думаем до S, может в этом заморочка.

Нет. Как показывает практика на BSD все как правило работает "изкоробки" вполне успешно. До скажем 5к абонентов можно как правило не утруждать себя заглядыванием в my.cnf. Для начала включите slow_query_log - и посмотрите не уходит ли просто ваш мускуль в астрал банально забивая на кверизы от тоже больноватого store_mysql. Возможно стоит посмотреть в каком контексте у вас идут операции с мускулем и добавить индексов по полям которые участвуют в where. Также можно попробовать покрутить на скорую руку key_buffer-ы и его родственников. К сожелению вынужден признать, что store_mysql действительно "слегка больноват" и возможно стоит как-то минимизировать использование конфигураторов stargazer до минимума - тогда точно все будет хорошо в этой жизни.

 

if(MysqlSetQuery(res.c_str()))
{
errorStr = "Couldn't save user stat:\n";
// errorStr += mysql_error(sock);
return -1;
}

Как бы намекает.

 

В случае если вы действительно массивно пишете детальную статистику и база пухнет гигами то постгря начинает выглядеть единственным адекватным решением. И нет - нормальный DBA тогда таки уже нужен.

 

2 Alexey Osipov

 

Во имя справедливости дополнительно сообщаю: бывают исключения из правил. Ubuntu Server 10.04, штатный mysql, stargazer, работает нормально. Правда размер базы даже до 100 пользователей не дотягивает.

Да, бывают случайности, видел таковые

 

[madf]

2 madf

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

Если база небольшая - до 10-20к абонентов, отлично справляется и мускуль при правильном подходе, который называется "не трогать его руками" и "дотянуть индексы".

...

Да я ж не против, просто не рекомендую - во избежание вопросов "А чего оно Couldn't save user stat"

[nightfly]

"А чего оно Couldn't save user stat"

Ну дык явственно и з куска кода выше следует откуда оно - если СУБД настолько чем-то взволнована, что манала отвечать на соединения - это уже проблема. Да.

У себя такое помниться видел только когда мускуль тупо грохнулся по количеству коннектов от кривого цикла.