Cardano node 1.30.1 ARM64 (aarch64) compiled binaries

I mean your next block. With a simple script you can determine reasonable restart points depending on the leaderlog.

The above shows epoch/no slot, restart time, block time. You’ll notice that the restart happens 2h before the next block, unless this would interfere with a previous block. Two hours should give the node plenty of time to restart even with a dirty block store. I observed that major GCs happen a lot less frequently (if at all) during the first few hours of uptime - for me it turns bad after 8h or so. Unfortunately, I don’t yet have good and conclusive results worth publishing - each of my tests runs for 24h.

The Haskell GC reminds me of the early days in Java. Over time that got much better. Halting the world does generally not work so well for non-trivial processes - especially not, if there is a real time aspect to it. Nonmoving GC can keep the mutator (MUT) alive, but should not result in a drastic memory increase. GC should not increase memory over time for it’s own bookkeeping - that would be a memory leak. Not sure, if that is the case here - the node might cause the increase of memory that we see over time. In that case, we might be seeing a mem leak in the node, which would be low hanging fruit for improvement.

2 Likes