Chain folder keeps growing

0 votes


I ran a test last night, in which I wanted to issue 30 000 assets from one node to another - nothing new, we done it many times. The only parameter we changed in params.dat file before we started this test is "mining-diversity", and set it to 0.75.

The setup was: three nodes on three servers "blockserver1", "blockserver4" and "blockserver5". The last one was connected to blockchain but stayed idle.

However, very strange thing happened. After our program finished inserting assets on server "blockserver1" onto address of node on "blockserver4", debug.log on "blockserver4" continued to write data (you can find most representative display in file "bs4-utst6-tail-debug-excerpt.png" of .zip archive I'll link later). We left it overnight, and when we came into the office this morning, folder "utest6" which was the name of the chain that we tested on was 58GB in size.

We left it for another 20ish minutes and checked it again. It grew to 59GB.

listassets command lists just 30 000 assets, our program is not working anymore (triple-checked it with additional top and ps -ef commands on all servers).

We wanted to know why this strange thing had happened. Also, I zipped some screenshots of our terminal (it would be insane if I zipped whole directory) with "du -h" and "tail -f debug.log" commands, and you can find it on following link: .

Also, if you have anything else you need, just send me a message, and I'll provide it to you.

Thanks in advance,

asked Mar 30, 2016 by SlobodanMargetic
Thanks for this. What would be most helpful is a zip of the last (say) 100 MB of the debug.log file on the node 4 that behaved strangely - that should provide a clue.
The link for the last ~100MB of debug.log file is on:
Thanks - we are shortly releasing alpha 19 but will look into this for alpha 20.
have you menaged to decrypt what is causing this? could it be that diversity was set too high for just 3 nodes (0.75).
Not yet, but we have it on the list to get to.

1 Answer

0 votes
No, it is not related to diversity.

Some of the assets were not confirmed. Miner running on blockserver4 tries to add these "issue" transactions to the block, but for some reason this block was not accepted by the node. This is the reason for constantly growing debug.log - miner writes details of just found blocks again and again.

Unfortunately, from the log it is not clear what is the reason for the failure. Can you please run multichaind with "-debug=mchn" flag? In the beginning, it should shrink debug.log to some reasonable size and then it should start growing again. You can stop it after couple of minutes. Only 20000 last rows of debug.log are relevant.

The following files may also help to analyse the problem: entities.dat and permissions.log
answered Apr 18, 2016 by Michael