About open unsolidifiedBlockCheck #6418
Description
A follow up issue from #6414, for memory OOM risk when more than 1/3 SR dis-connected, or blocks cannot be solidified. Checked from the logic, java-tron do have logics to mitigate this process, refer #6414 (comment). With this logic, after node.maxUnsolidifiedBlocks(default is 54), SR will only generate empty blocks, which will cost much less memory(～1KB). However, further examination of the logic reveals that the config unsolidifiedBlockCheck controlling this logic is disabled by default.
Thus, I want to ask the community whether it is necessary to enable this flag in time, defaulting to true?
The image below shows my experimental results. I tested on a FullNode that stays synchronized with the Mainnet, except the solidification logic was turned off. The memory consumption with 4677 unsolidified blocks is 5.57GB, check the image below.
As can be seen in the image above, besides KhaosDatabase, there are Chainbase costs totaling about 4GB. These 2 together already takes 9.57GB.
To generate 4677 unsolidified blocks means at most 18 working SRs takes about 5 hours 50 minutes, less than one maintenance cycle. That is, under conditions where solidification is impossible, SRs may not even survive one maintenance period before encountering OOM, without sufficient time for the community to re-vote and elect new SRs, in case the failed SRs cannot be recovered.