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

sadmin · 2014-11-05 08:55:19

Мы пытались но список дистрибутивов не вели так как ситуация когда не стратует или после обновление все просто падает, а клиенты в большинстве случаев не разбераются в проблеме, а сразу наезд идёт что все плохо биллинг не работает и все и клиент звонит 10 раз в "час что всепропало" потом оказывается он просто переустановил биллинг или обновил его и не посмотрел как все собрано.

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

Так в чем они виноваты?

Повторюсь, вам нужно всего лишь выкатать инсталяху на 2 основных дистра и усё!

видите даже Вы не разобрались в ситуации а обвиняете, а если бы все таки собрали свой радиус с портов Вы бы опять потом обновили на стандарный и было бы обвинение что после обновления не работает. Хотя если честно не могу онять что у Вас с обновлением не работает, все должно чётко обновиться без проблем

при попытке обновить дистр - неразрешенные зависимости. и пробовать трогать это - страшно! (так же как и обновлять биллинг).

~AsmodeuS~ · 2014-11-05 09:41:03

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

Это похоже на профессионализм? Это у вас такая "реклама"?

IP ищется при авторизации, а вносится при первом аккаунтинге.
Ну сессия создается при авторизации, занимая ип. Если аккаунтинг не пришел - сессия умирает. Если я ничего не попутал в алгоритме (давно ковырял код).

А должна создаваться при первом Accounting.
Когда-то с этим была проблема; был даже от тебя патч.

У я себя решил так: есть с IP-адресами, где записывается время последней выдачи адреса. Адрес считается свободным, если его нет в dv_calls и последняя выдача была больше n секунд назад.

Таблица полностью сразу заполняется адресами и update-ится только время выдачи.

Из всех рассмотренных вариантов этот оказался самым быстрым. Коллизии возможны, но крайне маловероятны.

dv_calls не наполняется...

Там активные сессии и не только.

И вот пример:

mysql> explain SELECT c.framed_ip_address
    ->   FROM dv_calls c
    ->   INNER JOIN nas_ippools np ON (c.nas_id=np.nas_id)
    ->   WHERE np.pool_id in ( 1 )
    ->   GROUP BY c.framed_ip_address;
+----+-------------+-------+-------+---------------+------+---------+------+-------+-----------------------------------------------------------+
| id | select_type | table | type  | possible_keys | key  | key_len | ref  | rows  | Extra                                                     |
+----+-------------+-------+-------+---------------+------+---------+------+-------+-----------------------------------------------------------+
|  1 | SIMPLE      | np    | index | nas           | nas  | 6       | NULL |     1 | Using where; Using index; Using temporary; Using filesort |
|  1 | SIMPLE      | c     | ALL   | NULL          | NULL | NULL    | NULL | 30062 | Using where; Using join buffer                            |
+----+-------------+-------+-------+---------------+------+---------+------+-------+-----------------------------------------------------------+

А потом такие запросы

INSERT INTO dv_calls SET started=now(),
       lupdated        = UNIX_TIMESTAMP(),
       status          = '11',
       acct_session_id = 'IP',
       nas_ip_address  = INET_ATON('127.0.0.1'), tp_id='100', uid='10001', user_name='10001', framed_ip_address=167772311, nas_id='1';

И следом маленький фикс разработчика =)

unlock tables;

вот не могу понять Вы ищите куски которые Вам не нравятся ставите показываете чтобы Вам объяснили как это работает ?

1 идёт лок на запист

2 потом выборка и запись нового ип если нужно

3 анлок

можите бенчмарком прогнать сколько операций в секунду можно сделать при такой схеме, так к слову на Р4 более 50 тис. Если у Вас есть более оптимальный способ предложите

кстати хорошая реклама кто не заметил тесты показывают при 30 тис онлайн

NiTr0 · 2014-11-05 09:41:09

Вы так не шутите. Для одного запроса в секунду вернет 2-3к строк, а для 300 запросов в секунду 300*2к или 3к , то есть не мало. Не самый оптимальный алгоритм, постоянно дёргать базу, ей и так есть чем заниматься.

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

И вопрос, какова вероятность образования deadlock?

А с чего бы ему образовываться?

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

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

Ну и да, 2к онлайна без особого напряга тянет тазик 5-летней давности с 2-головым атлоном...

~AsmodeuS~ · 2014-11-05 09:50:36

Занесения адресса при аккаунтенге плохой пример, может работать у маленьких провайдеров до 1000-2000 абонентов. У провайдеров с 10 тис онлайн за время между авторизацией и аккаунтингом может пролезть десяток абонентов с уже занятыми адреса.
Чукча не читатель, чукча писатель. Вы читали выше о блокировке адресов на определённое время после авторизации?

Самокритика это позитивно, только есть куча нюансов

1 время блокировки записи большое между авторизацией и аккаунтингом более 0.05 секунду

2 вы делаете 2 раза идентичные запросы к базе 1 во время авторизации а потом во время аккаунтинга чтобы получить данные абонента

3 некоторые сервера доступа (cisco,juniper) отправляют Start и сразуже Alive и иногда выходит ситуация что алайв быстрее обрабатывается чем стоп

и еще много нюансов

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

~AsmodeuS~ · 2014-11-05 09:56:54

Вы так не шутите. Для одного запроса в секунду вернет 2-3к строк, а для 300 запросов в секунду 300*2к или 3к , то есть не мало. Не самый оптимальный алгоритм, постоянно дёргать базу, ей и так есть чем заниматься.
Альтернативы? Ну кроме заведения отдельной таблицы для всех адресов пулов, и апдейта записей в ней (что чревато)?

И вопрос, какова вероятность образования deadlock?
А с чего бы ему образовываться?

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

Ну и да, 2к онлайна без особого напряга тянет тазик 5-летней давности с 2-головым атлоном...

не обращайте внимание

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

~AsmodeuS~ · 2014-11-05 10:02:13

Дедлоки или есть (что фатально плохо), или их нет (что хорошо). Раз вы говорите о вероятности появления дедлоков, значит они есть и ваша архитектура - говно.

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

dimka88 · 2014-11-05 10:29:49

... Не самый оптимальный алгоритм, постоянно дёргать базу, ей и так есть чем заниматься.

Да ну? А разве это не задача базы - слушать вопросы и отвечать на них? Чем это ей еще заниматься?

Чем меньше запросов к базе, тем меньше шансов, что база станет узким местом.

И вопрос, какова вероятность образования deadlock?

...

Дедлоки или есть (что фатально плохо), или их нет (что хорошо). Раз вы говорите о вероятности появления дедлоков, значит они есть и ваша архитектура - говно.

Простите, но я не разрабатывал архитектур, вы меня перепутали с кем то. (Печальбеда)

вот не могу понять Вы ищите куски которые Вам не нравятся ставите показываете чтобы Вам объяснили как это работает ?

кстати хорошая реклама кто не заметил тесты показывают при 30 тис онлайн

Ужасти, 30к - это генерегка на тесте, запросы только от 1 тестового клиента, база совсем не нагружена.

dimka88 · 2014-11-05 10:39:47

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

2014-11-04 12:33:22 LOG_ERR:  [] 
UPDATE dv_calls SET
         status='1',
         started=FROM_UNIXTIME(UNIX_TIMESTAMP()), 
         lupdated=UNIX_TIMESTAMP(), 
         nas_port_id='1336', 
         acct_session_id='5458B7480DFA00', 
         CID='10.0.10.170', 
         CONNECT_INFO=''
         WHERE user_name='login1' AND nas_id='6' AND acct_session_id='IP' AND (framed_ip_address=INET_ATON('172.16.1.1') OR framed_ip_address=0) 
         LIMIT 1;
 --1213
 --Deadlock found when trying to get lock; try restarting transaction

2014-11-04 12:33:22 LOG_ERR:  [] 
UPDATE dv_calls SET
         status='1',
         started=FROM_UNIXTIME(UNIX_TIMESTAMP()), 
         lupdated=UNIX_TIMESTAMP(), 
         nas_port_id='368', 
         acct_session_id='5458B9677C4C00', 
         CID='10.0.10.222', 
         CONNECT_INFO=''
         WHERE user_name='login2' AND nas_id='7' AND acct_session_id='IP' AND (framed_ip_address=INET_ATON('172.16.10.2') OR framed_ip_address=0) 
         LIMIT 1;
 --1213
 --Deadlock found when trying to get lock; try restarting transaction

2014-11-04 13:28:20 LOG_ERR:  [] 
UPDATE dv_calls SET
         status='1',
         started=FROM_UNIXTIME(UNIX_TIMESTAMP()), 
         lupdated=UNIX_TIMESTAMP(), 
         nas_port_id='1144', 
         acct_session_id='5458C42932F700', 
         CID='10.0.10.146', 
         CONNECT_INFO=''
         WHERE user_name='login3' AND nas_id='6' AND acct_session_id='IP' AND (framed_ip_address=INET_ATON('172.16.1.7') OR framed_ip_address=0) 
         LIMIT 1;
 --1213
 --Deadlock found when trying to get lock; try restarting transaction

madf · 2014-11-05 10:44:12

... Не самый оптимальный алгоритм, постоянно дёргать базу, ей и так есть чем заниматься.

Да ну? А разве это не задача базы - слушать вопросы и отвечать на них? Чем это ей еще заниматься?

Чем меньше запросов к базе, тем меньше шансов, что база станет узким местом.

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

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

И вопрос, какова вероятность образования deadlock?

...

Дедлоки или есть (что фатально плохо), или их нет (что хорошо). Раз вы говорите о вероятности появления дедлоков, значит они есть и ваша архитектура - говно.

Простите, но я не разрабатывал архитектур, вы меня перепутали с кем то. (Печальбеда)

Раз не разрабатывали, то какого черта вы о них тут судите? "Не читал но осуждаю"? Відредаговано 2014-11-05 10:44:47 madf

~AsmodeuS~ · 2014-11-05 11:01:15

Ужасти, 30к - это генерегка на тесте, запросы только от 1 тестового клиента, база совсем не нагружена.

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

dimka88 · 2014-11-05 11:17:16

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

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

dimka88 · 2014-11-05 11:27:50

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

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

А с чего бы ему образовываться?

Я там постом выше, привел факт образования deadlock.

Ну и да, 2к онлайна без особого напряга тянет тазик 5-летней давности с 2-головым атлоном..

На 2к согласен, даже может на 3к, только последствия после лавинообразных авторизаций будут!

NiTr0 · 2014-11-05 11:27:54

я думаю это всё просто предположения пока нет ни одного факта что будет плохо

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

~AsmodeuS~ · 2014-11-05 11:33:07

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

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

очень странная ситуация, думаю стоит Вам написать как Вы это делаете, а то что то не так у Вас. можете в личку написать или в аську

dimka88 · 2014-11-05 11:33:27

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

Напомнило: Возил мужик из Чернигова картошку одним ведром на жигулях, и решил оптимизировать работу покупкой суперкара но с тем же ведром.

Відредаговано 2014-11-05 11:34:59 dimka88

dimka88 · 2014-11-05 11:42:28

очень странная ситуация, думаю стоит Вам написать как Вы это делаете, а то что то не так у Вас. можете в личку написать или в аську

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

NiTr0 · 2014-11-05 11:43:50

Я там постом выше, привел факт образования deadlock.

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

Abram · 2014-11-05 11:47:25

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

Мне кажется, можно обойтись каким-нибудь атомарным 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 записями.

~AsmodeuS~ · 2014-11-05 11:56:51

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

так вот по этому и интересно

~AsmodeuS~ · 2014-11-05 12:03:16

Мне кажется, можно обойтись каким-нибудь атомарным 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

Відредаговано 2014-11-05 12:14:42 ~AsmodeuS~

NiTr0 · 2014-11-05 12:05:44

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

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

ttttt · 2014-11-05 12:22:15

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

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

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

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

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

madf · 2014-11-05 12:23:59

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evi
Напомнило: Возил мужик из Чернигова картошку одним ведром на жигулях, и решил оптимизировать работу покупкой суперкара но с тем же ведром.

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

madf · 2014-11-05 12:25:48

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

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

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

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

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

NiTr0 · 2014-11-05 12:32:15

Вынести раздачу адресов в отдельный сервис

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

Увійти

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

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

sadmin 7

Ссылка на сообщение

Поделиться на других сайтах

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

Posted Images

~AsmodeuS~ 34

Ссылка на сообщение

Поделиться на других сайтах

NiTr0 583

Ссылка на сообщение

Поделиться на других сайтах

~AsmodeuS~ 34

Ссылка на сообщение

Поделиться на других сайтах

~AsmodeuS~ 34

Ссылка на сообщение

Поделиться на других сайтах

~AsmodeuS~ 34

Ссылка на сообщение

Поделиться на других сайтах

dimka88 19

Ссылка на сообщение

Поделиться на других сайтах

dimka88 19

Ссылка на сообщение

Поделиться на других сайтах

madf 279

Ссылка на сообщение

Поделиться на других сайтах

~AsmodeuS~ 34

Ссылка на сообщение

Поделиться на других сайтах

dimka88 19

Ссылка на сообщение

Поделиться на других сайтах

dimka88 19

Ссылка на сообщение

Поделиться на других сайтах

NiTr0 583

Ссылка на сообщение

Поделиться на других сайтах

~AsmodeuS~ 34

Ссылка на сообщение

Поделиться на других сайтах

dimka88 19

Ссылка на сообщение

Поделиться на других сайтах

dimka88 19

Ссылка на сообщение

Поделиться на других сайтах

NiTr0 583

Ссылка на сообщение

Поделиться на других сайтах

Abram 98

Ссылка на сообщение

Поделиться на других сайтах

~AsmodeuS~ 34

Ссылка на сообщение

Поделиться на других сайтах

~AsmodeuS~ 34

Ссылка на сообщение

Поделиться на других сайтах

NiTr0 583

Ссылка на сообщение

Поделиться на других сайтах

ttttt 195

Ссылка на сообщение

Поделиться на других сайтах

madf 279

Ссылка на сообщение

Поделиться на других сайтах

madf 279

Ссылка на сообщение