Indeed, after shutting down the node, all that heap is released

Well, I suppose it's not a problem yet, as long as it stays in reasonable levels (about half a gig now, after querying data)

there are caches used by the node which may be big, but that isn’t a problem if you don’t need the memory for something else

looks like the second change cache has a background thread that monitors memory use

Yeah, but would be good to have some way to estimate the cache sizes

I'm guessing that the rocks cache is bounded, but does xt then keep a reference to all the documents that happen to be in the cache? Or is it just something completely unrelated.

We do have this issue open where you'd be very welcome to pose such questions (I'll link back to this thread at least, anyway) https://github.com/xtdb/xtdb/issues/1830 In short though, managing memory usage is a tricky balance between: 1. performance - caches make things fast so use memory if it's available 2. robustness - we don't want OOMs or to cause non-XT performance to suffer unpredictably 3. user-friendliness - defaults should be sane but exposing levers is often necessary As per the issue, we need to review the defaults at some point.

Which version of XT?

> the second chance cache has a background thread that monitors memory use note that the second chance cache has been disabled (in favour of LRU) as of 1.22.0, due to unresolved memory issues

1.23.0

Looks like the questions in the issue pretty much cover the subject

> I'm guessing that the rocks cache is bounded that's definitely true of the block cache as I understand things, although Rocks will perform various allocations for other reasons > does xt then keep a reference to all the documents that happen to be in the cache? XT has no visibility of what's inside the Rocks cache