<p>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.</p>
<p>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).</p>

CC BY-SA 4.0
2023-08-25T00:51:59.510Z
2023-08-25T00:51:59.510Z
Ava Chow
<p>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.</p>
<p>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 <em><strong>getpeersinfo</strong></em> and later I tried to add them through <em><strong>addnode</strong></em>, but I didn't get such an effect.
How can you explain this behavior?</p>
<p>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.</p>

CC BY-SA 4.0
2023-08-24T22:46:45.270Z
With dbcache=16000, it should go fairly quickly until the very end. Is it still slow even with that set?
Ava Chow
CC BY-SA 4.0
2023-08-24T23:33:07.750Z
@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. :/
javierMarquez
<bitcoin-core><synchronization><full-node><peers>
Why is my sync slow even with a dbcache of 16000?
javierMarquez
# Why is my sync slow even with a dbcache of 16000?

(Asked by: username_0 on 2023-08-24)

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.

**Tags:** bitcoin-core, synchronization, full-node, peers

> **Comments:**
> **username_1**: With dbcache=16000, it should go fairly quickly until the very end. Is it still slow even with that set?  
> **username_0**: @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. :/  

---

## 1 answers

### Answer by username_1 on 2023-08-25. Score: 8 | Accepted answer

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).


---

