kvant-v

Я увидел один серьёзный недостаток собственного решения, Патч с текущими цифрами не позволит в полной мере использовать возможности "ExecutersNum" с большими значениями. Хотя всё будет работать маленькая очередь станет слабым местом системы Ну а с большими цифрами снова создастся опасность переполнения очереди. вопрос снят.

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

Интересная особенность патча, не смотря на значение параметра равного 1 while (data.msg_qnum > 1) //цикл ожидания освобождения очереди до заданного значения заполненности последовательность пуска скриптов выглядит так: 3 скрипта OnConnect соответствующие 3-ём OnConnect скрипты OnChange 3 следующих OnConnect соответствующие 3-ём следующим OnConnect скрипты OnChange ..... ..... На самом деле так и должно быть, первый скрипт OnConnect сразу забирается из очереди на выполнение, второй заполняет очередь до 1 и только третий заполняет очередь до 2 что по условию активирует приост

Мне всё-таки удалось , благодаря помощи Madf, создать патч применение которго позволяет использовать в пусковых скриптах sgconf get и set при кол-ве юзеров always online более 60. Может кому-то пригодится, а может когда-нибудь и в релиз попадёт . Патч добавляет новую функцию в плагин "always online autorizator", которая не даёт очереди скриптов переполниться или опустеть. функция представляет собой управляемую, паузу которая активируется и деактивируется в зависимости от состояния очереди. Функция содержит два важных параметра о значениях которых, хотелось-бы "услышать" мнение специалист

Ну это хороший конечно способ завалить старгейзер, но уж очень примитивный. Любой админ сразу поймёт почему скрипт виснет, ещё на стадии тестирования. Вот этот способ (из документации) гораздо интереснее. sgconf get -s <server> -p <port> -a <admin> -w <admin_password> -u <user> <options> sgconf set -s <server> -p <port> -a <admin> -w <admin_password> -u <user> <options>

Основная проблема текущей дефолтной очерёдности помоему как раз в сюрпризах. Изначально кажется что всё хорошо работает. Ну никак я не мог подумать что если на тестовом сервере 3 юзера работали то уже с 7 будут проблемы. И когда я решился на установку старгейзера на реальный сервер с реальным числом юзеров и уже проверенными на том тестовом сервере скриптами, вот это был сюрприз на всю ночь я долго вообще не мог понять в чём дело. Думаю многие кто шёл по моему пути на этом месте отказались от старгейзера. Но вы безусловно правы, аналогичный сюрприз для провайдера с нескольками тысячами юзеро

Nightfly, помоему это ваши слова: и затем: Нее ну против религии я конечно ничего не имею. Извините не знал. Я просто хотел сделать свой посильный вклад в развитие старгейзера, не только для себя лично. У людей ведь фантазия богатая, мало ли какой контекст у них будет. А для себя благодаря Madf и Вам я все проблемы уже решил. За что ещё раз огромное спасибо.

А помоему на этом форуме оч. много сообщений о граблях, ноги у которых на самом деле как раз из модуля "always online" растут. Например сообщения о том, что старгейзер глючит от больших скриптов. И мой опыт показал, что добиться нормального выполнения "больших скриптов" вполне реально. Конечно код там присутствует и он делает "тонны" полезной для меня работы. И если код скриптов без ошибок то какие причины для отказа его выполнения ? Помоему максимум плохого что должно быть от больших скриптов это снижение быстродействия. Вопрос к Madf: приемущества от смены порядка запуска м

Не успел вчера дописать самое интересное. После того как удалось изменить порядок запуска старт прошёл быстро и без единого сбоя, тогда я для краш теста скопировал запрос sgconf get 10 раз и снова пуск без единого сбоя, Мой костыль впервые оказался не задействованным при запуске. Такое кол-во запросов было эквивалентно запуску 600 юзеров моей системы. Тогда я решил проверить как будут обстоять дела с записью параметров sgconf set Добавил один запрос sgconf set с двумя ключами - и получил зависание уже на втором юзере ! Убрал 9 лишних запросов sgconf get оставив 1, снова зависение

Это то-что надо ! Madf, спасибо огромное ! Я бы месяц это искал, даже не думал, что последовательность пуска модулей внутри их самих. У меня вчера мозгов хватило только на то, чтобы поменять местами в main.cpp строки modules.sort(StartModCmp) и modules.sort(StopModCmp) что привело к полной обратной последовательности пуска-останова доп. модулей и могло иметь плохие последствия. Но мой кривой способ всё-же позволил мне вчера провести эксперимент который я повторил сегодня уже в нормальном варианте: И так напомню, проблемы с получением данных через gconf в OnConnect начинались с у

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

Мой OnConnect используeт для получения данных sgconf На 5 юзеров всё было ОК. После увеличения числа юзеров always online до семи первые два при запуске не могли получить данные грешил на модуль mysql поставил костыль в виде циклического перезапроса данных в случае не удачи, временно проблема решилась. Сейчас при достижении кол-ва юзеров always online 60 проблема появилась снова и выглядит так : при бесконечном цикле перезапроса данных в случае не удачи - сервер зависает судя по логам на старте модуля "Always Online autorizator v.1.0" точнее зависает наверно скрипт OnConnect, а сер