wallet storage directory inefficient with large number of addresses

[cebe]

I am running a multichaind network where each node manages a lot of addresses. One node for examples currently has 31039 addresses. The wallet.dat file is 7.4MB, which sounds quite okay, but the wallet directory contains 620388 files and according to du takes about 52G disk space. Accessing the multichain API for information and creating new transactions takes a lot of time.

Are there any plans on improving this? Or is there anything I can configure to make it more efficient?

[gidgreen]

Can you please show us which files are taking up all this space?

[cebe]

In datadir:

# ls -lah
total 46M
drwxr-x--- 7 multichain multichain 4.0K Dec 18 21:53 .
drwxr-x--- 4 multichain multichain 4.0K Nov 10 14:12 ..
drwx------ 3 multichain multichain 4.0K Nov 10 14:06 blocks
drwx------ 2 multichain multichain 4.0K Dec 18 15:47 chainstate
-rw------- 1 multichain multichain    0 Nov 10 14:06 db.log
-rw------- 1 multichain multichain 668K Dec 18 21:53 debug.log
-rw------- 1 multichain multichain 8.7M Dec 18 15:57 entities.dat
drwx------ 2 multichain multichain 4.0K Dec 18 15:47 entities.db
-rw------- 1 multichain multichain   70 Dec 18 21:53 fee_estimates.dat
-rw------- 1 multichain multichain    0 Nov 10 14:06 .lock
-rw-r----- 1 multichain multichain  152 Nov 10 14:01 multichain.conf
-rw------- 1 multichain multichain 8.6K Nov 10 14:06 params.dat
-rw------- 1 multichain multichain 2.7K Dec 18 21:53 peers.dat
-rw------- 1 multichain multichain 3.7M Dec 18 15:57 permissions.dat
drwxr-x--- 2 multichain multichain 4.0K Dec 18 15:47 permissions.db
-rw-r----- 1 multichain multichain 449K Dec 18 15:57 permissions.log
drwx------ 3 multichain multichain  25M Dec 18 15:57 wallet
-rw------- 1 multichain multichain 7.5M Dec 18 21:53 wallet.dat
# cd wallet
# ls -lah | wc -l
634918
# du -sh .
55G .
# ls -lah |head -n 25
total 54G
drwx------ 3 multichain multichain  25M Dec 18 15:57 .
drwxr-x--- 7 multichain multichain 4.0K Dec 18 21:53 ..
-rw------- 1 multichain multichain  15M Dec 18 15:57 txs00000.dat
drwx------ 2 multichain multichain  12K Dec 18 15:47 txs.db
-rw------- 1 multichain multichain  52G Dec 18 15:57 txs.log
-rw------- 1 multichain multichain    0 Dec 18 15:57 uncsend_15110.dat
-rw------- 1 multichain multichain    0 Dec 18 15:57 uncsend_15111.dat
-rw------- 1 multichain multichain    0 Dec 18 15:57 uncsend_15112.dat
-rw------- 1 multichain multichain    0 Dec 18 15:57 uncsend_15113.dat
-rw------- 1 multichain multichain    0 Dec 18 15:57 uncsend_15114.dat
-rw------- 1 multichain multichain    0 Dec 18 15:57 uncsend_15115.dat
-rw------- 1 multichain multichain    0 Dec 18 15:57 uncsend_15116.dat
-rw------- 1 multichain multichain    0 Dec 18 15:57 uncsend_15117.dat
-rw------- 1 multichain multichain    0 Dec 18 15:57 uncsend_15118.dat
-rw------- 1 multichain multichain    0 Dec 18 15:57 uncsend_15119.dat
-rw------- 1 multichain multichain    0 Dec 18 15:57 uncsend_15120.dat
-rw------- 1 multichain multichain    0 Dec 18 15:57 uncsend_15121.dat
-rw------- 1 multichain multichain    0 Dec 18 15:57 uncsend_15122.dat
-rw------- 1 multichain multichain    0 Dec 18 15:57 uncsend_15123.dat
-rw------- 1 multichain multichain    0 Dec 18 15:57 uncsend_15124.dat
-rw------- 1 multichain multichain    0 Dec 18 15:57 uncsend_15125.dat
-rw------- 1 multichain multichain    0 Dec 18 15:57 uncsend_15126.dat
-rw------- 1 multichain multichain    0 Dec 18 15:57 uncsend_15127.dat
-rw------- 1 multichain multichain    0 Dec 18 15:57 uncsend_15128.dat

From the above I see that most of the space is taken by txs.log, what is that file used for? There are also 634918 files in that directory, are these necessary?

[gidgreen]

If you upgrade to MultiChain 1.0.2, it keeps the size of this log file in check.

[cebe]

sorry, I did not understand what you were trying to say, could you please elaborate?

[gidgreen]

What version of MultiChain are you using? You can see when you launch it.

[cebe]

this one was 1.0.1, I will try 1.0.2 and see if it behaves differently.

[cebe]

This seems to be fixed in 1.0.2, thanks.