GC and Checkpoint/HFS Check settings

Question

Hi, my question is about how to change the settings of the HFS Check and the Garbage Collection in a Avamar 4.1 system. How can I do this and where are the files which include these settings? E. g. I want to increase the GC duration to 3h. And I want to increase the number of checkpoints that will be available after successful HFS Check. As I know after a successful HFS Check the 'oldest' Checkpoint will be deleted but there is a option to increase the number of available checkpoint so you will have e.g. 3 or 4 checkpoints. Is this so?

BWagnerAZ · Accepted Answer

To alter gc duration in 4.1:

make a copy of the original gc_cron script.

cp -p /usr/local/avamar/bin/gc_cron /usr/local/avamar/bin/gc_cron.bkup

alter the timeout option in the gc_cron file:

dpncron::init("gc_cron", "gc", 4200,
"--killsnapups=300 --infomsgs --verbose --passes=0 --timeout=7200 --pollrate=60 --nofull --conversion --convcount=50 --convtime=600 --throttlelevel=0 --nousehistory");

Changge --timeout=7200 to --timeout=10800 in order to extend it to 3 hours.

To expand the number of checkpoints retained:

avmaint config --ava | grep cp

avmaint config --ava cpmostrecent={number of cps you wish to retain}

Confirm your change:

avmaint config --ava | grep cp

Avamar Exorcist · Answer

I would recommend against changing the checkpoint retention and garbage collection run time from the default parameters.

The most recent validated checkpoint will always be preserved and this should be sufficient for redundancy purposes. Avamar is tuned such that when it runs close to the User capacity limit, there is sufficient OS space available to store checkpoints and to allow other maintenance tasks (such as stripe crunching and garbage collection) to run.

By increasing checkpoint retention without a specific technical reason you will potentially increase the amount of checkpoint overhead on the system and put the system at risk of running short of OS space. The closer the system is to the User capacity limit, the more problematic this can be. Checkpoint retention is normally only changed during system maintenance, to provide additional point-in-time redundancy.

Garbage collection also should be tuned only after a proper assessment of its performance. Check the /usr/local/avamar/var/cron/gc.log to compare how many stripes there are with how many GC is able to process during its run time. Increasing the run time is not the only way to increase performance. The type of data nodes being used will have a bearing on how it can be tuned. If you have a real issue, discuss it with support before making any changes.

Avamar v5's maintenance windows allows changes to be made more intuitively, from an end user point of view, by increasing or decreasing the blackout window. As on version 4, if you are wondering whether to make changes to the blackout window, use the capacity.sh script to compare ths amount of data removed with the amount of data added (see esg103967).

As with any change you make to the system there will be some trade-off - make sure you fully understand what those trade-offs before doing anything. The default parameters were chosen because they were found to be be most appropriate on the vast majority of customer systems.

Alla1965 · Answer

Exactly that what I wanted to know and it works! :-) Thank you very much!

Alla1965 · Answer

I absolutely agree with you to be careful with these settings. I know about the default parameters and I also understand why these parameters are set as they are. I will do this only for test purpose. Thank you for your detailed description of the relation of these parameters to the overall Avamar system.

Avamar

GC and Checkpoint/HFS Check settings

Was this post helpful?