< JoeLiu>
Is there any book for Bitcoin developping?
< Luke-Jr>
JoeLiu: bitcoin.org has some useful documentation
< dcousens>
gmaxwell: you around?
< dcousens>
Just had my node drop, was curious why
< dcousens>
bitcoind
< dcousens>
Killed
< dcousens>
Nothing more on the console
< dcousens>
last few messages on the debug.log are 2015-10-16 18:14:46 socket sending timeout: 37784s
< phantomcircuit>
dcousens, run dmesg
< phantomcircuit>
im guessing out of memory
< dcousens>
ta, ya OOM.
< dcousens>
Though shouldn't have bitcoind thrown an error std::bad_alloc etc?
< dcousens>
is there any way I can stop this from happening?
< dcousens>
I had a higher minrelaytxfee
< phantomcircuit>
dcousens, how much memory do you have?
< dcousens>
phantomcircuit: on this node? 2GB
< phantomcircuit>
drop the maxconnections limit is probably what you have to do
< phantomcircuit>
unfortunately
< dcousens>
would just setting an even higher relay fee work maybe?
< dcousens>
also, whats the easiest way to track this data over time?
< dcousens>
(like, say, process v mempool MB size)
< phantomcircuit>
dcousens, you can call getmempoolinfo and dump that to a file somewhere
< Luke-Jr>
2 GB is plenty. Probably your relay policy is too broad and is storing spam.
< dcousens>
Luke-Jr: default policy, so probably
< dcousens>
0.12 couldn't come sooner :)
< Luke-Jr>
software versions are not for policies.
< Luke-Jr>
you're supposed to configure that yourself
< dcousens>
Luke-Jr: if I were to configure this node for what it is being paid to do, it'd be a leech solely
< dcousens>
I don't have time to allocate to configuring policy, so, the defaults matter
< dcousens>
Maybe if policy was as simple as dropping in some pre-written CPP files that there were a library of somewhere
< dcousens>
But, I'm not aware (nor is it advertised) of that
< dcousens>
(by leech solely, I mean, it'd only download blocks, no relay whatsoever)
< Luke-Jr>
then you get to deal with the unlimited resource consumption. we don't have time to help you.
< Luke-Jr>
deciding and configuring policy is part of the job of running a node, *especially* if you're being paid to do it..
< dcousens>
Luke-Jr: lol, conceptually I agree with you, but pragmatically things tend to be different
< Luke-Jr>
instead you get paid to do it, and then go insist others do your job on their unpaid (at least by you) time..
< dcousens>
Luke-Jr: I wasn't insisting anything?
< Luke-Jr>
[09:20:08] <dcousens> 0.12 couldn't come sooner ☺ [09:24:34] <dcousens> I don't have time to allocate to configuring policy, so, the defaults matter
< Luke-Jr>
sure sounds like it
< dcousens>
I understand the implications of OSS, its all I do all day
< Luke-Jr>
pragmatically, you're the one left without a working node, and having to explain to whoever is paying you why you're not doing the job
< dcousens>
Doesn't mean I can't express interest in some of the changes that will be deployed as defaults in 0.12
< Luke-Jr>
dcousens: we adopted a "don't change default policy" principle a bit ago. maybe we should have stuck to it stronger..
< * Luke-Jr>
goes to bed.
< dcousens>
Luke-Jr: night, sorry you took my comments the wrong way. phantomcircuit thanks for the help
< gmaxwell>
Luke-Jr: So I'd rather remove smart times completely than have rescans take 9.5 hours longer in that case. :P so you should help him figure out how to get the behavior right.
< gmaxwell>
we never would have merged smart times knowing that it added hours to the rescan of a 200k key wallet.
< Luke-Jr>
:/
< Luke-Jr>
this is the first complaint of that nature, whereas we used to have regular complaints about tranasction times before smart-times got released..
< gmaxwell>
Luke-Jr: we have had regular complaints about rescan taking forever for a long time.
< Luke-Jr>
O.o
< gmaxwell>
Just didn't know smarttimes were part of it until now.
< gmaxwell>
heck, even I've complained about it. :)
< Luke-Jr>
it's rare enough I assumed he meant reindex
< gmaxwell>
Luke-Jr: no, rescale! as in zapwallettx (which he mentioned specifically)
< gmaxwell>
er rescan.
< Luke-Jr>
I mean, rescan and zapwallettx are not daily tasks
< Luke-Jr>
reindex is getting to be :/
< gmaxwell>
Luke-Jr: people are zaping frequently because of the malleation attacks.
< gmaxwell>
still, this also means reindex would be slow, as we run the same code there.
< Luke-Jr>
if it's really 9.5 hours longer, then any significant optimisation is likely to require changing the database non-trivially, which is dangerous. I consider slow better than dangerous, since we plan to go away from bdb someday anyway. So if bad times in day-to-day use is preferable to slow rescan, reverting it may be our best option. :|
< Luke-Jr>
I'll take a look and see if I'm wrong about the risk, but that's what 9.5 hours suggests to me.
< Luke-Jr>
ok, we can probably get a lot of improvement by caching the ordered tx list rather than sorting it every add
< Luke-Jr>
>_<
< Luke-Jr>
any simple way to benchmark?
< Luke-Jr>
gmaxwell: this would be easier if I could remove accounting first; thoughts?
< Luke-Jr>
wumpus: ^
< gmaxwell>
Luke-Jr: why do you need the sorted list?
< gmaxwell>
Luke-Jr: can you not cache a min or max?