Re: [jopr-dev] reducing purge times

I think the system should should function irrespective of what the default purge intervals are and irrespective of how long the database and/or all servers have been down (and thus how much backlog there is to purge / compress). it's nice to give users reasonable out-of-the-box defaults for this things, but IMO the more pressing concern is really http://jira.rhq-project.org/browse/RHQ-1355 to answer your question specifically, i would, as a user of a sys mgmt tool, like to keep data forever (so that i can correlate changes to data over long periods of time to understand how my business is growing, estimate future hardware needs, analyze the utilization of the virts in my enterprise, etc etc). 2nd to that, i'd like to keep data for as long as possible such that the monitoring tool still performs. but without RHQ-1355 in place i think the following are reasonable defaults: RT data - on the one hand, i could see the benefit of mimicing whatever our purge intervals for measurements are (1 yr, i believe?) so that the monitor tab has consistency of data - i.e., i don't want to click on one tab and see data and click over to another tab and see missing data. RT data is very similar metric data in that way. however, RT differs from it because it's not gracefully compressed over time like measurement data is. so, i'd probably want the RT purge interval to be equal to however long we keep raw measurement data before compressing it - i think that's 14 days? Trait data - we could easily extend this to 1 year. traits change very infrequently, and many resources don't have any traits. so, we can easily bump this way up without impacting the system. Availability data - since this is run-length encoded, we *should* be able to keep this data for a long time. i wouldn't think that we need to set this to anything smaller than 31 days in order to keep the system performing. John Mazzitelli wrote: