Unsolved
This post is more than 5 years old
2 Intern
•
132 Posts
0
2448
January 18th, 2018 13:00
Looking for clarification on new "paging-cache-limit-enable" avtar flag
I'm looking for any clarification that can be provided on the new "paging-cache-limit-enable" avtar flag, as described in KB516151 - with the understanding that it might not be well known since the KB itself is at most 2 weeks old.
Basically the KB implies that the parameter by default "will set the size limit of the paging cache file to about 2% of the filesystem", and then provides an example of "with default 2% limit, on a machine with a 15GB root filesystem, with the paging-cache-limit-enable flag set, the paging cache did not grow past 309MB (approximately 2% of 15GB)".
It follows that with another flag "--paging-cache-limit=x" that can apparently be used to change the percentage value to something other than the 2% default.
However, in trying to explain this to a Unix admin, they want clarification on what the KB means by "root filesystem" - I think they are overthinking whether it means volume group, partition, filesystem, or something else.
Also, I am trying to find out if there is an option to set the cache file size limit to a fixed value in GB or MB, as opposed to a percentage. The same Unix admin is saying that the var directories on their systems are typically the same size regardless of the overall volume size of the whole system, or something closer to what the "root filesystem" size might be.
Seeing that limiting the file cache size has more to do with making sure it doesn't fill up whatever the vardir is than any other filesystem, and also more to do with the number of files being backed up than their capacity, it would be surprising if there was only one way to set this value.
Of course, it's also understood that there are tradeoffs to going with this approach, as it limits the size of the cache file (and those are discussed in the KB) - so I will be discussing other options with the customer as well as this. But if this flag is being proposed as one solution to this issue (which it would appear can very easily arise in any situation where there are a large number of files on a server that might not have that much capacity), then it would be good for it to have some guidelines associated with it in terms of which of those situations it was best suited for, and parameters that reflected that.
All comments/feedback appreciated - thanks.
Avamar Exorcist
462 Posts
1
January 25th, 2018 05:00
I have updated the KB 516151 to change the wording from 'root file system' to 'partition'.
There isn't an option to define a maximum absolute size for the paging cache, only the proportion of the partition which it's allowed to consume.
You could submit an RFE with your requirement - refer to KB 490089 but it's not really a good idea to encourage regular use of this parameter since it prevents the cache from behaving as intended and doesn't address the root cause of the problem on the client, namely, lack of space..
connolly
2 Intern
•
132 Posts
0
January 25th, 2018 07:00
Also, FWIW - the example in KB 516151 for the 15GB partition with the default 2% cache allocation that sets the cache file limit at 309MB?
By my calculations, that will only be able to keep track of a little around 180,000 files in total. That's not a lot.
connolly
2 Intern
•
132 Posts
0
January 25th, 2018 07:00
Thanks for making that change in the document - that makes it much clearer, IMHO.
Thanks also for the feedback - although, as you know, some customers might consider the cache to be the problem relative to how much space it wants to consume on the client, in certain cases. Especially when there is effectively no warning anywhere other than in the Best Practices document that the client cache is potentially going to grow to 20GB in a "typical" scenario.
If there is an expectation that 20GB of space could be required for client cache files, it might be a good idea to put that requirement in the Avamar Client documentation. Or even a smaller value, with additional information to clarify why the value is what it is. In the situation I am dealing with, we started seeing issues when the cache file got to 1GB - and that client barely has 1 million files (and the partition should have been able to accomodate the file growing beyond 1GB).
Still not sure why we had issues (the customer actually thinks it has to do with the AIX OS), but in troubleshooting them, I've seen how the cache file can grow substantially during the first 16 backups depending on the client's data - and IMHO, we don't set very good expectations for that in the documentation. For some other clients at the same customer, the cache files aren't even close to 1GB - but for some others, they are over 40GB.
IMHO, it seems a lot easier to augment the documentation a bit than to deal with multiple service requests as our cache files grow to the point where they use up remaining available space on what is typically either a WIndows system drive or a fairly important *nix system partition.
Danny101
10 Posts
0
January 14th, 2019 05:00