Would like to report a problematic behavior on a linux system, 8 GB of RAM, while running ./bn -l in order to show hashmap collision stats of the node's store.
Few seconds after running, the node is killed by the OS with a SIGKILL. The issue is relevant since the termination eventually corrupts bn's database, needing for chain re-download from start (lacking intermediate snapshots).
Increasing the swap memory in order to make the total system memory above that figure solves the problem, even if it runs quite slow.
Could be helpful to rise a warning on low RAM system to prevent db corruption while running the command.
Would like to report a problematic behavior on a linux system, 8 GB of RAM, while running
./bn -l
in order to show hashmap collision stats of the node's store.Few seconds after running, the node is killed by the OS with a SIGKILL. The issue is relevant since the termination eventually corrupts bn's database, needing for chain re-download from start (lacking intermediate snapshots).
It appears that this behavior depends from the system running out of memory (e.g. see https://stackoverflow.com/questions/11779042/sigkill-while-allocating-memory-in-c). Further analysis shows that the command demands a peak memory usage of about 16 GB.
Increasing the swap memory in order to make the total system memory above that figure solves the problem, even if it runs quite slow. Could be helpful to rise a warning on low RAM system to prevent db corruption while running the command.