dimka88

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

Это хорошо. У меня пока не совсем достаточно времени, для детальных тестов. По мере нахождения, я буду отписываться. Скорее всего ближе к концу ноября.

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

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

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

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

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

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

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

Да ну? А разве это не задача базы - слушать вопросы и отвечать на них? Чем это ей еще заниматься? Чем меньше запросов к базе, тем меньше шансов, что база станет узким местом. Дедлоки или есть (что фатально плохо), или их нет (что хорошо). Раз вы говорите о вероятности появления дедлоков, значит они есть и ваша архитектура - говно. Простите, но я не разрабатывал архитектур, вы меня перепутали с кем то. (Печальбеда) Ужасти, 30к - это генерегка на тесте, запросы только от 1 тестового клиента, база совсем не нагружена.

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

Там активные сессии и не только. И вот пример: 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;

А не проще взять фиктивное число, если не хотите светить количество пользователей. Фиктивное число 8999 При отправке в приват это будет выглядеть uid+8999; При приёме от привата uid=SUM-8999; Да и не только, ломать авто инкремент индекс по умолчанию плохо.

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

и Немного вы меня не поняли. Я имею ввиду, что при более 2к клиентов стоит задумываться о переходе на другие, коммерческие, более грамотные продукты. Тут вам и рост и стабильность (Ну опять же, совокупность многих факторов). Ваше время придёт =) Еще подождите. (Оффтоп.) Трудно собраться, когда на твой город периодически нападает армия. С продуктом знаком, восхищен вашей документацией, с 5 раза включая логику, не совсем удаётся понять, что вы имели ввиду. Смотрим в документацию, и видим Смотрим настройку rlm_perl, и видим для 2-й версии, но для первой версии настройка есть. ссылка в студию. http://abills.net.ua/wiki/doku.php/abills:docs:rlm_perl:ru#freeradius_2x С rlm_perl отдельно все посмотрим, рассмотрим, всему свое время.

Если активных клиентов менее 2000, то Abills, mikbill, ubilling. Если вы уже более серьёзно развиваете предприятие и хотите безопасно обновляться, идти в ногу со временем, то уж рассмотрите варианты Гидра, Felix2 может быть карбон и expertbilling. Для региональных операторов связи, присутствуют очень дорогие, но очень надёжные решения, есть ли смысл их здесь упоминать?

Вы это время можете сами регулировать, там оно в конфиге задаётся количество не пришедших acct-interim-update, можете до 5 минут сократить, это если не пришёл хотя бы 1 update. Можете уменьшить время acct-interim-interval и тем самым нагрузить базу еще больше, но Abills быстро осознает, что нас упал. А вообще падение NAS - это в первую очередь проблема NAS. И да по поводу падений , описанной ситуации, делал Asmodeus фичу, а получилась бага. Там как то сессии с одинаковыми CID на разных нас могли подниматься.

SELECT id as nas_id, name AS nas_name, nas_identifier, descr AS nas_describe, ip AS nas_ip, nas_type, auth_type AS nas_auth_type, mng_host_port as nas_mng_ip_port, mng_user AS nas_mng_user, DECODE(mng_password, 'test12345678901234567890') AS nas_mng_password, rad_pairs AS nas_rad_pairs, alive AS nas_alive, disable AS nas_disable, ext_acct AS nas_ext_acct, gid, address_build, address_street, address_flat, zip, city, country, domain_id, mac, changed, location_id FROM nas WHERE ip='127.0.0.1' and (nas_identifier='accel-ppp' or nas_identifier='') ORDER BY nas_identifier DESC; SELECT id as nas_id, name AS nas_name, nas_identifier, descr AS nas_describe, ip AS nas_ip, nas_type, auth_type AS nas_auth_type, mng_host_port as nas_mng_ip_port, mng_user AS nas_mng_user, DECODE(mng_password, 'test12345678901234567890') AS nas_mng_password, rad_pairs AS nas_rad_pairs, alive AS nas_alive, disable AS nas_disable, ext_acct AS nas_ext_acct, gid, address_build, address_street, address_flat, zip, city, country, domain_id, mac, changed, location_id FROM nas WHERE ip='127.0.0.1' and (nas_identifier='accel-ppp' or nas_identifier='') ORDER BY nas_identifier DESC; select u.uid, DECODE(password, 'test12345678901234567890') AS passwd, UNIX_TIMESTAMP() AS session_start, UNIX_TIMESTAMP(DATE_FORMAT(FROM_UNIXTIME(UNIX_TIMESTAMP()), '%Y-%m-%d')) AS day_bagin, DAYOFWEEK(FROM_UNIXTIME(UNIX_TIMESTAMP())) AS day_of_week, DAYOFYEAR(FROM_UNIXTIME(UNIX_TIMESTAMP())) AS day_of_year, u.company_id, u.disable, u.bill_id, u.credit, u.activate AS account_activate, u.reduction, u.ext_bill_id, UNIX_TIMESTAMP(u.expire) AS account_expire FROM users u WHERE u.id='test' AND u.domain_id='0' AND (u.expire='0000-00-00' or u.expire > CURDATE()) AND (u.activate='0000-00-00' or u.activate <= CURDATE()) AND u.deleted='0' GROUP BY u.id; SELECT ROUND(deposit, 2) FROM bills WHERE id='1'; select if (dv.logins=0, if(tp.logins is null, 0, tp.logins), dv.logins) AS logins, if(dv.filter_id != '', dv.filter_id, if(tp.filter_id is null, '', tp.filter_id)) AS filter, if(dv.ip>0, INET_NTOA(dv.ip), 0) AS ip, INET_NTOA(dv.netmask) AS netmask, dv.tp_id AS tp_num, dv.speed AS user_speed, dv.cid, tp.total_time_limit, tp.day_time_limit, tp.week_time_limit, tp.month_time_limit, UNIX_TIMESTAMP(DATE_FORMAT(DATE_ADD(curdate(), INTERVAL 1 MONTH), '%Y-%m-01')) - UNIX_TIMESTAMP() AS time_limit, tp.total_traf_limit, tp.day_traf_limit, tp.week_traf_limit, tp.month_traf_limit, tp.octets_direction, if (count(un.uid) + count(tp_nas.tp_id) = 0, 0, if (count(un.uid)>0, 1, 2)) AS nas, UNIX_TIMESTAMP() AS session_start, UNIX_TIMESTAMP(DATE_FORMAT(FROM_UNIXTIME(UNIX_TIMESTAMP()), '%Y-%m-%d')) AS day_begin, DAYOFWEEK(FROM_UNIXTIME(UNIX_TIMESTAMP())) AS day_of_week, DAYOFYEAR(FROM_UNIXTIME(UNIX_TIMESTAMP())) AS day_of_year, dv.disable, tp.max_session_duration, tp.payment_type, tp.credit_tresshold, tp.rad_pairs AS tp_rad_pairs, count(i.id) AS intervals, tp.age AS account_age, dv.callback, dv.port, tp.traffic_transfer_period, tp.neg_deposit_filter_id, tp.ext_bill_account, tp.credit AS tp_credit, tp.ippool as tp_ippool, dv.join_service, tp.tp_id, tp.active_day_fee, tp.neg_deposit_ippool AS neg_deposit_ip_pool, dv.expire AS dv_expire FROM (dv_main dv) LEFT JOIN tarif_plans tp ON (dv.tp_id=tp.id AND tp.domain_id='0') LEFT JOIN users_nas un ON (un.uid = dv.uid) LEFT JOIN tp_nas ON (tp_nas.tp_id = tp.tp_id) LEFT JOIN intervals i ON (tp.tp_id = i.tp_id) WHERE dv.uid='1' AND (dv.expire='0000-00-00' or dv.expire > CURDATE()) GROUP BY dv.uid; SELECT ippools.ip, ippools.counts, ippools.id FROM ippools, nas_ippools WHERE ippools.id=nas_ippools.pool_id AND nas_ippools.nas_id='1' ORDER BY ippools.priority; 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; 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'), nas_id='1', tp_id='100', user_name='test', framed_ip_address=167772224, uid='1'; SELECT id, in_price, out_price, prepaid, in_speed, out_speed, net_id, expression FROM trafic_tarifs WHERE interval_id='0'; INSERT INTO errors_log (date, log_type, action, user, message, nas_id) values (now(), '6', 'AUTH', 'test', 'CID: 192.168.6.94 GT: 0.07730', '1'); SELECT id as nas_id, name AS nas_name, nas_identifier, descr AS nas_describe, ip AS nas_ip, nas_type, auth_type AS nas_auth_type, mng_host_port as nas_mng_ip_port, mng_user AS nas_mng_user, DECODE(mng_password, 'test12345678901234567890') AS nas_mng_password, rad_pairs AS nas_rad_pairs, alive AS nas_alive, disable AS nas_disable, ext_acct AS nas_ext_acct, gid, address_build, address_street, address_flat, zip, city, country, domain_id, mac, changed, location_id FROM nas WHERE ip='127.0.0.1' and (nas_identifier='accel-ppp' or nas_identifier='') ORDER BY nas_identifier DESC; SELECT acct_session_id FROM dv_calls WHERE user_name='test' AND nas_id='1' AND (framed_ip_address=INET_ATON('10.0.0.64') OR framed_ip_address=0); UPDATE dv_calls SET status='1', started=FROM_UNIXTIME(1414669426), lupdated=UNIX_TIMESTAMP(), nas_port_id='0', acct_session_id='0000000000fcf9d2', CID='192.168.6.94', CONNECT_INFO='' WHERE user_name='test' AND nas_id='1' AND acct_session_id='IP' AND (framed_ip_address=INET_ATON('10.0.0.64') OR framed_ip_address=0) LIMIT 1; INSERT into s_detail (acct_session_id, nas_id, acct_status, last_update, sent1, recv1, sent2, recv2, id, sum) VALUES ('0000000000fcf9d2', '1', '1', UNIX_TIMESTAMP(), '0', '0', '0', '0', 'test', '0'); Так выглядит авторизация обычного пользователя в биллинге Abills. Все хорошо, пока база не наполнена. Но как база наполнится, мы увидим прекраснейшее использование могучих индексом mysql. Особенно таблицы dv_log. А далее будем разбирать deadlock который я думаю так и встречается по сей день. ps/ Продолжение следует. И раз вы так любите придерживаться стандартов, поправьте вот этот запрос. select u.uid, DECODE(password, 'test12345678901234567890') AS passwd, UNIX_TIMESTAMP() AS session_start, UNIX_TIMESTAMP(DATE_FORMAT(FROM_UNIXTIME(UNIX_TIMESTAMP()), '%Y-%m-%d')) AS day_bagin, DAYOFWEEK(FROM_UNIXTIME(UNIX_TIMESTAMP())) AS day_of_week, DAYOFYEAR(FROM_UNIXTIME(UNIX_TIMESTAMP())) AS day_of_year, u.company_id, u.disable, u.bill_id, u.credit, u.activate AS account_activate, u.reduction, u.ext_bill_id, UNIX_TIMESTAMP(u.expire) AS account_expire FROM users u WHERE u.id='test' AND u.domain_id='0' AND (u.expire='0000-00-00' or u.expire > CURDATE()) AND (u.activate='0000-00-00' or u.activate <= CURDATE()) AND u.deleted='0' GROUP BY u.id; select = SELECT. Навскидку при одновременном подключении 300 пользователей, имеем 14*300=4200 запросов в единицу времени (Deadlock привет).

Ну уж далеко от лучших. При наличии свободного времени подниму на стенде, и детально 5-10 запросов покажу. Пока можно не краснеть =) +

Попросите у них демку потыкать. Мне очень понравилось, но в связи с войной и еще многими обстоятельствами покупка отменилась. Да и вообще latera очень солидные ребята. А самый большой + это Oracle Database и грамотная структура таблиц. Не столько она уже и стоит, что бы экономить на сердце предприятия. А если вы сомневаетесь в покупке, то загляните в код бесплатной версии всем любимой украинской биллинговой системы и EXPLAINом запросы к базе погоняйте. И вы поймёте, что значит писать не качественно. Это моё мнение.

ipfw для Linux разрабатывала Марта Карбон, но использовать IPFW в Linux при большой нагрузке не рекомендуется, хотя Луиджи Риззо вроде как дорабатывает и под Linux . Используйте лучше средства Linux, они не уступают, даже в чём то превосходят.

Идея очень правильная. Но смысла в ней мало, разве что для перестраховки (Для монолога: "Я же все правильно сделал?!"). Отказаться от бизнеса в густонаселённом районе, не вопрос, скажут вали. Начнёшь останавливать работу провайдера, приедут за несколько минут, расстреляют, отожмут бизнес. Оборудование через блок посты не провезёшь. А остальные будут просто молчать. Ситуация зашла в тупик. Делайте как вам говорят, и только так есть возможность сохранить жизнь и бизнес. Людям не ощутившим подобное на себе, всех факторов не понять. И да, вы даже не представляете, что необходимо сделать, что бы тут все устаканилось... Dimka_SKY - держитесь! Будем надеяться, что "великие" и "не очень великие" но с оружием найдут общий язык.

Да вы тему почитайте, а не пишите ахинею. Многие поддерживают контроль.

У меня конечно не удалось это воплотить в жизнь, но на психологическом уровне, заставляет задуматься. А там судите сами.

Биллинг 1,5 год работы! Полёт нормальный. Ну вилами по воде писано. Это kernel based. Там всё замечательно. Да ну. Ядро за 5 минут компилируется. Если знать, что туда компилировать.