Критическая ситуация с переходом на новый рассчетный период

[zooxel]

Добрый день.
Прошу разобраться с ситуацией. У нас установлен UTM 5.2.1-001.
С 1 октября 2006г. в 24:00 биллинг начал действия по переводу абонентов
на новые рачтеные периоды (новые тарифные планы, списания денежных
средств). Однако этот процесс продолжается до сих пор - УЖЕ БОЛЕЕ
СУТОК. Админкой подцепится к ядру не получается
Ситуация критическая!!!! Прошу принять меры.

Все это время в логах сыпятся однотипные строчки:

?Debug : Oct 02 08:14:05 DBCtx: SQL query: UPDATE dtagg_iptraffic SET discounted='0.000000', discounted_without_tax='0.000000', bytes='0' WHERE id='550326'
?Debug : Oct 02 08:14:05 DBCtx: SQL query: UPDATE dtagg_iptraffic SET discounted='0.000000', discounted_without_tax='0.000000', bytes='0' WHERE id='550327'
?Debug : Oct 02 08:14:05 DBCtx: SQL query: UPDATE dtagg_iptraffic SET discounted='0.000000', discounted_without_tax='0.000000', bytes='0' WHERE id='550328'
?Debug : Oct 02 08:14:05 DBCtx: SQL query: UPDATE dtagg_iptraffic SET discounted='0.000000', discounted_without_tax='0.000000', bytes='0' WHERE id='550329'
?Debug : Oct 02 08:14:05 DBCtx: SQL query: UPDATE dtagg_iptraffic SET discounted='0.000000', discounted_without_tax='0.000000', bytes='0' WHERE id='550330'
?Debug : Oct 02 08:14:05 DBCtx: SQL query: UPDATE dtagg_iptraffic SET discounted='0.000000', discounted_without_tax='0.000000', bytes='0' WHERE id='550331'
?Debug : Oct 02 08:14:05 DBCtx: SQL query: UPDATE dtagg_iptraffic SET discounted='0.000000', discounted_without_tax='0.000000', bytes='0' WHERE id='550332'
?Debug : Oct 02 08:14:05 DBCtx: SQL query: UPDATE dtagg_iptraffic SET discounted='0.000000', discounted_without_tax='0.000000', bytes='0' WHERE id='550333'
?Debug : Oct 02 08:14:05 DBCtx: SQL query: UPDATE dtagg_iptraffic SET discounted='0.000000', discounted_without_tax='0.000000', bytes='0' WHERE id='550334'
?Debug : Oct 02 08:14:06 DBCtx: SQL query: UPDATE dtagg_iptraffic SET discounted='0.000000', discounted_without_tax='0.000000', bytes='0' WHERE id='550335'
?Debug : Oct 02 08:14:06 DBCtx: SQL query: UPDATE dtagg_iptraffic SET discounted='0.000000', discounted_without_tax='0.000000', bytes='0' WHERE id='550324'
?Debug : Oct 02 08:14:06 DBCtx: SQL query: UPDATE dtagg_iptraffic SET discounted='0.000000', discounted_without_tax='0.000000', bytes='0' WHERE id='550325'
?Debug : Oct 02 08:14:06 DBCtx: SQL query: UPDATE dtagg_iptraffic SET discounted='0.000000', discounted_without_tax='0.000000', bytes='0' WHERE id='6754'
?Debug : Oct 02 08:14:06 DBCtx: SQL query: UPDATE dtagg_iptraffic SET discounted='0.000000', discounted_without_tax='0.000000', bytes='0' WHERE id='23512'
?Debug : Oct 02 08:14:06 DBCtx: SQL query: UPDATE dtagg_iptraffic SET discounted='0.000000', discounted_without_tax='0.000000', bytes='0' WHERE id='550323'
?Debug : Oct 02 08:14:06 DBCtx: SQL query: UPDATE dtagg_iptraffic SET discounted='0.000000', discounted_without_tax='0.000000', bytes='0' WHERE id='25276'
...

Все логины, пароли и другие параметры доступа к серверам выслал на почту supinfo@netup.ru

[Spar]

Добрый день.
Прошу разобраться с ситуацией. У нас установлен UTM 5.2.1-001.
С 1 октября 2006г. в 24:00 биллинг начал действия по переводу абонентов
на новые рачтеные периоды (новые тарифные планы, списания денежных
средств). Однако этот процесс продолжается до сих пор - УЖЕ БОЛЕЕ
СУТОК. Админкой подцепится к ядру не получается
Ситуация критическая!!!! Прошу принять меры.

вам надо комп апгрейдить
как минимум десять процессоров , пол ведра оперативки и сказёвый райд-5 с 100-гиговыми хардами

тогда то,что сейчас utm делает сутки, будет делаться за пару минут

[zooxel]

Вся проблема в том, что у нас железо примерно такое же, как вы написали, но это не помогает

Нетап посмотрел и сообщил, что т.к. много обсчитываемого трафика, необходимо на это время отключить сбор статистки по netflow. Пришлось дать абонентам халяву и через 3-4 часа все действительно обсчиталось.

[Spar]

а юзеров в билинге скока ?

[zooxel]

1500 абонентов и около 30-40Тб трафика в месяц.

[azazello]

А вот какой интересный факт произошел в прошлом месяце.
В 00-00 создался новый расчетный период длинною 2минуты 34секунды, такого никогда не случалось раньше и никто не контролировал переход. В результате у всех абонентов снялась 2 раза абонплата.
При переходе на этот месяц ситуация немного изменилась и создался новый расчетный период почему то до 30 октября 23-00
При чем на 2-х разных серверах одинаково! Что ещё больше удивило.
Вопрос. Как такое могло произойти?
Это получается что нужно во время каждого перехода следить за созданием нового периода и в случае глюка править?