GitHub suggested discussing here before bothering developers with an issue.
So be it! 🙂
I’m running Bitcoin Core Version v0.20.1 and Linux Mint 18.3 on crappy old hardware. Pruning blockchain to 2 G and setting
dbcache=2048 didn’t help much. Moving
datadir from HDD onto a USB-Stick did a little.
top says CPU around 20% can reach up to 40 if I manually drop slow or unresponsive nodes.
CPU frequency is rarely going up. So, no issue here.
Memory usage is fine too, actually a lot of headroom. Looks like bitcoin-qt doesn’t need that much cache.
Swap is empty. (
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sdc 0,00 0,00 549,00 0,00 51125,00 0,00 186,25 1,06 1,92 1,92 0,00 1,70 93,60
Bottleneck seems to be file I/O. Which confuses me since that is what a cache is meant to fix, isn’t it?
Now to my questions:
Is there anything I am missing to improve disk access?
Is there an open issue on GitHub regarding this already?
And secondly for the experts on dropping lazy nodes. Can you give me a hint at which classes I have to look to understand the strategy? Or even better a link to the discussions on that topic.
For I don’t want to start an arms race between clients seeking faster download and nodes trying to serve fair.
Short summary what I’ve learned so far.
- Don’t use USB-Sticks for
datadir. For bitcoin-qt might shutdown due to Fatal LevelDB errors.
- Pruning increases disk I/O while saving disk space.
- Even on crappy old hardware memory and CPU are most probably not the limiting factor.