5

We know that initial sync takes ages especially after 500-600k blocks. I get 500k in 30 hours, but now when I'm standing on 600k block syncing is quite slow, it took a couple of days to reach that number. The usual speed is about 15-30 blocks per minute, but sometimes something happens in heaven and speed up to 150-250 block per minute and it can go on for quite long time, (1-2 hours) but after that everything returns back to low speed.

I have the last Bitcoin Core, Win 10, 16Gb RAM, 4Tb HDD, Ryzen 6-core 3,6 GHz, my internet speed is constantly around 200 Mbps. I tried to use both: daemon and qt. With normal speed it takes 2-5% of CPU, 3-10Gb of RAM, 5-10Mb/sec of HDD. When increasing the speed, it takes 20-50% of CPU. I see how fast new blocks fly by and I can't explain what has changed?! They are the same size in blockchain, the same count of transactions. At these moments I tried to take getpeersinfo and later I tried to add them through addnode, but I didn't get such an effect. How can you explain this behavior?

I experimented with .conf file and now I work with this parameters: txindex=1, listen=1, dbcache=16000, banscore=10, maxreceivebuffer=100000, maxsendbuffer=20000, maxconnections=500, timeout=15000.

2
  • 1
    With dbcache=16000, it should go fairly quickly until the very end. Is it still slow even with that set?
    – Ava Chow
    Aug 24, 2023 at 22:46
  • @AndrewChow Yes. When I started syncing it was fast, the cache quickly grew to several GB, but unfortunately I had to stop syncing for a while after 500 KB. When I stopped it, the cache was about 10 GB. Now if I start again it will very slowly grow to 1-2 GB. Maybe that's the key - I shouldn't have stopped syncing. But here's what's interesting, the speed can now sometimes be very high even with a small cache size. :/ Aug 24, 2023 at 23:33

1 Answer 1

7

Although you've set a dbcache large enough to contain the entire UTXO set, at some point you've restarted. This means that the cache will begin empty and so UTXOs will need to be fetched from the database on disk. This loses the benefit of using the large dbcache since all of the existing UTXOs are no longer in memory. New UTXOs in incoming blocks will be held in memory, and that certainly helps with the syncing as the average age of an input is fairly low, but there will still be a significant number of transactions that require retrieving the UTXO from disk.

Compounding this is the fact that your are using a HDD rather than a SSD as they are slow to read and write data (compared to SSDs, which are slow compared to RAM).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.