~AsmodeuS~

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 было более десятка прицидентов по этому

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

хм. а когда мы были у вас на ком поддержке (где то год-полтора назад), об этом скрипте никто ничего не сказал/не сделал..... возможно у Вас было какое то другое решение этой проблемы

Вот за это убивать надо. во первых из исходников собирается только одна программа и то только на линуксе это freeradius, а собирается она потому что perl собран в дистрибутиве с потоками а freeradius без потоков, так что с убийством обращайтесь к создателям дистрибутивов

Ммм, я говорил таблица пустая. Наполним, будем смотреть. Да её вообще нужно не выключать, а включать по желанию! А то она вроде есть, жрёть, а не гавкаэ, то есть её не пользуются. Сюда мы обязательно дойдём, ой там интересного... 25к душ, 2 года хранить dv_log чуть более мелкого ISP. к dv_log, нужен не архивный доступ. Да. Я не хотел вас обидеть, не критикуйте меня строго. Я бы не критиковал ваш продукт, если бы им не пользовался. В любом случае, данное обсуждение даст начало, к реализадии более качественного продукта. Никто не сомневается, что вы

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

Как это - не отпускает? Как только сессия попадает в зап - все, юзер может коннектиться снова. В зап она попадает после N потерянных алайвов. Один минус - удаляется из запа целиком она всего после 2*N алайвов, я прикрутил себе патчик чтобы в запе она висела Y алайвов (доп.переменная конфига), на случай прерывания связи между биллингом и насами/остановки биллинга на профилактику... Дело в том, что если падает нас, то сессии уходят вместе с ним. Если при этом его быстро поднять, то окажется что сессии висят на нем до сих пор. Причем еще и не запнутые, а юзеры в это время досят насы.

Как это - не отпускает? Как только сессия попадает в зап - все, юзер может коннектиться снова. В зап она попадает после N потерянных алайвов. Один минус - удаляется из запа целиком она всего после 2*N алайвов, я прикрутил себе патчик чтобы в запе она висела Y алайвов (доп.переменная конфига), на случай прерывания связи между биллингом и насами/остановки биллинга на профилактику... ком версия восстанавливает самостоятельно потерянные сессии