Avamar: How to limit the size of the demand paging cache (f_cache2.dat)

The Avamar client demand paging cache (f_cache2.dat) is used on clients whose backups are directed to Data Domain. This file can grow to be up to 20x larger than the traditional 'monolithic' file cache (f_cache.dat).

From version 7.2-101-x, two new avtar flag files have been introduced. These flags allow the size of the cache to be carefully managed.

The flags cull selected backups from the cache file. The backups that are selected are based on perceived usability. This culling is intended to keep the number of backups stored in the file under strict control.

Because it may have detrimental effects* if used arbitrarily, this solution is OFF by default. It may be turned on for those (few) customers who really need it. A typical use case would be where a client's backups have been switched from using Avamar server to Data Domain back-end storage.

Note: The paging cache limitation feature does NOT reduce the cache size. It prevents it from growing. If the paging cache is already fully grown, it is necessary to delete the file and apply the limit. The cache can then be left to repopulate during the subsequent backup.


To limit the paging cache size:

Apply the following avtar flag.
--paging-cache-limit-enable

By default, the algorithm sets the size limit of the paging cache file to about 2% of the file system where the cache file resides. There is some leeway depending on the size of the backups.

This percentage can be changed using the flag (where x is an integer indicating a percentage value (say, 10%).
--paging-cache-limit=x

Where the paging-cache-limit-enable flag was used with default 2% limit, on a machine with a 15GB partition, with the paging-cache-limit-enable flag set, the paging cache did not grow past 309MB (approximately 2% of 15GB):

If later, the flag is removed, the paging cache continues to grow as normal on subsequent backups. 


Trade-off
As with most software tuning parameters, there is a trade-off to consider when limiting the size of the paging cache.

A smaller paging cache can hold fewer cache entries. This may result in an increase cache being missed when avtar walks the file system and attempts to compare the hash of the metadata with the entries in the file cache.

Missed cache entries result in avtar having to open and process the entire file. For large files, this may slow down the backup considerably. See the flow chart in the 'notes' to better understand this process.

Related KB articles:

• KB 62852: Avamar - How to interpret avtar backup log status lines.   
• KB 19552: Avamar client backup performance - behavior and theory 
• KB 13957: Information required by Support when investigating Avamar client backup performance issues.
• KB 19245: Avamar backup performance - tuning and tweaks to reduce backup run times.   
• KB 13952: Avamar: What happens when avtar reads a file during the file scan phase.