1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
|
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 <olivier@trillion01.com>) 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 <olivier@trillion01.com>)
id 1VRwR9-0002Go-GY; Thu, 03 Oct 2013 21:52:19 -0600
Message-ID: <1380858738.932.71.camel@Wailaba2>
From: Olivier Langlois <olivier@trillion01.com>
To: Jeff Garzik <jgarzik@bitpay.com>
Date: Thu, 03 Oct 2013 23:52:18 -0400
In-Reply-To: <1380684053.932.43.camel@Wailaba2>
References: <CAJna-Hi+eyRnZUtHpfvod_uRCmjPOL5HS3ZZpr54yzbKRRT9-w@mail.gmail.com>
<1380600219.932.21.camel@Wailaba2> <1380611418.932.31.camel@Wailaba2>
<CAJHLa0PucKk_OBQarRgVBRPyC+RbvT9GC1iYqAaBjyT2qyRFdw@mail.gmail.com>
<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"
<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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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?
|
