Related eBooks

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. (vm.swappiness=5)


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.


By pplny

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

Translate »