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 sta

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

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

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

и Немного вы меня не поняли. Я имею ввиду, что при более 2к клиентов стоит задумываться о переходе на другие, коммерческие, более грамотные продукты. Тут вам и рост и стабильность (Ну опять же, совокупность многих факторов). Ваше время придёт =) Еще подождите. (Оффтоп.) Трудно собраться, когда на твой город периодически нападает армия. С продуктом знаком, восхищен вашей документацией, с 5 раза включая логику, не совсем удаётся понять, что вы имели ввиду. Смотрим в документацию, и видим Смотрим настройку rlm_perl, и видим для 2-й версии, но для первой

Если активных клиентов менее 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

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

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

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

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

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

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

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