Jump to content

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


Recommended Posts

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

 

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

 

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

 

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

 

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

 

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

 

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

Link to post
Share on other sites

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

 

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

Link to post
Share on other sites
На 2.406-rc1 такое тоже наблюдается?

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

 

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

Link to post
Share on other sites

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

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

Link to post
Share on other sites

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

 

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

Link to post
Share on other sites

к стати да, интересует адекватная работа нескольких подключенных конфигураторов

Link to post
Share on other sites

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

Link to post
Share on other sites
  • 4 weeks later...

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

 

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

Link to post
Share on other sites
в этом релизе - то же самое.

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

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

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

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

 

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

 

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

Link to post
Share on other sites
У тебя 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

Link to post
Share on other sites

А вобще хоть в одном из скриптов используется?

 

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

Link to post
Share on other sites
А вобще хоть в одном из скриптов используется?

 

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

 

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

 

<Module conf_sg>

 

Port = 4445

 

</Module>

 

<Module conf_sg>

 

Port = 4447

 

</Module>

 

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

 

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

Link to post
Share on other sites
Попробуй

 

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

Link to post
Share on other sites
Теоретически возможна.

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

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

 

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

 

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

 

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

 

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

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

Link to post
Share on other sites

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

 

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, что в общем-то понятно. как я понимаю таки модуль конфигуратора?

Link to post
Share on other sites

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

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

Link to post
Share on other sites

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

 

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

 

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

 

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

Link to post
Share on other sites

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

res = listen(listenSocket, 0);

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

Link to post
Share on other sites
Попробуй в плагине конфигуратора в файле rsconf.cpp в строке 119:

res = listen(listenSocket, 0);

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

 

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

Link to post
Share on other sites

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

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...