Unsolved
This post is more than 5 years old
132 Posts
0
1592
Info on "growth rate" of f_cache2.dat file?
Does anyone have any info they could share in terms of observations on the "growth rate" of f_cache2.dat file in newer versions of the Avamar client?
I had thought that I had seen this in a document somewhere, but I've checked the Tech Addendum, OBP and other documents, and I can't find anything.
I do find a lot of information about how big it can get, and why it gets that big, but I'm interested in the "growth curve", so to speak.
For example, does it grow like the f_cache file did, where it would double in size when it needed to? That is, if it was already at 1GB, would it grow to 2GB next, and then to 4GB (and again, I'm talking about the newer f_cache2 file - the older file was limited to 2GB or something like that).
Or could it potentially grow from 1GB to 4GB over the course of a single backup for that client if there was enough new data? And by that, I mean would it "skip" growing to 2GB and "go directly to" 4GB?
Working with a customer on a backup issue where we are getting messages about being unable to write to the f_cache2.dat file, and I have gone over the "do we have enough free space" aspect several times, and as far as I know, the customer has increased the filesystem size to accommodate a larger f_cache2 file if it grows "predictably" by doubling - but I need some kind of guideline if I'm going to tell them how to increase the file system even more.
I am aware that I can also limit the size of the f_cache2 file in newer versions of the Avamar software, but I'm not sure whether I can implement that change while the agent is still in this state of still trying to increase the fcache2 file size. I'd prefer to get things working again and then set the limit to whatever size the file was going to try to go to next - if I could only find that info.
All comments/feedback appreciated - thanks.
ionthegeek
2K Posts
0
January 18th, 2018 09:00
The paging cache does not double like the monolithic cache did. It will allocate more pages (and grow incrementally) as needed.
connolly
132 Posts
0
January 18th, 2018 09:00
OK - so in a manner of speaking, would that mean its growth is "less predictable"? If so, should we have some additional guidelines relative to making sure that we have adequate space for that growth on the filesystem where the cache file is located? (other than the info already provided in the OBP document?) - maybe specify a minimum amount of filesystem
space required for the Avamar agent install to accomodate "reasonable" cache file growth (which may already be listed somewhere - but I don't recall whether it takes something like a "reasonable" cache file growth into consideration, or just considers making sure that the cache can grow to at least 1GB).
The reason I'm asking is that in my situation, we are talking about a cache file for the following sized backups, with only a 0.1% change rate each:
Client 1 - Backup #13 timestamp 2018-01-16 20:25:08, 702,502 files, 202,585 directories, 28.71 GB (4,413 files, 19.56 MB, 0.07% new)
Client 2 - Backup #14 timestamp 2018-01-16 20:13:47, 434,855 files, 142,683 directories, 79.16 GB (1,511 files, 80.82 MB, 0.10% new)
FWIW, as this is the start of a project at this customer, these are both clients that we have only started backing up recently, so we haven't reached the "magic" 16 backup count that the cache file apparently keeps track of (and also, FWIW, we are only using 1 dataset for each client, other than the on-demand test backups that we have run). Another FWIW - these clients were backing up successfully up until a couple of days ago - the client with the larger number of files started failing first, with the other client failing one backup iteration later (so one of them likely started failing after the first 11 backups worked OK, with the other one failed after the first 12 worked OK)
Maybe I'm not fully clear on how many cache entries this new approach is going to need to keep track of what it needs to?
connolly
132 Posts
0
January 18th, 2018 10:00
FWIW, there's another discussion out there about an issue from back in Avamar 7.0 where the f_cache2 file was "limited" in AIX (which is the OS I am seeing this on) as well as other "*nix" OS:
Avamar 7.0 fatal error when f_cache reaches 2GB
Not sure if my issue has anything in common with that one - can't find any other info on it right now other than what is mentioned in that discussion.