We’ve got an application that regularly needs to see how the database looked at a specific time and we’re using
as-of. The logic works perfectly, but we’re seeing memory pressure issues. I’ve read the filtering docs, so my basic understanding is that the
as-of function filters the indexes (and the doc says this can (or perhaps it means will?) cause a full scan of the indexes.
Now, since the peer needs those to be in the object cache, I assume this means if the object cache isn’t big enough to hold all of the indexes that this is likely to cause GC thrashing (created the filtered version of the indexes, which become garbage at some near pt in the future when the as-of db itself is collected, I would assume).
I’m guessing the filtered indexes are stored on the heap of the app, as opposed to the object cache. So, if the indexes fit in the object cache the memory pressure is really on the heap of the application itself (creating filtered copies of the indexes).
So, from a memory tuning perspective I’m thinking I might want the object cache split to be enough to hold all of the indexes, but also enough VM RAM to house at least 1 set of filtered ones?
Basically I’m just trying to understand if there are internal optimizations that make the memory and CPU overhead of
as-of much less than the size of all of the indexes. We’re running several pulls and queries against each of these databases.
At the end of the day, I guess the answer is “give it as much RAM as you can afford”, but I’m wondering if the objectCacheMax split should be adjusted on a system that uses
as-of a lot.