send BTC is very slow with huge wallet

JokerCatz commented at 5:12 pm on February 6, 2016: none

my wallet.dat size : 358M and debug.log

 02016-02-06 17:03:09 keypool added key 54799, size=301
 12016-02-06 17:03:09 keypool reserve 54499
 22016-02-06 17:03:19 CommitTransaction:
 3CTransaction(hash=3dc010c216, ver=1, vin.size=1, vout.size=2, nLockTime=397048)
 4    CTxIn(COutPoint(5fc29785f4, 41), scriptSig={{hash}}, nSequence=4294967294)
 5    CTxOut(nValue=3.37993552, scriptPubKey=OP_DUP OP_HASH160 {{hash}})
 6    CTxOut(nValue=0.68241470, scriptPubKey=OP_DUP OP_HASH160 {{hash}})
 72016-02-06 17:03:19 keypool keep 54499
 82016-02-06 17:03:19 AddToWallet {{hash}}  new
 92016-02-06 17:03:19 AddToWallet {{hash}}
102016-02-06 17:03:19 Relaying wtx {{hash}}
112016-02-06 17:03:37 keypool added key 54800, size=301
122016-02-06 17:03:37 keypool reserve 54500
132016-02-06 17:03:47 CommitTransaction:
14    CTransaction(hash={{hash}}, ver=1, vin.size=1, vout.size=2, nLockTime=397048)
15    CTxIn(COutPoint({{hash}}, 1), scriptSig={{hash}}, nSequence=4294967294)
16    CTxOut(nValue=6.11253197, scriptPubKey=OP_DUP OP_HASH160 {{hash}})
17    CTxOut(nValue=0.61373803, scriptPubKey=OP_DUP OP_HASH160 {{hash}})

I need more fast to send BTC(now 1 send be ~30sec) , but…I don’t know how to fix it

the CUP usage always 100%+ , and my bitcoin.conf

0upnp=0
1maxconnections = 128
2server=1
3rpcthreads=8
4rpckeepalive=false
5rpctimeout=30
6rpcallowip=127.0.0.1
7rpcport=8332
8keypool=300
9paytxfee=0.0001

and getinfo

 0{
 1"version" : 110200,
 2"protocolversion" : 70002,
 3"walletversion" : 60000,
 4"balance" : {{skip}},
 5"blocks" : 397059,
 6"timeoffset" : -14,
 7"connections" : 14,
 8"proxy" : "",
 9"difficulty" : 120033340651.23696899,
10"testnet" : false,
11"keypoololdest" : 1454771625,
12"keypoolsize" : 301,
13"paytxfee" : 0.00010000,
14"relayfee" : 0.00005000,
15"errors" : ""
16}

please help me to fix it….many thanx…

maflcko commented at 5:55 pm on February 6, 2016: member

Unless you get an exact match, the coin selection algorithm will iterate over the whole unspent coin set at least a thousand times.

You can get the size of the coin set with $ src/bitcoin-cli listunspent 0 | grep -c spendable. Also, you can grep for the amount and see if there is a bunch of small coins.

Could you share the output of $ src/bitcoin-cli listunspent 0 | grep -c spendable? (Make sure you don’t post any amounts or txids to the public if you care about privacy)

JokerCatz commented at 6:14 pm on February 6, 2016: none

$ bitcoin-cli listunspent 0 | grep -c spendable 412

maflcko commented at 11:03 pm on February 7, 2016: member

Iterating over 412 coins is done in less than a second. This sounds more like #2511

You can add the -debug=db option to see how long it takes to flush the wallet.

02016-02-07 23:00:17 Flushing wallet.dat
12016-02-07 23:00:17 Flushed wallet.dat 8ms

JokerCatz commented at 4:07 am on February 8, 2016: none

02016-02-08 03:52:41 Flushing wallet.dat
12016-02-08 03:52:50 Flushed wallet.dat 9252ms

… 7xxx ~ 93xx ms and another logs

02016-02-08 03:58:40 AddToWallet {{hash}}  new
12016-02-08 03:58:42 Flushing wallet.dat
22016-02-08 03:58:50 Flushed wallet.dat 7960ms
32016-02-08 03:59:30 keypool added key {{int}}, size=301
42016-02-08 03:59:30 keypool reserve {{int}}
52016-02-08 03:59:32 Flushing wallet.dat
62016-02-08 03:59:40 Flushed wallet.dat 7964ms
7...

and

0bitcoin-cli listunspent 0 | grep -c spendable
1534

okay…so? how to fix this? like change to non-BDB ? or just loading balance add more node ? I think I can use docker to loading balance it … (NFS share old blk00xxx.dat to save hd space , all node keep last 2 blk00xxx.dat file , and export / import wallet to another node……)

laanwj renamed this:
~~send BTC is very slow...~~
send BTC is very slow with huge wallet
on Feb 8, 2016

laanwj added the label Wallet on Feb 8, 2016

maflcko commented at 12:23 pm on February 8, 2016: member

how to fix this?

You could switch to a SSD (replacing your HDD) to reduce the time of a flush to about one second
You could generate a new wallet if you don’t reuse your addresses:

The steps could be roughly like this:

0ADD=getnewaddress
1sendtoadderess $ADD $balance
2KEY=dumpprivkey $ADD
3[stop node]
4mv wallet.dat wallet.dat_2016_02_08
5[restart node]
6importprivkey $KEY

JokerCatz commented at 5:27 pm on February 8, 2016: none

I know how to export / import keys , but customer use our wallet solution & has (user <=> wallet) relation in DB , I can’t change/cancel customer wallet , so I will make more node to loading balance it (export / import wallets to 2+ nodes) & split receive and sender wallet be different node , daily transfer receive node BTCs to sender node , I think will be okay for this (( and sorry my poor english…:x , and Happy Chinese New Year , Dev team : )

pstratem commented at 7:48 pm on February 8, 2016: contributor

@JokerCatz are you using the “account” functions?

Note that they are deprecated and will be removed in a future release.

JokerCatz commented at 2:03 pm on February 9, 2016: none

^ you mean bitcoin-cli like sendfrom or like listaccounts , the “account” command will be remove? & we use JSON-RPC to call node command…

pstratem commented at 4:13 am on February 10, 2016: contributor

@JokerCatz #5575

JokerCatz commented at 9:05 am on February 10, 2016: none

okay~ I got it , thanx : )

laanwj added the label Resource usage on Feb 16, 2016

GamerSg commented at 7:17 am on February 27, 2016: contributor

@JokerCatz I previously encountered the same issue. What i did was dump all needed private keys to a text file, create new wallet, import needed private keys, rescan.

This got rid of a ton of change addresses.

sipa commented at 7:25 am on February 27, 2016: member

I wonder if, for wallets with very large numbers of UTXOs, we can’t just take a random subset of them to fund with…

maflcko commented at 8:39 am on February 27, 2016: member

@sipa I think this issue is more about the delay caused by flushing the wallet after using a change address for creating the transaction and less about the performance of the coin selection code.

JokerCatz commented at 8:50 am on February 27, 2016: none

yep , I dump and import all customer address private key …… wallet.dat from 480 MB change to 12 MB(20k plus wallet and split one to send / receive BTC node) , and very fast to send BTC now :)

but I miss some txid between old and new node (old can be find) , but it’s okay , just report my env and many thanx dev team : )

Jsying commented at 5:37 pm on June 3, 2016: none

Flushing wallet take a long time when the wallet is large. It seems like BerkeIeyDB lsn_reset function will rewrite the whole wallet.dat. I wonder why we need to call dbenv->lsn_reset(strFile.c_str(), 0); in ThreadFlushWalletDB. Is there any concern? Why not call lsn_reset when shutting down bitcoind or reduce the frenquency.

pstratem commented at 5:48 pm on June 3, 2016: contributor

@Jsying I’m working on significantly improving the wallet performance, but it’s going to take some time.

GSPP commented at 7:20 pm on June 3, 2016: none

Rewriting the entire wallet certainly is not crash consistent. I really doubt a database engine would do such a thing.

You can use procmon on Windows to see what exactly is being written.

sipa commented at 7:21 pm on June 3, 2016: member

I think @pstratem is working on this.

Jsying commented at 10:06 am on June 5, 2016: none

@GSPP I have used strace to see the write_bytes before and after flushing db (lsn_reset) and It’s seems like it really rewrite the whole wallet.dat According to BDB docs:

Because database pages contain references to the database environment log records (LSNs), databases cannot be copied or moved from one transactional database environment to another without first clearing the LSNs. Note that this is not a concern for non-transactional database environments and applications, and can be ignored if the database is not being used transactionally.

and the comment // Flush wallet file so it's self contained https://github.com/bitcoin/bitcoin/blob/master/src/wallet/walletdb.cpp#L893

I guess lsn_reset will rewrite the whole wallet.dat so that it can be moved to other environment. But I curious why so frequently… @pstratem @sipa Thanks. I am not going to duplicate your works. I just observe the phenomenon and very curious about the reason…

gmaxwell commented at 1:51 am on July 14, 2016: contributor

@pstratem Can you confirm you thing you fixed this?

pstratem commented at 3:51 am on July 14, 2016: contributor

@gmaxwell I’ve been working my way towards improving wallet performance in general.

Unfortunately to do so safely requires a number of re-factors on the way the wallet accesses the database.

These have been merged: #8137 https://github.com/bitcoin/bitcoin/pull/8142

Waiting for this one before doing the final pass: #8152

denravonska commented at 1:26 pm on March 9, 2018: none

Is there a reason why lsn_reset was called inside CDBEnv::CheckpointLSN? It increases the risk window in case of a crash and calling it while flushing manually (IE not via the old flush thread) when exiting should be enough, no?

BrannonKing commented at 5:12 pm on December 26, 2019: none

@pstratem , #8152 has been merged. Can this be closed?

willcl-ark commented at 11:28 am on November 23, 2022: contributor

I wonder if this is another issue which should be closed as the BDB wallet is unlikely to see this periodic flushing performance issue patched now that we have sqlite wallets as default wallet type moving forward?

maflcko commented at 11:34 am on November 23, 2022: member

Closing per previous comment and #18904 (comment)

maflcko closed this on Nov 23, 2022

bitcoin locked this on Nov 23, 2023

send BTC is very slow with huge wallet #7475