BiTel

Появилась серьезная проблема. Планировщик начинает считать неправильно абонентские платы, максимальные трафики и т.д.
Вначале приходят письма с блокировкой шлюзов клиентом у который превышен лимит. Смотрим у них баланс положительный но в почту приходит сообщение о минусовом балансе. Смотрим наработки абон. плат все верные, кроме начислений максимальный трафиков. Делаем переабсчет максимальных трафиков - ничего не меняется, ошибок в планировщике нету. перегружаем планировщик, перезапускам максимальные начисления и все корректно считается.
Если в течении дня не перегрузить планировщик, тогда на следующий день начинает все криво считаться. У всех абонентов в наработках появляются одинаковые суммы.
После перезагрузки планировщика проблема повторно появляется через 2-3 дня.
Версия 5.1, проблема появилась недели 2 назад, по какой причине не поймем.
В логах никаких ошибок.
Когда проблема опять появится, что нужно сделать чтобы увидеть где идет затык?

Мб планировщику не хватает памяти? В момент затыка

и вывод сюда

Ну или же прямо сейчас поставьте значение побольше в scheduler.sh
допустим
Если ранее не меняли то там 256 стоит ЕМНИМС

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

До этого стояло 256, приходили ошибки о нехватки памяти. Поставили 512 - ошибки о нехватки памяти перестали приходить.
После вашей рекомендации поставили 1024 и понаблюдаем за процессом.
О результатах сообщим.

Ошибок в логах при этом никаких нет?

при проверке шлюза появляются только такая ошибка
WARN [pool-3-thread-4] ScriptInstance - 1.1.1.1:23: using deprecated class [bitel.billing.common.CommonUtils]
И все других ошибок нету.

Вот не прошло и пару дней, проблема снова появилась
Вот информация статуса

slave базу ну используете ?

Нет не используем.
Есть предположение что это происходит когда пытаемся изменить тариф который был поставлен по ошибке и при этом отключаем
проверку закрытых периодов closed.date.enabled=1 ставим 0 меняем тариф потом ставим 1.
И кажется после этого начинается проблема.
Сейчас не будем трогать закрытый период и посмотрим начнется появляться ошибка или нет.