~AsmodeuS~

данная функция уже морально устарела так как в системе существует механизм восстановления потерянных сессий ну кому то ж было написано http://abills.net.ua/wiki/doku.php/abills:docs:rlm_perl:ru#freeradius_2x Обратите внимание При использовании rlm_perl не изолируйте строковые пары RADIUS кавычками в секциях тарифных планов и серверов доступа.

Что бы это реализовать, надо как минимум альтернативный opensource продукт с поддержкой и много времени. И самый главный нюанс, что бы разработчик не дорабатывал продукт, который хотят форкнуть. Так что Abills это не грозит. Надеемся только на улучшения продукта, безопасные обновления, высокую производительность. ну как удалось еще что то найти ?

Вы забыли добавить "Обновите биллинг!".)))) можно просто проверить что изменилось если не хотите обновлять или патч загрузить с git или просто помедитировать может само пофиксится

Дедлок не должен появляться. Ибо лок вызывается только в auth.pm, в одном месте кода, и сразу на всю таблицу сессий. А дедлок вылезает в acct.pm - где нет ни локов, ни транзакций, ибо нет сложных операций. проблема оказалась на много тривиальней и связана было с innodb уже поправлено

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

Auth.pm из вашего cvs. только за этот год более 10 раз был изменён так что нужно конкретную дату Auth.pm из вашего cvs. То есть проблеме имеет место быть. Диадлок будет появляться и это очевидно, или я что то не так понимаю. да подтвердилось на старом опенсорсном дистрибутиве буду тестировать и отпишись по ситуации

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

http://search.cpan.org/search?query=AnyEvent+mysql&mode=allhttps://www.npmjs.org/search?q=mysql http://twistedmatrix.com/documents/current/core/howto/rdbms.html https://code.google.com/p/go-wiki/wiki/SQLDrivers Все давно переписано. Вообще разговор ни о чем уже. Вы с чего-то вдруг решили, что планировщик на sql костылях - это нормально. Пилите, имеете проблемы, но продолжаете жрать кактус. Ваше дело. Но это говнокод и ламерство. Асмодеус, вы такой программист, как я балерина, молчали бы уже Да уже заметили что программирование вы учили в балетной школе. Предполагаю что В

На 2к согласен, даже может на 3к, только последствия после лавинообразных авторизаций будут! проверил у себя 25 независимых потоков в каждом по 100 000 запросов не одного дедлока, думаю проблема где то у Вас просьба выслать мне Auth.pm так будет легче найти ошибку

Из этой темы и показанных костылей Если нет логики в СУБД, то при нормальной работе в СУБД должны только сохраняться конфиг/пулы/изменения_в_пулах раз в сколько-то секунд и все. Покажите статус процесса радиус сервера, на select/epoll/kqueue висит? Если да, то он асинхронный. Если у вас не упирается в СУБД, то это далеко не большие нагрузки Но речь сейчас не об этом, а о том, что неадекватно реализовано, из-за чего локи, пиление и прочие проблемы даже на микронагрузках. мне одному кажется что это полная чушь не одно из Ваших высказываний не выдерживает и малешей критики. Все у

Так а что неправильно с точки зрения клиентов? Они заплатили деньги за то, что вы поставите им НОРМАЛЬНО сервак с биллингом. ВЫ им собрали с исходников, а далее они админят дистр по МАНУАЛУ от создателей дистра и попадают на проблемы с вашими собранными радиусами.Так в чем они виноваты? Повторюсь, вам нужно всего лишь выкатать инсталяху на 2 основных дистра и усё! при попытке обновить дистр - неразрешенные зависимости. и пробовать трогать это - страшно! (так же как и обновлять биллинг). исходя из Вашей логики все прекомпилированные биллинговые системы зло потому что нельзя обновить си

И? А логика зачем-то в СУБД. Очень умно. Точнее, большего маразма трудно представить (а вообще я не смотрел радиус, может он там через одно место писан, с prefork моделью, а не асинхронно, потому маленький сервис может быть очень хорошей идеей) ждём ваше решение как это нужно сделать

Вынести раздачу адресов в отдельный сервис или это слишком сложно для асмодеусов? Задача вообще-то совсем не для СУБД и использовать СУБД в качестве планировщика ресурсов - тот еще маразм. о все как раз ждали Ваш профффесиональный подход, а ну покажите как же это сделать

тут немного другой принцип заносятся все адреса по одной записи в таблицу а что делает этот блок ? `u`.`lastBlock` <= %s

Что интересно - образовываться ему там не с чего, транзакций явных нет... так вот по этому и интересно

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

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

или кто то где то о них читал, так как пока не подтверждены. Если бы они были их очень просто найти в ABillS кстати

Альтернативы? Ну кроме заведения отдельной таблицы для всех адресов пулов, и апдейта записей в ней (что чревато)? А с чего бы ему образовываться? Как еще гарантировать атомарность выделения ип адреса? SQL процедурой, выполняющей идентичные действия в которой тоже будет использоваться лок таблицы? Ну и да, 2к онлайна без особого напряга тянет тазик 5-летней давности с 2-головым атлоном... не обращайте внимание я думаю это всё просто предположения пока нет ни одного факта что будет плохо, а тем более как сделать оптимальней. Если бы были то можно было бы на стенде протестиро

Чукча не читатель, чукча писатель. Вы читали выше о блокировке адресов на определённое время после авторизации? Самокритика это позитивно, только есть куча нюансов 1 время блокировки записи большое между авторизацией и аккаунтингом более 0.05 секунду 2 вы делаете 2 раза идентичные запросы к базе 1 во время авторизации а потом во время аккаунтинга чтобы получить данные абонента 3 некоторые сервера доступа (cisco,juniper) отправляют Start и сразуже Alive и иногда выходит ситуация что алайв быстрее обрабатывается чем стоп и еще много нюансов насчёт обновления если админы не могу

Получается, что вы даже не пытались. А достаточно 2 дистра основных проверить - и все.А в результате имеем сервак, который хрен обновишь, потому что кому что-то лень делать. Это похоже на профессионализм? Это у вас такая "реклама"? Ну сессия создается при авторизации, занимая ип. Если аккаунтинг не пришел - сессия умирает. Если я ничего не попутал в алгоритме (давно ковырял код). А должна создаваться при первом Accounting.Когда-то с этим была проблема; был даже от тебя патч. У я себя решил так: есть с IP-адресами, где записывается время последней выдачи адреса. Адрес считается

Ну сессия создается при авторизации, занимая ип. Если аккаунтинг не пришел - сессия умирает. Если я ничего не попутал в алгоритме (давно ковырял код). А должна создаваться при первом Accounting.Когда-то с этим была проблема; был даже от тебя патч. У я себя решил так: есть с IP-адресами, где записывается время последней выдачи адреса. Адрес считается свободным, если его нет в dv_calls и последняя выдача была больше n секунд назад. Таблица полностью сразу заполняется адресами и update-ится только время выдачи. Из всех рассмотренных вариантов этот оказался самым быстрым. Коллизии возможны, н

Получается, что вы даже не пытались. А достаточно 2 дистра основных проверить - и все. Мы пытались но список дистрибутивов не вели так как ситуация когда не стратует или после обновление все просто падает, а клиенты в большинстве случаев не разбераются в проблеме, а сразу наезд идёт что все плохо биллинг не работает и все и клиент звонит 10 раз в "час что всепропало" потом оказывается он просто переустановил биллинг или обновил его и не посмотрел как все собрано. И это у каждого 3 клиента с линуксом такая ситуация. И выходило что по пару часов день нужно просто объяснять клиентам чт

во всех дистрах такое ? (centos, debian, ubuntu). в дебиан и в убунту так в других были прицеденты но точно не могу сказать, решили во всех линуксах по одному образцу делать

dv_calls не наполняется... dv_log - да, но туда записи попадают уже сильно опосля... Давно появился сброс клиентов с дублирующимися адресами? Я что-то не замечал такого в коде... CentOS - все прекрасно работает искаропки. Debian - тоже все завелось искаропки в более-менее актуальной версии (в старых типа 0.51 - там да, радиус крашился по причине того что используются глобальные переменные типа $db, в то время как $db должна быть уникальной для каждого потока). 1 проверка дубликатов ИП появилась ее летом billd смотрите 2 было более десятка прицидентов по этому