I have a couple of clients that are going to start getting aggressive with triming data; although the monitor.db / log files cannot be changed in size; they are looking at the performance directory and are looking to purge any files / directories over one to two years old. I have been advising against it but i understand their concerns as the perf directory seems to be growing at the rate of 10 GB a month and is pushing against a hard capacity limit on the server.
The abnormal growth in perf data, may be due to deleted objects not being purged.
You might be a victim of bug 439756.Open a NGS case and clean up.
is there a way to control the size of the perf directory?
No.But you can control how long you what to retain the perf data for each counter group, and each individual filer using the cli or also the NMC.
dfm perf data modify [ -f ] -G <counter-group-name> [ -o <host-name-or-id> ]
[ -s <sample-rate> ] [ -r <retention-period> ]
Yes we have chatted about moving to a iscsi lun but even that has a limit and even with compression and dedup possibilities ( even all the magic in the world cannot grow 173 GB parition any larger ). The size of their current DFM install is around 120GB right now and in six months i expect the 173 GB disk to be filled. We have reduced the amount of DFM backups to once a day, we have evaluated each monitored controller to see if we really need perf stats collected ... yet the install base grows and grows ( slowly ).
will new versions of DFM ( on command, etc ) will introduce hard caps on database growth?
No.But did you would like to trim your db get a case open against the bug to see if you can cleanup some history tables.
Bug 447658
Regards
adai
