From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VRy6T-0006Bs-P3 for bitcoin-development@lists.sourceforge.net; Fri, 04 Oct 2013 05:39:05 +0000 Received-SPF: neutral (sog-mx-3.v43.ch3.sourceforge.com: 74.220.220.90 is neither permitted nor denied by domain of trillion01.com) client-ip=74.220.220.90; envelope-from=olivier@trillion01.com; helo=outbound-ss-1140.hostmonster.com; Received: from outbound-ss-1140.hostmonster.com ([74.220.220.90]) by sog-mx-3.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1VRy6S-0004Bx-Rv for bitcoin-development@lists.sourceforge.net; Fri, 04 Oct 2013 05:39:05 +0000 Received: (qmail 9664 invoked by uid 0); 4 Oct 2013 03:52:19 -0000 Received: from unknown (HELO box610.bluehost.com) (70.40.220.110) by qproxy1.mail.unifiedlayer.com with SMTP; 4 Oct 2013 03:52:19 -0000 Received: from [173.179.63.169] (port=49597 helo=[192.168.1.104]) by box610.bluehost.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1VRwR9-0002Go-GY; Thu, 03 Oct 2013 21:52:19 -0600 Message-ID: <1380858738.932.71.camel@Wailaba2> From: Olivier Langlois To: Jeff Garzik Date: Thu, 03 Oct 2013 23:52:18 -0400 In-Reply-To: <1380684053.932.43.camel@Wailaba2> References: <1380600219.932.21.camel@Wailaba2> <1380611418.932.31.camel@Wailaba2> <1380684053.932.43.camel@Wailaba2> Organization: Trillion01 Inc Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.8.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Identified-User: {5686:box610.bluehost.com:olivierl:trillion01.com} {sentby:smtp auth 173.179.63.169 authed with olivier@trillion01.com} X-Spam-Score: 0.7 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.7 SPF_NEUTRAL SPF: sender does not match SPF record (neutral) X-Headers-End: 1VRy6S-0004Bx-Rv Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] bitcoind stops responding X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 05:39:06 -0000 > 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?