Перейти до

проблемк с КК (sgconf)


Рекомендованные сообщения

каждый месяц сталкиваемся с некоторыми проблемами с КК. хотел бы спросить народ - может кто что подскажет.

 

ну вопервых - всем известно что если дважды попробовать обновить виндовый конфигуратор - на одной машине выйдет шиш. редко это еще и падением вылазит (2.405, файловая БД). в этом плане можно надеятся на исправление столь печального недостатка? знаю обсуждалось когда-то, но все же. (вариант с мускулом и веб не предлагать - что-то отзывов хороших очень мало о стабильности такой связки)

 

при попытке отправить во время обновления еще и какие-то параметры на запись через sgconf (далее КК),вылазит фактически тоже самое.

 

что больше всего огорчает - у нас довольно сложная система скриптов дергающая КК довольно часто. к примеру в начале месяц (вот сейчас , собсвенно :blink: ) пользователям без денег ставится спец тариф, передается параметр записи в одно из полей UserData, меняется Passive. Все это длает КК при участии внутренней логики СТГ (ну например у нас есть тарифы freez и virus, которые так или иначе конфигурируют ACL на свитчах и информируют о статусе пользователя через виндовый конфигуратор, и пожно заморозить человека по собственному желанию, если выбрать ему тариф freez "в следующем месяце"... так что привязка к работе с тарифами СТГ - оевидна) .

 

поскольку в это же время (в начале месяца) начинают менятся тарифы и сниматься за них денюжка, на каком-то этапе СТГ подвисает, часто с отпаданием доступа конфигуратора в любом виде. при этом процес авторизации и аутентификации (ровно как и скрипты коннекта и дисконнекта) - прекрасно работают дальше.

 

империческим путем замечено что происходит такое подвисание на этапе орудования КК. что в виду его поведения с обычным конфигуратором и проблем при одновременной работе двух виндовых конфигураторов, наводит на мысль о связанности данных проблем. так как одновременно могут выполнятся несколько процессов с КК, или по чистой случайности КК конфликтует с внутренними отработками самого СТГ... в общем догадки :)

 

отсюда вопрос - что делать? откуда ноги у проблемы? и есть ли способ ее полечить?

Ссылка на сообщение
Поделиться на других сайтах

Ага тоже заметил такой еффект при работе одновременно КК и виндового. Особо не заморачивался и как решение принял отказ от виндового конфигуратора :blink:

 

PS "нестабильно" работающая связка веб+мускуль успешно и стабильно без единого вылета работает тьфу-тьфу уже около года на пригруженной машине.

Ссылка на сообщение
Поделиться на других сайтах
На 2.406-rc1 такое тоже наблюдается?

в продакшин не запускали, сейчас только готовимся. в общем причина действительно в том что стг перестает общаться на порту конфигуратора. у КК есть такое понятие как таймаут? мне показалось что вродь нет, так как пытаясь отправить что либо стг через КК в таком "подвисшем" состоянии не получаю ни ОК ни какой либо ошибки, тупо висит...

 

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

Ссылка на сообщение
Поделиться на других сайтах

stg работает с конфигуратором по TCP (тайм-аут, соответственно, TCP-шный) и в 1 поток. То есть - не более одного соединения одновременно. Отсюда ростут ноги у проблем с одновременной работой разных конфигураторов.

2.406 падать не должна. Если все-таки будет - будем разбираться. По идее если конфигуратор пытается приконнектиться к stg в то время как с ним уже общается другой - он должен реджектиться. Завтра посмотрю что там и как.

Ссылка на сообщение
Поделиться на других сайтах

дык фактически не падает (точнее очень редко), а вот не общается по порту управления - это почти на верняка при таком стресс-тесте. еще , к слову, удаление пользователя через виндовый КК из трех раз 1 раз удалит. иногда роняет стг...

 

а можно ли как-то обойти ограничение в один КК ? (кроме очевидного написания своей или использования чужой альтернативной морды)

Ссылка на сообщение
Поделиться на других сайтах

Ограничение можно попробовать обойти указав в конфиге несколько конфигураторов на разных портах. По идее должно работать, но сам я не пробовал :)

Ссылка на сообщение
Поделиться на других сайтах
  • 4 weeks later...

в этом релизе - то же самое.

 

причина для меня ясна. на этом сервере у меня нет возможности включить несколько stg-exec довольствуюсь только одним, и во время отработки тарифов СТГ никого и ничего не желает слушать, пока не закончит. корни этой проблемы - в невозможности работать нескольких конфигураторов на одном порту. попробуем sgconf повесить на другой )

Ссылка на сообщение
Поделиться на других сайтах
в этом релизе - то же самое.

Тоже падает? Тогда попрошу сделать корку и выслать мне вместе со всеми бинарниками на faust@stg.dp.ua

причина для меня ясна. на этом сервере у меня нет возможности включить несколько stg-exec довольствуюсь только одним, и во время отработки тарифов СТГ никого и ничего не желает слушать, пока не закончит. корни этой проблемы - в невозможности работать нескольких конфигураторов на одном порту. попробуем sgconf повесить на другой )

А при чем тут stg-exec? Он просто скрипты выполняет и к конфигуратору никакого отношения не имеет.

Ссылка на сообщение
Поделиться на других сайтах
Тоже падает? Тогда попрошу сделать корку и выслать мне вместе со всеми бинарниками на faust@stg.dp.ua

 

А при чем тут stg-exec? Он просто скрипты выполняет и к конфигуратору никакого отношения не имеет.

 

нет-нет, по падениям еще рано говорить - пока небыло. я имел в виду ту же проблему с зависанием намертво sgconf'a. при чем екзекутор? если бы их использовать больше - подвиснут только процессы которым звезды стали неудачно (точнее которые одновременно попытались получить доступ к конф-порту) при этом, как я уже писал, sgconf просто виснет намертво. ни ошибок, ни ОК, ничего (помните, я еще спрашивал о таймаутах). Грубо говоря при должном количестве екзекуторов (10 например) может случиться 10 таких ошибок, которые будут обнаружены поправлены не мешая общему "процессу 1-го числа". ну и еще руки не дойдут попробовать еще один порт конфигуратору открыть и sgconf повесить на него (не думаю, правда, что это хоть сколь-либо поможет)

Ссылка на сообщение
Поделиться на других сайтах
У тебя sgconf используется в скриптах OnConnect/OnDisconnect?

нет пришлось лотказаться в виду упомянутой проблемы, но в зависимости от разных условий может вызываться sgconf при операциях с клентами (заморозка\разморозка), пополнение счета и т.д.

 

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

 

вот к примеру для понимания что у нас происходит:

 

./sw1: line 279: 6523 Убито /etc/stargazer/sgconf set -s 127.0.0.1 -p 4445 -a xxx -w yyy -u Peter --ud9 optimal_30 >>/m_ban_debug.log

./sw1: line 280: 6656 Убито /etc/stargazer/sgconf set -s 127.0.0.1 -p 4445 -a xxx -w yyy -u Peter -t freeze:now >>/m_ban_debug.log

./sw1: line 284: 6678 Убито /etc/stargazer/sgconf set -s 127.0.0.1 -p 4445 -a xxx -w yyy -u Petrolium --ud9 optimal_30 >>/m_ban_debug.log

./sw1: line 285: 6769 Убито /etc/stargazer/sgconf set -s 127.0.0.1 -p 4445 -a xxx -w yyy -u Petrolium -t freeze:now >>/m_ban_debug.log

Ссылка на сообщение
Поделиться на других сайтах
А вобще хоть в одном из скриптов используется?

 

И что говорит при указании 2-х и более модулей?

 

при указании двух модулей с разными портами аля

 

<Module conf_sg>

 

Port = 4445

 

</Module>

 

<Module conf_sg>

 

Port = 4447

 

</Module>

 

не стартует ругаясь на bind fail. само собой эти порты ничем не заняты

 

хм.... или для вызова модуля (если не ошибаюсь стг пробует .so подгружать по имени модуля) если создать копию mod_conf_sg.so - ну например mod_conf_sg2.so - пройдет такой бубен?

Ссылка на сообщение
Поделиться на других сайтах
Попробуй

 

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

Ссылка на сообщение
Поделиться на других сайтах
Теоретически возможна.

Ожидать стоит.

А я и есть автор (или соавтор) :rolleyes:

 

хо-хо, поднялось ;)))) сейчас потестим на предмет двух конфигураторов, спасибо за идею.

 

а как можно пообщаться с вами по интересующему меня вопросу? окромя форума ;)

 

p.s. - шоб я всрався дэ ты взявся - РАБОТАЕТ ;))) ну конечно требуется время на выяснение всех подводных...

 

тыкс... ну в моей проблеме это все равно никак не помогло ))) это надо подымать с 10-ок конфигураторов и между ними рассыпать операции, чтоб не перескались... ну или таймауты - что неприятно - но единственное решение "прямо сейчас"... хэх :o

нда.. ниче не понимаю... вообще через sgconf не хочет ничего отправлять, ни ошибок ничего. как буд-то перестает слушать на порту, но почему тогда не отваливается сам КК по таймауту? причем на втором порту конф_модуля стг нормально работает в это же время... выходит бага в модуле конфигуратора? как оттрейсить?

Ссылка на сообщение
Поделиться на других сайтах

а нет, солгал, оно таки ругается в итоге - но очень долго

 

time /etc/stargazer/sgconf set -s 127.0.0.1 -p 4447 -a xxx -w yyy -u roma --ud9 optimal_30

Error

 

real 3m45.078s

user 0m0.008s

sys 0m0.012s

 

ндык.... что бы это могло быть? 3 минуты - это чегой-то очень уж... в логах отрыл в этот момент broken pipe со всеми вытекающими.

 

ну и Admin's connect failed. IP 127.0.0.1, что в общем-то понятно. как я понимаю таки модуль конфигуратора?

Ссылка на сообщение
Поделиться на других сайтах

Связаться со мной можно по почте (faust@stg.dp.ua) или в Jabber (madf@jabber.kiev.ua)

4 минуты? Может TCP timeout? Или-же дедлок какой-нить...

Ссылка на сообщение
Поделиться на других сайтах

4 минуты в TCP - омг. сомневаюсь :rolleyes:

 

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

 

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

 

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

Ссылка на сообщение
Поделиться на других сайтах

Попробуй в плагине конфигуратора в файле rsconf.cpp в строке 119:

res = listen(listenSocket, 0);

заменить 0 на что-то побольше. Скажем, 10.

Ссылка на сообщение
Поделиться на других сайтах
Попробуй в плагине конфигуратора в файле rsconf.cpp в строке 119:

res = listen(listenSocket, 0);

заменить 0 на что-то побольше. Скажем, 10.

 

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

Ссылка на сообщение
Поделиться на других сайтах

хм.... а если поставить к примеру 10000? или больше? чем чревато? (реально такие числа вряд ли нужны, но вот 100 - вполне достижимо даже сейчас в начале месяца, если я правильно понимаю смысл этой переменной) это, как я понимаю, количество сокетов, грубо говоря буффер на поступающие операции?

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

×
×
  • Створити нове...