5.2.1-009 Баг или фича ? В debug.log непонятные сообщения

alkol · Сообщение **alkol** » Пн май 14, 2012 10:45

После перехода с 5.2.1-005 на 009 в debug.log посыпались непонятные сообщения. Эти сообщения идут постоянно, debug.log тяжелеет за секунды.

?Debug : May 12 15:49:24 b2e70b70 UTM5 DBA: _calc_unblocked_time: curr <1338494400> start_recalc <0> saved_recalc <0> is_blocked_recalc <0> begin <1335816000> end <1338494400>
?Debug : May 12 15:49:24 b2e70b70 UTM5 DBA: __get_unabon_unprepay: slink_id 37779 unabon 0 unprepay 0 is_blocked 0
?Debug : May 12 15:49:24 b2e70b70 UTM5 DBA: _calc_unblocked_time: curr <1338494400> start_recalc <0> saved_recalc <0> is_blocked_recalc <0> begin <1335816000> end <1338494400>
?Debug : May 12 15:49:24 b2e70b70 UTM5 DBA: __get_unabon_unprepay: slink_id 39325 unabon 0 unprepay 0 is_blocked 0
?Debug : May 12 15:49:24 b2e70b70 UTM5 DBA: _calc_unblocked_time: curr <1338494400> start_recalc <0> saved_recalc <0> is_blocked_recalc <0> begin <1335816000> end <1338494400>
?Debug : May 12 15:49:24 b2e70b70 UTM5 DBA: __get_unabon_unprepay: slink_id 23983 unabon 0 unprepay 0 is_blocked 0
?Debug : May 12 15:49:24 b2e70b70 UTM5 DBA: _calc_unblocked_time: curr <1338494400> start_recalc <0> saved_recalc <0> is_blocked_recalc <0> begin <1335816000> end <1338494400>
?Debug : May 12 15:49:24 b2e70b70 UTM5 DBA: __get_unabon_unprepay: slink_id 30988 unabon 0 unprepay 0 is_blocked 0
?Debug : May 12 15:49:24 b2e70b70 UTM5 DBA: _calc_unblocked_time: curr <1338494400> start_recalc <0> saved_recalc <0> is_blocked_recalc <0> begin <1335816000> end <1338494400>
?Debug : May 12 15:49:24 b2e70b70 UTM5 DBA: __get_unabon_unprepay: slink_id 22013 unabon 0 unprepay 0 is_blocked 0
?Debug : May 12 15:49:24 b2e70b70 UTM5 DBA: _calc_unblocked_time: curr <1338494400> start_recalc <0> saved_recalc <0> is_blocked_recalc <0> begin <1335816000> end <1338494400>

Количество уникальных slink_id в файле принадлежат только 10-15% пользователей в базе.

Так должно быть или где то косяк?

Так же в main.log постоянно
ERROR : May 12 12:09:29 b2d47b70 Radius: RadiusPlugin::rehash: no stream manager

UPD. Останавливая neflow, в логе эти сообщения пропадают

EvaNgeLioN

То же самое. Система FreeBSD 8.2-RELEASE 32 разрядная. Версия mysql 5.1.63.
Дополню на utm5-2.1.009 rc3 от 2011-07-28 такой проблемы не наблюдалось, а вот после установки utm5-2.1.009 релиз поверх utm5-2.1.009 rc3 стало валиться.
P.s. Починили падения ядра, но добавили другое, было бы забавно, если бы не было так печально.

mrmix25

аналогичная проблема

, перешел с 008 на 009 релиз.....

DVK · Сообщение **DVK** » Чт июн 28, 2012 16:48

И что, так никто и не разобрался в чем дело? Аналогичнейшая фигня, переход с 6й сборки на 9 release.

mrmix25

DVK писал(а):И что, так никто и не разобрался в чем дело? Аналогичнейшая фигня, переход с 6й сборки на 9 release.

логи в ротацию и всё

... а так в работе ни каких глюкофф не замечено ....... и конечно же ждем следующего обновления utm..........

DVK · Сообщение **DVK** » Ср июл 04, 2012 17:26

mrmix25 писал(а):
DVK писал(а):И что, так никто и не разобрался в чем дело? Аналогичнейшая фигня, переход с 6й сборки на 9 release.
логи в ротацию и всё ... а так в работе ни каких глюкофф не замечено ....... и конечно же ждем следующего обновления utm..........

Тогда еще и рамдиск под логи надо. А то оно винтом постоянно дрючит и ядро процессор жрет (в моём случае 25-27% по top).

DVK · Сообщение **DVK** » Чт июл 05, 2012 15:14

Попробовал в /dev/null дебаг лог завернуть. Слабо помогло, ядро жрёт процессор в огромных количествах (22-24%), на сборке 5.2.1-006 в тех же условиях ядро utmа - 0%.

xxxupg · Сообщение **xxxupg** » Чт июл 05, 2012 16:37

может поможет изменение log_level в конфигурации?

DVK · Сообщение **DVK** » Чт июл 05, 2012 17:53

xxxupg писал(а):может поможет изменение log_level в конфигурации?

Не помогает. Посмотрел логи внимательнее. Плодится по 200 с лишним записей по одному слинк_ид в секунду...

DVK · Сообщение **DVK** » Пт июл 06, 2012 15:26

Ну вот, официальный ответ от нетап получен. По мнению Нетапа выполнение биллингом ненужной операции более 200 раз в секунду для каждого сервис-линка, пока биллинг выполняет функционал, заявленный в документации - это не бага!
Интересно, руководство компании выгонит в шею тех "разработчиков", которые так считают и таки будет доводить до ума продукт? Или на будущем УТМа можно ставить крест?

DVK · Сообщение **DVK** » Пт сен 14, 2012 09:39

Интересно, неужели никто эти баги до сих пор не поборол? Или лень поделиться рецептом лечения?

mrmix25

DVK писал(а):Интересно, неужели никто эти баги до сих пор не поборол? Или лень поделиться рецептом лечения?

Поборол!!! откатился на UTM 5.2.1-008 (update 8 )

kkadd · Сообщение **kkadd** » Чт дек 13, 2012 08:58

Подскажите как правильно откатиться, ведь база проапдейтилась тоже.
А то у меня такая же фича + падает иногда.
Спасиб.

drag0mir

ребята кароче я тоже напоролся на этот баг, но не сразу, было всё ок.
появилось после того как врубил нетфлоу.
в кой то веки придумали опять тариф с ограничением по трафику, пришлось врубить ipcad после чего ядро биллинга стало грузить неимоверно проц.
отрубаю ipcad и о чудо в логах нет херни, и проц отдыхает ))
так что если нет нужды считать трафик, а нужду эту я изначально считал злом, то вырубайте нетфлоу.
а вот как быть мне сейчас - сам не знаю, пойду ковыряться дальше

Данная проблема признана багом, будет исправлена в ближайшее время.