9 месяцев назад я унаследовал администрирование небольшой сети и UTM3 вместе с ней. До сих пор особых нареканий на ее работу не было. Все считала,
всех отключала, и т.д.
С полтора месяца назад обнаружилось неадекватное поведение. Как затем выяснилось это началось с нового года.
Траффик и деньги система предположительно продолжает считать правильно.
Но оперативные отчеты (по дням и по часам) перестали показывать правду.
Траффик оказывается сильно занижен. Пользователи удивляются почему их система отключает когда потребленный траффик такой маленький.
Я обращался к господам в netup, где мне вежливо сказали что уже как 2 года
не сопровождают эту версию. Предложили upgrade до UTM.5
В наши планы это не входит.
Ниже приведен результат моих исследований такого странного поведения.
- в БД обнаружено три пары таблиц
traffic_day / traffic_opt_day
traffic_month / traffic_opt_month
traffic_year / traffic_opt_year
- отчеты пользователей строятся по таблицам с префиксом 'opt'
- протоколирование sql запросов показало, что tsave пишет одну и ту-же информацию в обе таблицы. Затем чистит "старую" информацию из таблиц
без префикса "opt".
=================
4 Query UPDATE traffic_month SET bytes=bytes+'1166',ltime='1144079100' WHERE uid='15' AND t_class=1000 AND day='3' AND yday='92'
4 Query UPDATE traffic_opt_month SET bytes=bytes+'1166',ltime='1144079100' WHERE uid='15' AND t_class=1000 AND day='3' AND yday='92'
4 Query DELETE FROM traffic_month WHERE ltime < '1140623101'
=================
Но почему-то оказывается, что в таблицах с префиксом "opt" (по которым строятся отчеты) присутствуют не все записи.
В таблице traffic_opt_month есть записи в основном за воскресенье и иногда за понедельник.
В таблице traffic_opt_day записи по нечетным часам и то не все.
Сейчас для получения "реальных" данных руками выбираю из traffic_day & traffic_month.
Проверял БД mysqlcheck. Ошибок не показывает.
Буду признателен за дельные советы.
Советы типа выкинуть ее нафиг не работают. Желания менять биллинговую систему нет.
mysql> select FROM_UNIXTIME(ftime), (bytes)/1024/1024 from traffic_opt_month where FROM_UNIXTIME(ftime) between '2006-03-01 00:00:00' and '2006-03-31 23:59:59' and t_class=10 and uid=24 order by ftime;
+----------------------+-------------------+
| FROM_UNIXTIME(ftime) | (bytes)/1024/1024 |
+----------------------+-------------------+
| 2006-03-06 09:30:01 | 29.748055 |
| 2006-03-07 08:45:01 | 17.565218 |
| 2006-03-13 09:00:01 | 29.983105 |
| 2006-03-20 09:00:01 | 16.566559 |
| 2006-03-27 09:30:01 | 25.469215 |
+----------------------+-------------------+
5 rows in set (0.01 sec)
mysql> select FROM_UNIXTIME(ftime), (bytes)/1024/1024 from traffic_month where FROM_UNIXTIME(ftime) between '2006-03-01 00:00:00' and '2006-03-31 23:59:59' and t_class=10 and uid=24 order by ftime;
+----------------------+-------------------+
| FROM_UNIXTIME(ftime) | (bytes)/1024/1024 |
+----------------------+-------------------+
| 2006-03-02 11:15:00 | 44.346771 |
| 2006-03-03 09:00:01 | 13.972713 |
| 2006-03-06 09:30:01 | 29.748055 |
| 2006-03-07 08:45:01 | 17.565218 |
| 2006-03-09 10:00:01 | 25.468250 |
| 2006-03-10 09:00:01 | 107.750175 |
| 2006-03-13 09:00:01 | 29.983105 |
| 2006-03-14 09:00:01 | 33.103619 |
| 2006-03-15 09:30:03 | 38.960674 |
| 2006-03-16 11:15:02 | 31.097698 |
| 2006-03-17 09:00:01 | 40.749268 |
| 2006-03-20 09:00:01 | 16.566559 |
| 2006-03-21 09:15:01 | 11.072265 |
| 2006-03-22 08:45:01 | 36.787716 |
| 2006-03-23 09:00:01 | 37.056763 |
| 2006-03-24 10:00:01 | 11.718398 |
| 2006-03-27 09:30:01 | 25.469215 |
| 2006-03-28 09:00:01 | 3.030425 |
| 2006-03-29 09:45:01 | 7.248229 |
| 2006-03-30 08:45:01 | 9.118782 |
| 2006-03-31 08:45:01 | 2.580431 |
+----------------------+-------------------+
21 rows in set (0.07 sec)
mysql> select FROM_UNIXTIME(ftime), (bytes)/1024/1024 from traffic_opt_day where FROM_UNIXTIME(ftime) between '2006-04-04 00:00:00' and '2006-04-04 23:59:59' and t_class=10 and uid=24 order by 1;
+----------------------+-------------------+
| FROM_UNIXTIME(ftime) | (bytes)/1024/1024 |
+----------------------+-------------------+
| 2006-04-04 09:15:01 | 5.825432 |
| 2006-04-04 11:00:01 | 10.480784 |
| 2006-04-04 13:00:01 | 14.012320 |
| 2006-04-04 15:00:01 | 1.204184 |
+----------------------+-------------------+
4 rows in set (0.04 sec)
mysql> select FROM_UNIXTIME(ftime), (bytes)/1024/1024 from traffic_day where FROM_UNIXTIME(ftime) between '2006-04-04 00:00:00' and '2006-04-04 23:59:59' and t_class=10 and uid=24 order by 1;
+----------------------+-------------------+
| FROM_UNIXTIME(ftime) | (bytes)/1024/1024 |
+----------------------+-------------------+
| 2006-04-04 09:15:01 | 5.825432 |
| 2006-04-04 11:00:01 | 10.480784 |
| 2006-04-04 12:00:01 | 8.593051 |
| 2006-04-04 13:00:01 | 14.012320 |
| 2006-04-04 14:00:01 | 9.652583 |
| 2006-04-04 15:00:01 | 1.204184 |
| 2006-04-04 16:00:01 | 9.620751 |
| 2006-04-04 17:00:01 | 2.461573 |
+----------------------+-------------------+
8 rows in set (0.00 sec)
UTM3 поздравила с новым 2006 г! Господа, помогоите!
Ясно.
У меня все-же большое подозрение, что покривились таблицы, хотя myisamcheck
не жалуется. Я пересоздал таблицы с префиксом _opt_. Наблюдаю за системой.
Кстати насколько я осведомлен эти таблицы остались и в 4й версии.
И мне все-же любопытно зачем таблицы дублируются.
traffic_day / traffic_opt_day
traffic_month / traffic_opt_month
traffic_year / traffic_opt_year
У них одинаковые структуры, туда пишутся одни и те-же данные в процессе обработки статистики. Разница лишь в том, что первые время от времени чистятся.
Или в 4й версии не так?
У меня все-же большое подозрение, что покривились таблицы, хотя myisamcheck
не жалуется. Я пересоздал таблицы с префиксом _opt_. Наблюдаю за системой.
Кстати насколько я осведомлен эти таблицы остались и в 4й версии.
И мне все-же любопытно зачем таблицы дублируются.
traffic_day / traffic_opt_day
traffic_month / traffic_opt_month
traffic_year / traffic_opt_year
У них одинаковые структуры, туда пишутся одни и те-же данные в процессе обработки статистики. Разница лишь в том, что первые время от времени чистятся.
Или в 4й версии не так?
Ох, таки посмотрел в чем дело... 
Короче, traffic_... (без opt) нужны только для рисования графиков, поэтому там (для быстроты этой операции) держится информация лишь за последние n дней. Все работы идут с traffic_opt_...
Теперь конкретно по твоей проблеме. У тебя происходит только update таблиц, а insert'а новой информации нет. Insert происходит только тогда, когда не удался update (вернул 0 измененных строк), т.е. когда на данного пользователя с данным классом трафика в данный день ничего не записано (см. where из твоих update'ов). Если же что-то есть, то - как сам видишь - просто добавляется количество байт в этот класс и все...
Причина глюка: УТМовские косяки с датой и временем. Как видишь по update'ам, там не пишется/проверяется год, а только день в нем, т.е. если информации по пользователю больше, чем на год, то новая будет добавляться к старой. Однако, т.к. ftime там стоит прошлогодний, то в отчетах этого не видно и кажется что вообще ничего и никуда не добавлено...
Извиняюсь, если несколько субмурно, но надеюсь, что все-таки более-менее понятно.
Цель ради которой в УТМ сделано так мудрено проста: информацию о трафика надо агрегировать, ибо смысл хранить в отчетах данные более мелкими отрезками, чем часовые, если все равно отчеты возможны лишь по часам из дневных таблиц и по дням из месячных?
Ошибка УТМовских программеров в том, что фантазии больше, чем на год работы биллинга у них не хватило.
Решение проблемы простое: почистить traffic_opt_..., чтобы там не было прошлогодней информации.
И делать так надо будет каждый год, ибо на первый взгляд я соответствующих вещей в УТМе не вижу.... Что характерно - в четвертом.
Так что, в определенном смысле, спасибо тебе - навел на тему. Сейчас сяду допИсывать автоматическое удаление информации из таблиц, которая старше 11 месяцев...
Короче, traffic_... (без opt) нужны только для рисования графиков, поэтому там (для быстроты этой операции) держится информация лишь за последние n дней. Все работы идут с traffic_opt_...Теперь конкретно по твоей проблеме. У тебя происходит только update таблиц, а insert'а новой информации нет. Insert происходит только тогда, когда не удался update (вернул 0 измененных строк), т.е. когда на данного пользователя с данным классом трафика в данный день ничего не записано (см. where из твоих update'ов). Если же что-то есть, то - как сам видишь - просто добавляется количество байт в этот класс и все...
Причина глюка: УТМовские косяки с датой и временем. Как видишь по update'ам, там не пишется/проверяется год, а только день в нем, т.е. если информации по пользователю больше, чем на год, то новая будет добавляться к старой. Однако, т.к. ftime там стоит прошлогодний, то в отчетах этого не видно и кажется что вообще ничего и никуда не добавлено...
Извиняюсь, если несколько субмурно, но надеюсь, что все-таки более-менее понятно.
Цель ради которой в УТМ сделано так мудрено проста: информацию о трафика надо агрегировать, ибо смысл хранить в отчетах данные более мелкими отрезками, чем часовые, если все равно отчеты возможны лишь по часам из дневных таблиц и по дням из месячных?Ошибка УТМовских программеров в том, что фантазии больше, чем на год работы биллинга у них не хватило.
Решение проблемы простое: почистить traffic_opt_..., чтобы там не было прошлогодней информации.
И делать так надо будет каждый год, ибо на первый взгляд я соответствующих вещей в УТМе не вижу.... Что характерно - в четвертом.
Так что, в определенном смысле, спасибо тебе - навел на тему. Сейчас сяду допИсывать автоматическое удаление информации из таблиц, которая старше 11 месяцев...