Note: I don't know exactly how long it took because I didn't do it in one go. I guess it was like 4,5 days doing it only at night. At some points(2015Q3, 2018Q2) it slows down and ETA goes up to 16 weeks or something.
The main bottleneck is IO. My 2013 mobile i3 has enough processing power to sync, I only used 3 threads and most of the time only one was close to 100%. The two directories that need to be written and read from intensively are chainstate and blocks/index. I pruned to 2GB and chainstate didn't go much over 3GB during the entire process. blocks/index is like 100MB.
The best solution is to move chainstate and blocks/index to a ramdisk. If you don't have enough ram the linux kernel has a thing called zram. Zram creates a compressed swap(cache) file in ram, this effectively increases your ram size at the cost of a bit of processing power and access speed(of the compressed part). On my machine I can net a bit more than 1GB of extra ram. That's right, with linux you can download more ram! The second best solution is to leave chainstate and block/index on a sdd. From what I've tested it should take up between 5 whole days and 2 weeks.
With regards to config, I didn't see much benefit in increasing the db cache over the default 450MB in bitcoin-qt. If I recall correctly, smaller prune sizes make chainstate larger.
After the initial sync keeping up to date is very easy on resources. You can catch up a week in a few minutes. At the moment bitcoind is using 400MB but I'm still working on bringing that number down.
Remember: If you want safety or if you want to help the network you need o run a full node. A full node is a node that verifies all transactions. A pruned node is a full node.
[link] [comments]
No comments:
Post a Comment