Переодически записывается ip трафик на абонентов которые даже не подключались к инету + у них нет этого трафика в сессиях. А если делать отчет по трафику и в статистике эти гигобайты левого трафика присутствуют. Проблема актуальна, потому как срабатывает модуль динамического шейпирования при достижении определенного порога трафика.
Как лечить такую вот вещь?
есть подозрения на mpd 5.5
вот на эту строчку
set netflow timeouts 5 5
а также на конфиги биллинга
traffic_agregation_interval=60
flow_discounts_per_period=31
aggregation_todisc_barrier=2
может что то исправить?
Пишется трафик не тем абонентам!!! как настроить mpd и utm5
Это не баг mpd, и даже не ng_netflow.
Задержка информации о трафике, экспортируемого ng_netflow может произойти по двум причинам:
1. время жизни выделяемого потока
2. нода будет ждать пока не будет сфрмирован полный пакет (~1460 байт для MTU=1500).
Если это настоящая сеть с активными хомячками числом больше 100, ng_netflow будет выдавать информацию о трафике практически в реальном времени - т.е. п.2 не будет проблемой.
Реальная причина в том, что UTM5 НЕ умеет считать трафик с динамическим распределение адресов, то что есть в штатном радиусе это костыль.
Вообще вся необходимая информация в БД есть. Можно было бы реализовать алгоритм "отложеной" тарификаци (на пример запаздывание 5 минут) для случая "динамики".
Но к сожалению "штатно" реализовано схема только с "урфа-пинком", при этом ладно бы по пинку вносились бы измения только в древо тарификатора, так оно еще и "честно" вяжет адрес к ЛС, совершая кучу ненужных транзакций...
Задержка информации о трафике, экспортируемого ng_netflow может произойти по двум причинам:
1. время жизни выделяемого потока
2. нода будет ждать пока не будет сфрмирован полный пакет (~1460 байт для MTU=1500).
Если это настоящая сеть с активными хомячками числом больше 100, ng_netflow будет выдавать информацию о трафике практически в реальном времени - т.е. п.2 не будет проблемой.
Реальная причина в том, что UTM5 НЕ умеет считать трафик с динамическим распределение адресов, то что есть в штатном радиусе это костыль.
Вообще вся необходимая информация в БД есть. Можно было бы реализовать алгоритм "отложеной" тарификаци (на пример запаздывание 5 минут) для случая "динамики".
Но к сожалению "штатно" реализовано схема только с "урфа-пинком", при этом ладно бы по пинку вносились бы измения только в древо тарификатора, так оно еще и "честно" вяжет адрес к ЛС, совершая кучу ненужных транзакций...
активных онлайн доходит до 1800 человек, радиусом неполучится потому что трафик скидывается только тогда когда отключаешься от инета. В реальном времени радиус от нетапа умеет скидывать статистику?
еще есть подозрение на mysql сервер. Когда кто нить формирует какой нить большой отчет жесткие диски по gstat загруженны на 85-90 процентов, стоит RAID10 на 4х 300гиговах SAS 15k (2*Xeon 5410). Может именно в этот момент происходит тупняк?
еще есть подозрение на mysql сервер. Когда кто нить формирует какой нить большой отчет жесткие диски по gstat загруженны на 85-90 процентов, стоит RAID10 на 4х 300гиговах SAS 15k (2*Xeon 5410). Может именно в этот момент происходит тупняк?