BiTel

Уважаемые разработчики.
Не подскажете процедуру/рекомендации по чистке/удалению таблиц для модуля(ей) Inet 6.0?
Изначально (исходя из рекомендаций) был выделен раздел под БД - 100ГБ.
И вот он почти заканчивается - осталось около 8ГБ после полтора года работы.
И с такой скоростью заполнения, как сейчас, раздел заполнится через месяц.
Основное место в БД занимают таблицы модуля Inet. Сейчас в БД всего 14 444 файла.

А какие таблицы Inet занимают достаточно большие объемы, чтобы из удаление заметно повлияло на свободное место?

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Вот такой расклад:
- inet_session_log_account_{mid}_yyyyMM - 43,768,725K bytes in 2580 files
- inet_session_log_detail_{mid}_yyyyMM - 31,780,164K bytes in 1290 files
- connection_log_entry_{mid}_yyyyMM - 9,839,390K bytes in 1280 files
- inv_ip_resource_subscription_dyn_{mid}_yyyyMM - 3,650,803K bytes in 256 files
- bgs_query_log_yyyyMM - 1,508,559K bytes in 48 files
- inet_connection__{mid} - 555,441,252 bytes in 110 files

Большинство из них с партицированием, про это правда нигде не пишут.

- inet_session_log_account_{mid}_yyyyMM - 43,768,725K bytes in 2580 files
- inet_session_log_detail_{mid}_yyyyMM - 31,780,164K bytes in 1290 files
- connection_log_entry_{mid}_yyyyMM - 9,839,390K bytes in 1280 files

Эти старые, если не нужны - вполне можно удалить.
connection_log_entry - координаты DHCP/RADIUS логов,
inet_session_log_detail - трафики, разбитые с помощью привязок трафиков, сгруппированные по типу трафика
inet_session_log_account - протарифицированная наработка сессий, сгруппированная по услуге

Неверно. netflow лежит в виде файлов на диске, его нет в базе.

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

А у вас какая схема подключения ? VPN ? трафик как собираете - по netflow ?

Вообще есть проблема сейчас, что если настроить inet неправильно, то он может создать просто неограниченные объемы данных . Мы пытались сделать так чтобы timeout сессий был принудительно не меньше 3-х часов, но этим оказалось есть недовольные и это убрали. Проблема модуля Inet в в его гибкости и универсальности, которые позволяют удовлетворитьизвращенные фантазии сложные схемы для мелких провайдеров, подключающих 100 клиентов. Но при этом универсальность может создать проблемы остальным . В частности может вырости объем данных у тех, кто перешел с IPN, так как там вообще не было сессий, а тут могут настроить timeout-ы так, чтобы создавать сессию каждые несколько секунд .Иногда у нас в кулуарах осбвждается идея, сделать каие-то схемы попроще для специфических случаев , но она вызывает жесткую критику от некоторых разработчиков, так в этом случае придется поддерживать 2 схемы. В итоге сошлись на том, что у нас универсальная схема, но пользователь сам выбирает что ему нужно и настраивает.

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

Некие, пусть даже общие, рекомендации не помешали бы, IMHO.

Мы используем pppoe, pptp, ipoe.
Все работает только через radius (Acct-Interim-Interval=300).
Трафик собираем и учитываем по netflow.
Тарифы все unlim.
Типы трафиков только "входящий" и "исходящий" по netflow.

Отписался выше о схеме работы....

Время идет, база заполняется, раздел почти заполнился - до время "Ч" осталось пару дней.
Поэтому хочу снова обратить внимание на тему.
Когда запускал версию 5.2 и выбирал размер партиции под базу, то встречалось мнение, что 100ГБ "хватит за глаза".
Но как оказалось на практике - это не относилось к модулю Inet, который начал "кушать" место.
Что имеем на текущий момент:
Размер партиции под БД - 100ГБ.
На текущий момент осталось свободно - 627М (за не полных 2 года работы) - это на пару дней.
В работе 6 моделей Inet.
Схема работы: pppoe, pptp, ipoe.
Все работает только через radius (Acct-Interim-Interval=300).
Трафик собираем и учитываем по netflow - за сутки около 30ГБ.
Тарифы все unlim.
Типы трафиков только "входящий" и "исходящий", привязанный по netflow.

Результаты более детального "расследования" по пожирателям дал следующие данные:

Для анализа отобрались самых 5 прожорливых таблиц модуля Inet.
Размеры указаны фактические, которые занимают файлы на диске.

Выводы:

1) Эти пять таблиц занимают 95% от всего размера БД.

2) Главный пожиратель; 36.76% - inet_session_log_detail - трафики, разбитые с помощью привязок трафиков, сгруппированные по типу трафика с почасовой разбивкой.
Что самое интересное, что 33% этой таблицы бестолковые записи, с учетом внутреннего типа трафика "время" - тип "0" со значением 3600 для каждой активной сессий каждый час.
Итого имеем, что 10% всей базы составляют такие "нужные" записями, что в часе 3600 сек.
Что самое интересное, при нашей схеме работы все данные в этих таблицах для нас вообще не нужны.

3) Анализ показал, что на 1000 клиентов при 2 типах трафика, а по факту 3 типах (+время) - в месяц расходуется около 1000М места в БД для модуля Inet.
Это важно знать при планировании выделения места по БД.

4) Таблица inv_ip_resource_subscription_dyn. Не совсем понятно ее назначение. И в описании схемы БД она отсутствует.
Кстатит на dbinfo.bitel.ru отсутствует описание не на одну таблицу Inet - минимум штук 5.

5) Начинаю делать дампы самых прожорливых архивных таблиц для освобождения места.

inet_session_log_detail используется для отчетов по трафику и для переобсчета.
connection_log_entry используется для "Показать DHCP/RADIUS-лог", там координаты старт/стоп пакетов в логах.

Это размер в сумме с индексом? Возможно большую часть занимает индекс.

Я знаю назначение этих таблиц, за исключением inv_ip_resource_subscription_dyn.
Да это размеры файлов, значит с индексами.
От этого (насчет индексов) ничего не меняется - раздел заканчивается.
Inet оказался очень прожорливым.
Выделил мало место под БД изначально, но сейчас это изменить увы не могу - придется пока удалять старые.
Вы в рекомендациях по размерам под БД где-то дайте предупреждение насчет прожорливости Inet.
На 1000 клиентов - 1000МБ в месяц.

Возможно быстрее SQL дампа будет удалить индексы из таблицы, затем сконвертировать ее в MyISAM. Файлы таблицы MyISAM насколько знаю легко можно перемещать, в отличие от таблиц InnoDB.

Не понял . Какие еще таблицы не описаны? Вот то, что там есть сейчас :

сколько у вас сессий за месяц в inet_session_log и сколько записей детализации в inet_session_log_detail ?

напишите в helpdesk и дайте доступ . Нужно провести анализ у вас на месте.

Спасибо за совет по переводу в MyISAM.
Переконвертировал пока connection_log_entry от 6 модулей за 2012 год - освободил пока 1ГБ.
Сейчас дальше буду думать, как оптимальнее дальше делать.
Делал так:
1) полный дамп оригинала в файл через "mysqldump --single-transaction --disable-keys --extended-insert --quick"
2) удаление партицирования - "ALTER TABLE $table REMOVE PARTITIONING;"
3) удаление лишнего индекса - "ALTER TABLE $table DROP INDEX \`app-dev-con\`;"
4) перевод в MyISAM - "ALTER TABLE $table ENGINE=MyISAM;"

Отсутствует полние описание таблиц:
1) inet_connection_{mid}_seq
2) inet_session_{mid}_seq
3) inv_ip_resource_subscription_dyn_{mid}_yyyyMM

в таблице "inv_ip_resource_subscription_{mid}" исправьте описание для:
296 addressTo varbinary(24) false конченый адрес

в таблице "connection_log_entry_{mid}_yyyyMM" отсутствует описание для:
247 type int(11) false

В разных модулях по разному.
В некоторых модулях бывает:
inet_session_log - более 300 000 записей в месяц,
inet_session_log_detail - более 3 000 000 записей в месяц.

Я уже давал ранее данные для доступа в helpdesk.
Ничего не изменилось - можно заходить.