Билинг для 300-500 абонентов.

[~AsmodeuS~ 34]

 

Альтернативы? Ну кроме заведения отдельной таблицы для всех адресов пулов, и апдейта записей в ней (что чревато)?

Вынести раздачу адресов в отдельный сервис или это слишком сложно для асмодеусов?

 

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil"

И даже если вдруг оказалось что база стала узким местом - сперва лучше оптимизировать саму базу.

Задача вообще-то совсем не для СУБД и использовать СУБД в качестве планировщика ресурсов - тот еще маразм.

 

 

 

о все как раз ждали Ваш профффесиональный подход, а ну покажите как же это сделать

[Abram 98]

 

Мне кажется, можно обойтись каким-нибудь атомарным select for update. Или быстренько заблокировать, select-нуть, update - обозначить, что этот адрес используется, и unlock.

Кстати, насчет моей таблицы с используемыми IP: благодаря ей у меня получилось обойтись без вот такой конструкции (перебор занятых IP адресов):

for (my $i = 0 ; $i <= $#pools_arr ; $i++) {
    %pool = %{ $pools_arr[$i] };
    foreach my $ip (@$list) {
      if (exists($pool{ $ip->[0] })) {
        delete($pool{ $ip->[0] });
        $self->{USED_IPS}++;
      }
    }
    last if (scalar(keys %pool) > 0);
  }

  my @ips_arr = keys %pool;
  my $assign_ip = ($#ips_arr > -1) ? $ips_arr[ rand($#ips_arr + 1) ] : undef;

Вместо этого у меня так:

SELECT
  *
FROM
  (SELECT
     `u`.`ip`
   FROM `ipUsage` `u` JOIN `ippools` `p` ON `p`.`id` = `u`.`poolid`
     LEFT JOIN `dv_calls` `c` ON `c`.`framed_ip_address` = `u`.`ip`
     LEFT JOIN `dv_main` `dv` ON `u`.`ip` = `dv`.`ip`
   WHERE `c`.`acct_session_id` IS NULL AND `dv`.`ip` IS NULL AND `u`.`poolid` = %s AND
         `u`.`lastBlock` <= %s
   ORDER BY `p`.`priority` ASC
   LIMIT 50) data
ORDER BY RAND();

Фактически свободный IP находится за один запрос.

Да, я знаю, что ORDER BY RAND() - это плохо, но там сначала ограничивается 50 записями.

 

 

тут немного другой принцип заносятся все адреса по одной записи в таблицу

 

а что делает этот блок ?

`u`.`lastBlock` <= %s

 

Вот именно от этого принципа я у себя и отказался.

lastBlock - последнее время блокировки адреса. В %s там подставляется текущий unixtimestamp минус 60 секунд вроде бы.

 

Суть такова: при авторизации делается UPDATE ... SET lastBlock = %s (%s = timestamp), т.е. пометка, что этот ещё 60 секунд использовать нельзя. Если за 60 секунд (это я взял с запасом) сессия не появится в dv_calls - адрес уже считается свободным. Если интересно - вот полностью ф-ция: http://pastie.org/private/ir1mpbpigh1ox53f5lgw . Код на Python, там реализован только нужный мне кусочек логики, да и лока таблиц нет (надо доделать), но суть понятна.

[Abram 98]

Не совсем корректно. Приоритет пулов нечеткий получается...

Если сильно нужно - решаемо. Сам понимаешь . Відредаговано 2014-11-05 12:50:48 Abram

[ttttt 195]

Что под этим имелось ввиду?

Ну вот вместо всех этих попыток пихать логику планировщика в СУБД написать маленький сервис, который эту логику реализует и общаться с этим сервисом, а не с СУБД.

[NiTr0 584]

Ну вот вместо всех этих попыток пихать логику планировщика в СУБД написать маленький сервис, который эту логику реализует и общаться с этим сервисом, а не с СУБД.

Прекрасно. Сервис падает (OOM, глюк железа, плановый перезапуск - неважно), и поднимается немного погодя. Где брать актуальную инфу о выданных адресах? Лезть в БД, от использования которой якобы ушли?

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

 

Не, можно конечно и к примеру memcached использовать в качестве хранилища временной "таблицы" адресов, и свой нескучный велосипед напилить, но все же проблм с этим огрести можно больше, чем получить профита.

Відредаговано 2014-11-05 13:17:24 NiTr0

[ttttt 195]

Где брать актуальную инфу о выданных адресах?

Из файловой системы или даже из СУБД. Суть не в том где хранить, а где логика реализуется.

 

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

О, к чему-то пришли. В радиус сервер можно и воткнуть планировщик, а в СУБД исключительно сохранять/брать конфиг.

 

Не, можно конечно и к примеру memcached использовать в качестве хранилища временной "таблицы" адресов, и свой нескучный велосипед напилить, но все же проблм с этим огрести можно больше, чем получить профита.

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

[NiTr0 584]

 

Где брать актуальную инфу о выданных адресах?

Из файловой системы

 

Прекрасно, пилим свою нескучную СУБД, которая будет вести таблицу выделенных адресов в файле...

 

Суть не в том где хранить, а где логика реализуется.

 

О, к чему-то пришли. В радиус сервер можно и воткнуть планировщик, а в СУБД исключительно сохранять/брать конфиг.

Так вот, auth.pm - это и есть плагин радиус-сервера, который выдает адреса

[ttttt 195]

Так вот, auth.pm - это и есть плагин радиус-сервера, который выдает адреса

И? А логика зачем-то в СУБД. Очень умно. Точнее, большего маразма трудно представить

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

Відредаговано 2014-11-05 13:47:59 ttttt

[~AsmodeuS~ 34]

 

Так вот, auth.pm - это и есть плагин радиус-сервера, который выдает адреса

И? А логика зачем-то в СУБД. Очень умно. Точнее, большего маразма трудно представить

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

 

ждём ваше решение как это нужно сделать

[NiTr0 584]

И? А логика зачем-то в СУБД. Очень умно. Точнее, большего маразма трудно представить

А с чего вы взяли, что логика в СУБД?

В СУБД только хранилище активных сессий и собссно пулов. Логика вся в перле (составление карты адресов для пулов, исключение из карты адресов уже занятых сессиями, и соответственно занесение в БД новой сессии). Из-за чего и локи таблиц

 

Ну и да, в той же гидре логика в СУБД вся. Из-за чего она и применяется при больших нагрузках...

Відредаговано 2014-11-05 13:57:12 NiTr0

[ttttt 195]

А с чего вы взяли, что логика в СУБД?

Из этой темы и показанных костылей

Если нет логики в СУБД, то при нормальной работе в СУБД должны только сохраняться конфиг/пулы/изменения_в_пулах раз в сколько-то секунд и все.

 

Покажите статус процесса радиус сервера, на select/epoll/kqueue висит? Если да, то он асинхронный.

 

Ну и да, в той же гидре логика в СУБД вся. Из-за чего она и применяется при больших нагрузках...

Если у вас не упирается в СУБД, то это далеко не большие нагрузки Но речь сейчас не об этом, а о том, что неадекватно реализовано, из-за чего локи, пиление и прочие проблемы даже на микронагрузках. Відредаговано 2014-11-05 14:05:34 ttttt

[NiTr0 584]

Если нет логики в СУБД, то при нормальной работе в СУБД должны только сохраняться конфиг/пулы/изменения_в_пулах раз в сколько-то секунд и все.

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

 

Покажите статус процесса радиус сервера, на select/epoll/kqueue висит? Если да, то он асинхронный.

Обычный такой фрирадиус, ессно асинхронный.

 

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

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

[ttttt 195]

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

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

[NiTr0 584]

С какой это радости - не должно быть? Т.е. однопоточная обработка запросов в порядке очереди - это хорошая, годная практика?

Обычно есть поток-менеджер, и потоки-воркеры, на которые менеджер раскидывает задания...

[Abram 98]

С какой это радости - не должно быть? Т.е. однопоточная обработка запросов в порядке очереди - это хорошая, годная практика?

Обычно есть поток-менеджер, и потоки-воркеры, на которые менеджер раскидывает задания...

Если сервис асинхронный - то это очень годная тактика.

FreeRADIUS НЕ асинхронный и никогда им не был.

[NiTr0 584]

А в чем годнота? В отсутствии масштабируемости?

[ttttt 195]

Т.е. однопоточная обработка запросов в порядке очереди - это хорошая, годная практика?

Не совсем в порядке очереди запросов, запросы принимаются асинхронно, не блокируя другие (в том смысле, что ядро ОС продолжает заполнять буфера сокетов), а когда какой-то запрос принят, то вызывается его обработчик. Обработчик потом не отдает данные клиенту, а ложит их в буфер, которые будут не блокируясь отправлены. Всем этим заведует единый бесконечный цикл, который собирает события от ядра через select()/epoll(). Плохо я описал, без псевдокода такую архитектуру не описать, но это типичный event loop и типичное event-driven программирование. Такой код обычно проще, чем параллельный, и его производительность гораздо выше. Как когда-то давно говорил Линус - если хочешь производительность, асинхронность единственный путь

 

Обычно есть поток-менеджер, и потоки-воркеры, на которые менеджер раскидывает задания...

Нет, это изврат для IO-bound задач и ненужное чрезмерное усложнение. Потоки имеют смысл только в CPU-bound задачах. А в перл модель типа поток-менджер и потоки-воркеры по-моему вообще не встречаются из-за особенностей перл потоков, там либо event loop и все асинхронно, либо префорк/форк и обработка в дочерных процессах. Відредаговано 2014-11-05 21:44:08 ttttt

[NiTr0 584]

Нет, это изврат для IO-bound задач и ненужное чрезмерное усложнение.

А с чего вы взяли, что все упирается в i/o, а не в CPU? А главное - как предлагаете с SQL запросами быть? Мускул клиент вроде как не предлагает асинхронный обработчик. А главное - в итоге получится стремная солянка, которая крутится на одном ядре, и распараллелить которую невозможно без полного переписывания с нуля...

 

К слову, перловые потоки таки нормальные потоки. http://letsgetdugg.com/2009/04/19/fun-perl-benchmark/ в помощь если не верите. То на питоне из-за GIL с потоками грусть-печаль

[ttttt 195]

А с чего вы взяли, что все упирается в i/o, а не в CPU?

Да как-то не заметил, что там CPU кодирует mp4 на каждый запрос авторизации, все SQL запросики, СУБД, плохо смотрю?

 

А главное - как предлагаете с SQL запросами быть? Мускул клиент вроде как не предлагает асинхронный обработчик.

Дык а какая разница, что вы собираетесь выиграть от асинхронности запроса раз в 5 секунд?

 

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

Не имеет значение в реальной жизни

 

К слову, перловые потоки таки нормальные потоки.

С ними там сложная долгая история, они так и не прижились и не приживутся, вместо них прижились event loop'ы и целая масса разных асинхронных фреймворков. А вот в Питоне наоброт, даже несмотря на глобальный лок, очень много кто использует потоки по дурости, а асинхронный код там не очень популярен. Відредаговано 2014-11-05 23:58:35 ttttt

[NiTr0 584]

Да как-то не заметил, что там CPU кодирует mp4 на каждый запрос авторизации, все SQL запросики, СУБД, плохо смотрю?

Дык а кто вам сказал, что SQL - это I/O? А главное - как вы SQL асинхронным-то сделаете, если это даже I/O? Свой SQL сервер напишете, с асинхроннстью и однопоточностью?

 

Дык а какая разница, что вы собираетесь выиграть от асинхронности запроса раз в 5 секунд?

Итоги подведем: никакого i/o активного нет и в помине (запрос в 5 секунд) - значит, асинхронность в один поток есть бред.

 

Не имеет значение в реальной жизни

Для сети в 300-500 человек - да, пофиг какой говнокод А если радиус будет обрабатывать эдак 500+ запросов в секунду?

 

С ними там сложная долгая история, они так и не прижились и не приживутся, вместо них прижились event loop'ы и целая масса разных асинхронных фреймворков.

С чего бы это не прижились? Вполне себе прижились, и активно используются. В том же rlm_perl

[ttttt 195]

Дык а кто вам сказал, что SQL - это I/O? А главное - как вы SQL асинхронным-то сделаете, если это даже I/O?

Зачем? О чем разговор вообще? Я в контексте выноса логики планировщика из СУБД в отдельный сервис.

 

никакого i/o активного нет и в поминех

А куда оно делось? Гоняли себе данные туда-сюда, а вдруг перестали?

 

А если радиус будет обрабатывать эдак 500+ запросов в секунду?

Ерунда. Это скорее для "масштабируемого" многопоточного кода будет проблемой. Lock contention, блокирующие вызовы, рейсы. Вот весело кому-то будет.

[NiTr0 584]

 

 

Зачем? О чем разговор вообще? Я в контексте выноса логики планировщика из СУБД в отдельный сервис.

Логика и так в отдельном процессе. А вы предлагаете вынести из СУБД именно хранение текущего актуального состояния в отдельный процесс. Из которого запихивать данные в СУБД раз в N времени и надеяться, что процесс не упадет и сохраненные данные о состоянии не потеряются. Что есть бредом. Не, понятно, оно будет работать быстрее - но кому нужна скорость в ущерб надежности?

 

 

 

А куда оно делось? Гоняли себе данные туда-сюда, а вдруг перестали?

Куда гоняли? SQL - это не обращение к дисковой подсистеме в общем-то, уже давным-давно СУБД обзавелась кешами, из которых все и читается. А сохраняется на диск только статус. Но - да, при каждой его смене, а не раз в 5 секунд.

 

 

 

Ерунда. Это скорее для "масштабируемого" многопоточного кода будет проблемой. Lock contention, блокирующие вызовы, рейсы. Вот весело кому-то будет.

Лок в одном участке, где между получением статуса и его сохранением идет обработка данных (при этом остальные потоки ожидают, если обратились к данному участку), или глобально однопоточное приложение, где один-единственный поток молотит данные - что будет быстрее?

Даже если лок будет на весь вызов процедуры (в худшем случае из возможых) - получаем 1 работающий поток и остальные ожидающие. Т.е. - скорость, сопоставимую с "асинхронным" однопоточным приложением.

[Abram 98]

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

Да, именно это же делает ОС, если использовать потоки/процесы, но практика показала, что накладные расходы на это настолько высоки, что часто один асинхронный процес может обслужить больше клиентов, чем несколько синхронных.

 

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

[NiTr0 584]

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

Покажи мне асинхронный MySQL запрос Я что-то не припомню таковой реализации в мускуле, как и в других СУБД.

 

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

Відредаговано 2014-11-06 11:01:23 NiTr0

[Abram 98]

 

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

Покажи мне асинхронный MySQL запрос Я что-то не припомню таковой реализации в мускуле, как и в других СУБД.

 

Запрос сам по себе синхронный, но это не должно никого волновать .

Грубо говоря, соединение с MySQL - это сокет. В сокет можно написать что-то и благополучно на него забить болт до того времени, пока что-то оттуда не придёт.

В асинхронном программировании логика такова: отправил в MySQL запрос, пнул реактор (слышь ты, вот есть fd/socket, придёт чего-то вызовещь вот эту ф-цию) и всё - функция завершилась, возвращаемся в реактор. Дальше реактор запускает следующую функцию (или не запускает, если ничего не пришло ни в один fd и не сработал alarm; в таком случае реактор висит в select/epoll/итд, пока ничего не придёт). Главное здесь - не ожидать окончания каких-либо операций (будь то запрос в БД, дисковое IO, сетевое взаимодействие), а быстренько пнуть и вернуться в реактор. Реактор сам вызовет твои функции по цепочке callback-ов, когда им РЕАЛЬНО нужно будет работать и не ждать.

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

 

Примеры удачных реализаций: twisted в Python, POE в Perl, Qt, nginx, node.js.