Is the Day (istatus 120) trending needed by DM for any reason? If not, is it possible to stop DM from putting those entries in the avg database tables? It appears to me that if the TTL for both Hour and Day avg trend data are the same, as they are by default, then there really isn't really any need or purpose for these data points to be in the database. Why would you use Day data when you have Hour data for the same time period. In MySQL systems the simple fact that they are in the tables adds the same load to the database cleaning thread queries as the Hourly and 5 min data does so on large systems with large tables where the cleaning process is failing not adding the Day entries to the table could possibly make a big difference in the cleaning thread process performance.
Thanks
Jeff,
Indeed I must agree if the TTL is the same for all the trend windows there is no point in saving that data. The reasoning behind it is indeed to configure the TTL for those points to be kept longer than the 5min or 1h points. I checked and there is no option to disable the writing of these points.
The request just fetches all average trend points in a certain time span (1h, 1d, 1w, all). No matter the TTL configuration. The only time the graphing logic changes is when you zoom in far enough it switches over from average to real-time trend point (if they are present).
Davy, once again thanks for the response.
My pleasure.
Thanks for the response. Do you know if the trend graphing logic uses it depending on the zoom level/time span that the user is asking to display? One option I have to limit this data would be to set its TTL to the min of 15 days but if the graphing logic is only using the day data under certain zoom/time spans or in the history slider at the bottom of plots then that would be a problem.
Thanks again