Alexey Pechnikov wrote:
Ну это уже минусы нашей биллинговой системы. Переписать её по другому возможности нет. Нет у неё такого функционала. Да и суппорта такими переделками лишиться можно. Жаль, но вот такие недостатки. Плюсом биллинг не умеет писать логи размером >2Гб. Не понимает SIGHUP и отваливается если один из логфайлов забит. Ротейта предусмотрено не было, ротейтим логротейтом с параметрами size, prerotate, postrotate... Уж как есть.Да, клиентская сторона преимущественно на яве. Клиентов ~30. Процентов 80-90 - инсерты в схему + процедуры их обработки. База обсчитывает телематические услуги ~1000 пользователей. При обработке данных за месяц (билинговании) возникают как раз те проблемы, от которых желаем избавиться - сейчас на обсчёт уходит несколько часов. С половины суток это время снизили до 3х часов примерно. Узкое место сейчас io_wait, доступ к винтам (они 7200, sata, raid-5, аппаратный на LSI ). Смотрим в сторону внешнего сановского сториджа c FC интерфейсом и сановского сервака.Понятно. Я от подобных проблем ушел путем использования материализованных видов - обработка данных происходит непосредственно при их вставке, что позволяет в любой момент получить итоговые данные. В оракле материализованные виды есть из коробки, в постгресе подобную функциональность можно самому написать. Если возникают проблемы с производительностью при вставке, можно выполнять пакетную обработку (небольших наборов данных) в моменты простоя системы. А считать все за один раз единожды в месяц - абсолютно неэффективное разбазаривание ресурсов. Скажем, расчет идет 3 часа, запускается раз в месяц, эффективность использования ресурсов около 1/4 процента.