Генерирование основного отчета, отчета по трафику и VoIP!

[MagLAN]

Уважаемые разработчики!
.... начало месяца, клиентам необходимо выставлять счета...
За февраль месяц начали генерировать основной отчет по группам пользователей и что имееи.... А имеем то, что при генерации отчета столкнулись с рядом проблем, и это при том что первый отчет делался по группе, в которой 25 учетных записей:
1) при генерации, радиус перестает авторизовать пользователей, получается, что для получения отчета за февраль клиент не может работать в марте, из-за того что биллинг не в состоянии выполнять то, что является его основной функцией. Мы понимаем, что Вам необходимо данную ситуацию воспроизвести на тестовой платформе, где пользователь aospan и пару учетных запичей, но можем заверить, что у Вас все будет "летать"... НОкак нам быть с нашими 1000 пользователей????
2) Добавляем, что при генерации любого вида отчетов начинает "тупить" админский интерфейс и соотвественно вся программа.... Нетап приходиться перегружать!
3) По VoIP вообще проблема, которая по обещанию должна была решиться в 008 сборке, но у вы...
Пишим еще раз, что при создании услуги VoIP и пристегивании к пользователю, начинаюся чудеса! Мы понимаем, что учетной записи можно пользоваться интернетом или телефонией по отдельности, но тогда ПОЧЕМУ при установки пароля на VoIP обычная услуга передачи трафика начинает авторизоваться как VoIP??? В результате радиус не выдает IP адрес клиенту!!!
И еще поясните как возможно при такой работе биллинга оказывать качественные услуги связи!

[plass15]

никак!

[admin]

1. Для производительной работы биллинга не достаточно его просто установить.
Многое зависит о сервера БД. Сколько памяти он сейчас занимает?
Сколько памяти всего в сервере? Сколько свободно в настоящий момент?

1000 пользователей - это очень мало для таких симптомов, которые Вы описываете.

2. непонятно, что и как начинает тупить и почему приходится перегружать.

3. я не общался с Вами по этой проблеме (?), но заверяю Вас: я постоянно работаю с одним сервером, на котором одновременно предоставляются услуги телефонии и VPN. НИКАКИХ подобный проблем не наблюдается. Пожалуйста, обращайтесь с такими пробелмами в службу техподдержки, так как это , скорее частная проблема, чем общий баг.

[Max Milkov]

1. Для производительной работы биллинга не достаточно его просто установить.
Многое зависит о сервера БД. Сколько памяти он сейчас занимает?
Сколько памяти всего в сервере? Сколько свободно в настоящий момент?

1000 пользователей - это очень мало для таких симптомов, которые Вы описываете.

2. непонятно, что и как начинает тупить и почему приходится перегружать.

3. я не общался с Вами по этой проблеме (?), но заверяю Вас: я постоянно работаю с одним сервером, на котором одновременно предоставляются услуги телефонии и VPN. НИКАКИХ подобный проблем не наблюдается. Пожалуйста, обращайтесь с такими пробелмами в службу техподдержки, так как это , скорее частная проблема, чем общий баг.

Я не администратор форума, но за последний месяц читал сообщения о "частной проблеме" торможении ядра при генерации отчетов минимум от 4ех пользователей.
Ничего себе "частная" проблемка, а?!
У нас тоже уже проявляются такие моменты. Пока еще притормаживания не критично сказываются на таботе пользователей (и то только по тому, что мы используем FreeRadius и авторизация пользователей не зависит на прямую от ядра), но учитывая что это происходит с примерно 300 аккаунтами на машине класса P4-2GHz/1Gb RAM можно легко спрогнозировать что уже при 500 абонентах проблема станет критичной.

[mva]

У меня таже проблемма, и давно, за 1 день еще 2-3 минуты делается, после оптимизации MySQL, но за месяц это целое событие....
Позавчера делали 55 минут

Параллельно смотрел процессы в базе так на одного юзера бывало по 3 минуты висел, загрузка проца 100% грузит не ядро а MySQL,
Надо просто оптимизировать запросы при выборке, понятно что много таблиц, но какой же надо комп тогда? если будет 5000 юзеров...
3 часа никто работать не сможет?

В это время никто не мог подключиться...

Памяти было свободно мег 400 и свапа половина...

1300 юзеров
UTM5-1.10-008 Sparc Solaris 64
CPU UltraSparc IIi 440 1 Gb memory.

Не частная это проблема, не надо...

[admin]

Памяти было свободно мег 400 и свапа половина...

А вот и причина проблемы!
Весь тонкий смысл тюнинга mysql заключается в том, чтобы заставить использовать его всю доступную память, не попадая при этом в своп.
На 400 мегабайтах памяти mysql можно очень сильно ускорить.