Regarding the -xn are you using 8.10.7 GHC or the 8.10.4 one?
On 8.10.4 it has issues.
I’m using 8.10.7 but this is a rare issue. The -O parameter vastly decreases the number of major GC performed and thus the probability to trigger the current instabilities in the RTS with -xn
In fact this -O parameter is a gem! I’ve looked for such a parameter but somehow missed it. With this and -F you can actually enforce a maximum soft limit on the memory usage without the caveats of the -M flag (which enables the compaction GC at a certain threshold severely degrading the performances).
To follow up on my previous post: -O does not prevent -Iw from triggering a major GC even well below the threshold set by -O.
I’m doing some tests concerning memory usage right now, I will report in this other thread to keep things separate.
1 Like
No -qb or -qg options?
8.10.7, last time I tried I got this after ~33 hours:
cardano-node: internal error: END_STM_WATCH_QUEUE object (0x4857750) entered!
(GHC version 8.10.7 for x86_64_unknown_linux)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
No, because -qb without a generation number disables the load balancing which increases the time it takes to make a GC (we want to reduce it)
In the same way, -qg without a generation number behind disables the parallel GC making it N times slower according to the documentation. Moreover enabling it only for older generation is not suitable either because gen 0’s GC (or small GC) are not the ones causing missed slots, and since I’m using a big generation 0 of 1G (4*256m), I need this generation GC to be as fast as possible too.
1 Like
Weird, didn’t happen to me.