Use hibernation rather than manual garbage_collect calls as per standard recommendation. Hibernate will be default gabage_collect anyway. Maybe help with SST files that naturally go quiet.
Plus typos from previous commit in leveled_cdb.
CDB files may be opened or rolled then left untouched for a period, so clean up any memory. Been awoken from hibernate has a cost, but it is a rare event.
Now that the SST files will fadvise on load (to force load into the page cache). The load should take place in reverse order, so that if th eledger is > page_cache, it is the higher levels that will end up in the cache at the expense of the lower levels.
Two helpers for memory management:
1 - a scan over the cdb file may lead to a lot of binary references being made. So force a GC fater the scan.
2 - the penciller files contain slots that will be frequently read - so advice the page cache to pre-load them on startup.
This is in response to unexpected memory mangement issues in a potentially non-conventional setup - where the erlang VM held a lot of memory (that could be GC'd , in preference to the page cache - and consequently disk I/O and request latency were higher than expected.
Extracting binary from within a binary leaves a reference to the whole of the original binary.
If there are a lot of very large objects received abck toback - this can explode the amount of memory the penciller appears to hold (and gc cannot resolve this).
To dereference from the larger binary, need to do a binary copy
When there is hevay PUT load, leveled_sst files could go into the delete-pending state befre the GC message is receieved - and the GC message would then interrupt the timeout cycle and lead ot the file not being GC'd until close.
in OTP R16 (and perhaps other OTP releases) there is a failure to fully garbage collect leveled_sst files after thya have initialised. They sppear to maintain a 4MB "hangover" from the initialisation process.
This can be removed by manually calling garbage_collect. So we do this now on all new non-L0 files. A L0 file will be short-lived or switched - short-lived and it doesn't matter, switched and this is already GC'd.
The L0 Pid has used a lot of memory in the construction of the file (something like 50MB). This won't be GC'd immediately. This is fine, as this will normally be short-lived. However if the SST file is switched levels ... then this may mean thta we have multiple SST files with memory not being GC'd.
