From: Olivier Langlois <olivier@trillion01•com>
To: Jeff Garzik <jgarzik@bitpay•com>
Cc: "bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] bitcoind stops responding
Date: Thu, 03 Oct 2013 23:52:18 -0400 [thread overview]
Message-ID: <1380858738.932.71.camel@Wailaba2> (raw)
In-Reply-To: <1380684053.932.43.camel@Wailaba2>
> 1380610633.387730: POST / HTTP/1.1^M
> ThreadRPCServer method=getinfo
> CTxMemPool::accept() : accepted dc2941dd69b2f9fa2754f741dfba76489abef706bd237e3bd715181950723e4d (poolsz 1283)
> keypool reserve 15
> keypool return 15
> locktime : 5.996820 calltime : 0.000328 totaltime : 5.997148
>
I have found another circumstance where getinfo rpc function can take
more than 2 secs to return. Here are the circunstances:
received block 0000000000000013c889fbe1b2a23eb4b6bd38a8051420be1bf319da184f02ae
Committing 1015 changed transactions to coin database...
SetBestChain: new best=0000000000000013c889fbe1b2a23eb4b6bd38a8051420be1bf319da184f02ae height=261213 log2_work=72.38679 tx=24743665 date=2013-10-02 05:26:49 progress=0.999999
{"method":"getinfo","params":[],"id":783}
ThreadRPCServer method=getinfo
keypool reserve 15
keypool return 15
locktime : 0.000001 calltime : 2.453037 totaltime : 2.453038
This time locking the contention isn't from cs_main, cs_wallet mutex
lock. I think that what happen here is
1. CWallet::SetBestChain is called
2. This trigger ThreadFlushWalletDB that will lock wallet db and flush
it
3. getinfo will have to wait that ThreadFlushWalletDB ends to complete
GetOldestKeyPoolTime().
Just throwing a couple of ideas here. Comments are welcome:
1.
Is closing the db and reopen it the only way to flush the db to disk?
Can it be done asynchonously? I don't know BDB much but probably closing
the DB involves some blocking fsync() call and given that this follow
1015 records writing into the txdb, it takes more time than it should
otherwise to return.
2.
I'm relatively new to bitcoin. I understand that in a recent past
everything was using BDB. Now that only the wallet seems to keep using
it, maybe some options could be removed to make BDB more lightweight.
DB_THREAD:
From what I see, BDB API access is already well synchronized by
bitcoind. There is no obvious reason to ask BDB API to be thread safe.
DB_INIT_TXN:
Correct me if I'm wrong, but I suspect this subsystem initialization to
be a vestige of when txdb was in BDB.
3.
not sure at all about this one but I'm throwing the idea anyway.
Personnally, I have no used for 'keypoololdest'. I might experiment
without it
How about having an optional bool param to 'getinfo' that could have the
name 'lowlatency' or 'nodb' to skip info gathering having the potential
to make the call longer?
prev parent reply other threads:[~2013-10-04 5:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-30 20:44 slush
2013-09-30 21:01 ` Warren Togami Jr.
2013-09-30 22:00 ` Fatima Castiglione Maldonado 发
2013-09-30 22:08 ` Gregory Maxwell
2013-10-01 0:05 ` Fatima Castiglione Maldonado 发
2013-10-01 1:26 ` Jeff Garzik
2013-10-01 0:20 ` Chris Double
2013-10-01 1:17 ` Jeff Garzik
2013-10-01 8:58 ` slush
2013-10-04 6:22 ` Gavin Andresen
2013-10-04 15:05 ` Jeff Garzik
2013-10-01 4:03 ` Olivier Langlois
2013-10-01 7:10 ` Olivier Langlois
2013-10-01 14:17 ` Jeff Garzik
2013-10-02 3:20 ` Olivier Langlois
2013-10-04 3:52 ` Olivier Langlois [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1380858738.932.71.camel@Wailaba2 \
--to=olivier@trillion01$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jgarzik@bitpay$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox