1. 
   kosuodhmwa commented at 7:00 pm on February 16, 2026: none

   Is there an existing issue for this?

   • I have searched the existing issues

   Current behaviour

   bitcoind sync gets very, very slow on Augst 2023 in BTC chain (maybe 2/3 progressed or something like that)

   Earlier (e.g. first sync in 2024), it was faster, but i also used another version there. the version i use now, is v30.99.0-0ffb20dee178 (self-compiled from master branch)

   AND: i also changed my HW: From SSD SATA on LSI SATA-3 controller to a Seagate video SATA-33 HDD on UBS 2.0 controller (because it can bypass the to VM on VirtualBox 7.2.x on MS Window$ (maybe on Linux, i would be able to bypass PCI SATA devices or VHD files in a raw mode - but on Windows, PCIE SATA bypass is not supported and VHD file raw mode is not cleanly implemented. So i need to use USB drives to bypass it completely/in a raw mode)

   (But i don’t think that is the problem TBH)

   Currently, it needs ~1 day for 1 day in block chain: On 2026-02-06, on blockchain it was on 2023-08-05 and now we have 2026-02-16 and blockchain sync is on 2023-08-19. Which means, it will result in an infinite process

   Expected behaviour

   Should be synced in maybe 2-3 weeks maximum so i think, similar to the last sync (2024 when i remember right? But it was another version, don’t know that’s the reason or not?).

   Steps to reproduce

   bitcoind sync gets very, very slow on Augst 2023 in BTC chain (maybe 2/3 progressed or something like that)

   Earlier (e.g. first sync in 2024), it was faster, but i also used another version there. the version i use now, is v30.99.0-0ffb20dee178

   AND: i also changed my HW: From SSD SATA on LSI SATA-3 controller to a Seagate video SATA-33 HDD on UBS 2.0 controller (because it can bypass the to VM on VirtualBox 7.2.x on MS Window$ (maybe on Linux, i would be able to baypass PCI SATA devices or VHD files in a raw mode - but on Windows, PCIE SATA bypass is not supported and bypass file raw mode is not cleanly implemented. So i need to use USB drives to bypass it completely/in a raw mode)

   (But i don’t think that is the problem TBH)

   Currently, it needs ~1 day for 1 day in block chain: On 2026-02-06, on blockchain it was on 2023-08-05 and now we have 2026-02-16 and blockchain sync is on 2023-08-19. Which means, it will result in an infinite process

   Relevant log output

   How did you obtain Bitcoin Core

   Compiled from source

   What version of Bitcoin Core are you using?

   v30.99.0-0ffb20dee178

   Operating system and version

   Debian 12.x x64, most current version, with most current updates

   Machine specifications

   PRIMERGY TX120 S3 Server with 4-core (8 virt. Cores) Xeon, 32GB of RAM

2. 
   kosuodhmwa commented at 7:01 pm on February 16, 2026: none

   PS: I was not able to attach zipped debug log here. Got an error message…

   HERE, because of that issue: https://limewire.com/d/5xAA1#NmroMAVYvc

3. 
   sipa commented at 7:08 pm on February 16, 2026: member

   What is your dbcache setting set to?
4. 
   sipa commented at 7:13 pm on February 16, 2026: member

   Based on your debug.log, it looks like you have the default dbcache setting, 450 MiB. With that much RAM, I recommend setting it to dbcache=10000 or so, to cache most of the chainstate in memory.
5. 
   l0rinc commented at 7:17 pm on February 16, 2026: contributor

   to cache most of the chainstate in memory

   Yeah, especially for a HDD through a USB 2.

   the version i use now, is v30.99.0-0ffb20dee178

   That’s very recent, basically a month old: https://github.com/bitcoin/bitcoin/commit/0ffb20dee17858e0f13b23fce3dd0ec06cbeb9a2

6. 
   kosuodhmwa commented at 7:50 pm on February 16, 2026: none

   Thank you very much for your fast feedback! :-)

   bitcoin.conf’s content:

   ´´´ root@debian12-btc-node:~/.bitcoin# cat bitcoin.conf

   — Core —

   server=1 txindex=1 disablewallet=1

   — Netzwerk —

   listen=1 bind=127.0.0.1 #bind=192.168.1.174 rpcbind=127.0.0.1 #rpcbind=192.168.1.174

   — RPC / REST (für lnd) —

   rpcuser=….. rpcpassword=….. rpcallowip=127.0.0.1 #rpcallowip=192.168.1.174 #rpcallowip=192.168.1.0/24 rest=1

   — Whitelisting —

   whitelist=127.0.0.1 #whitelist=192.168.1.174 #whitelist=192.168.1.0/24

   — Tor —

   proxy=127.0.0.1:9050 listenonion=1 onlynet=onion

   — Pfade —

   datadir=/root/.bitcoin ´´´

   “That very recent, basically a month old: https://github.com/bitcoin/bitcoin/commit/0ffb20dee17858e0f13b23fce3dd0ec06cbeb9a2"

   Yes, i also had the same problem before with a version that was a few monts old. Because of that, i used the latest master branch when i tried to solve the problem a few weeks ago.

7. 
   kosuodhmwa commented at 7:51 pm on February 16, 2026: none

   OK, so i will cancel the process now, the add “dbcache=10000”, then start it again… :-)
8. 
   kosuodhmwa commented at 7:54 pm on February 16, 2026: none

   so bitcoind.conf is now like that:

   ´´´

   — Core —

   server=1 txindex=1 disablewallet=1 dbcache=10000

   — Netzwerk —

   … … … ´´´

9. maflcko added the label Resource usage on Feb 17, 2026
10. maflcko added the label Questions and Help on Feb 17, 2026
11. 
    l0rinc commented at 8:26 am on February 17, 2026: contributor

    Did it improve? Expect that when the in-memory data gets dumped again (after the 10 GB dbcache gets filled), the process will “freeze” for a long time - should still be a lot faster than dumping every time the 450 MB dbcache gets full.
12. 
    kosuodhmwa commented at 1:41 pm on February 17, 2026: none

    Hmmm… still slow so it seems, now i’m on 2023-08-21 in block chain sync… yesterday, so before that setting change, it was on 2023-08-19 :-(
13. 
    kosuodhmwa commented at 1:43 pm on February 17, 2026: none

    Maybe a lil bit faster - without setting change, i would maybe still on 2023-08-19 or on 2023-08-20… instead of 21th
14. 
    willcl-ark commented at 1:52 pm on February 17, 2026: member

    I think here you have essentially stacked every possible (random IO) performance-related bottleneck that I know of :(

    • spinning HDD (probably totally dominated by random reads/writes to the LevelDB)
    • USB 2.0 (extra latency per IO operation, very slow random IO)
    • VirtualBox (another layer of IO overhead)
    • tor (possibly contributing, possibly not)
    • txindex=1 even more random IO via the above for another DB
    • (previously) dbcache=450 - increasing random IO needed even further

    I think you may have addressed the final point in increasing that value, but I think with the rest iof the stack remaining, you are still not going to have a good time.

    I don’t think this is anything that can be solved on our side, and it needs hardware/configuration to be changed. The other low-hanging fruit could be to disable txindex and see if that speeds it up (and re-enable after you are synced). But I suspect without addressing other bottlenecks you might still not have a great time.

15. 
    l0rinc commented at 2:15 pm on February 17, 2026: contributor

    you have essentially stacked every possible (random IO) performance-related bottleneck that I know of

    Except for swapping (probably) :D

    It might even be faster for you to restart IBD and do everything in-memory with a high dbcache

16. 
    maflcko commented at 2:45 pm on February 17, 2026: member

    I think increasing dbcache will not affect IO write requirements? After #30611, a write will happen every hour, which seems more frequent than write due to a full dbcache? Also, restarting to increase dbcache will clear the dbache, so everything will need to be read again into memory from HDD, which is slow.

    since you already have an SSD, and have used it in the past, my recommendation would be to figure out how to use the SSD.

17. 
    darosior commented at 3:44 pm on February 18, 2026: member

    since you already have an SSD, and have used it in the past, my recommendation would be to figure out how to use the SSD.

    Maybe one pointer here. If you have a large-enough SSD to contain the chainstate (the UTxO database) but not the full block chain, consider pointing the -datadir to your SSD and the -blocksdir to the HDD.

18. 
    kosuodhmwa commented at 6:40 pm on February 19, 2026: none

    OK, thx, firstly, my ideas was to use it for another device, but when formated it with “low level format tool” (on a usb 3 adapter on laptop), i saw that it only reaches ~40mb/s (adapter and/or laptop should not be the problem here). Usually, SSDs reach 300mb/s or something like that on that usb 3.0 adapter… so the SSD seems to be “used”.

    So i will buy a new one ASAP. BTW: What is future-proof , maybe for the next ~5y? What do you think? 3TB is OK or better 4? (maybe difficult to say haha). And a “small card size” USB 3.0 adapter too.*

    *Maybe another detail, but it’s not relevant i.m.o.: The adapter on the server where VirtualBox BTC node VM is has ONLY usb 2.0 ports, but the adapter i used is USB 3.0. (USB 2.0 speed in both cases..)

19. 
    kosuodhmwa commented at 6:41 pm on February 25, 2026: none

    Now i bought a USB 3.0 PCIE controller (so no bottleneck anymore with USB 3.0/SATA-III adapter), will see it increases the speed of the current Seagate Video HDD… if not, i will look for a new SSD, maybe bigger than 2TB (so future-proof for BTC chain size, ;-))
20. 
    maflcko commented at 12:07 pm on March 2, 2026: member

    I guess the questions have been answered, and this can be closed for now?
21. willcl-ark closed this on Mar 2, 2026

    ---

22. 
    kosuodhmwa commented at 5:45 pm on March 2, 2026: none

    I’m still waiting for my USB 3.0 pcie controller card HAHAHA
23. 
    kosuodhmwa commented at 6:19 am on March 5, 2026: none

    Yes, now it seems to be faster, now it processes ~1.x month of BTC blockchain in ~1 day… :-)

    PS: 32GB RAM was total in physical - for the bitcoind Debian VM there is 8192 MB virtual memory reserved. So i changed the config value from “10000” to “3072”.

Contributors
kosuodhmwa sipa l0rinc willcl-ark maflcko darosior

Labels
Resource usage Questions and Help