Why is the initial sync so painfully slow? Have I misconfigured something?

[General-McSnuffles]

Bitcoin Core took about twenty-four hours to fully sync.

I figured Fulcrum would sync in maybe half that time, since it's just indexing off of a local connection, but man, it's on the day three, and still at 98%, with processing slowed down to only 53 blocks/minute. I'm wondering what's causing the slowdown.

• It's not a network problem. Fulcrum and Bitcoin Core communicate via localhost.
• It's not a CPU problem. top shows that the Fulcrum process rarely gets over 15%.
• It's not an IO bottleneck. Everything is being written to an external USB SSD. Max write speed of the drive is 250 MB/s, but Fulcrum only rarely exceeds 4 MB/sec. Typically it's at around 1 MB/sec, often less.
• It's not a memory issue. Server has 32 GB of RAM, with 24 GB remaining available for use. Fulcrum is only using about 3 GB.

I'm running on Debian 12 via a Dell PowerEdge server.

My fulcrum.conf file is as follows based on recommendations in the documenation:

# Data will be stored here.
datadir = /mnt/bitcoin-data/fulcrum

# bitcoind RPC
bitcoind = 127.0.0.1:8332
rpccookie = /mnt/bitcoin-data/bitcoin-core/.cookie

# listen for connections (non-SSL)
tcp = 0.0.0.0:50001
admin = 127.0.0.1:8000

# peer discovery
peering = false
announce = false
hostname = lnd.dla.local

# initial sync: expressed in MB; improves performance of initial sync
utxo_cache = 1000

# database RAM cache
db_mem = 1000

Also, my bitcoin.conf file contains the following line, as recommended in the documentation:

# ZeroMQ options required for Fulcrum (electrum server)
zmqpubhashblock=tcp://127.0.0.1:8433

Any ideas on how to speed up this initial sync? Did I do something wrong in my conf file, perhaps?

[SoFTCureOrigin]

hi, running the full sync since yesterday so 514000 block in 24h ->saying 56,2%:

Sep 13 05:01:48 fulcrum[593004]: [2025-09-13 05:01:48.800] Storage UTXO Cache: Flushing to DB ...
Sep 13 05:22:46 fulcrum[593004]: [2025-09-13 05:22:46.933] Processed height: 513000, 56.1%, 47.2 blocks/min, 998.2 txs/sec, 6077.3 addrs/sec
Sep 13 05:54:57 fulcrum[593004]: [2025-09-13 05:54:57.641] Processed height: 514000, 56.2%, 31.1 blocks/min, 629.3 txs/sec, 3163.5 addrs/sec
Sep 13 05:58:19 fulcrum[593004]: [2025-09-13 05:58:19.858] Storage UTXO Cache: Flushing to DB ...

.conf
utxo_cache = 2000
db_max_open_files = 400
txhash_cache = 1000

[SoFTCureOrigin]

Need to restart from scratch...!!

Sep 13 15:46:03 mynode fulcrum[10521]: [2025-09-13 15:46:03.331] Fulcrum 1.12.0 (Release 7743cca) - Sat Sept 13, 2025 15:46:03.331 UTC - starting up ...
Sep 13 15:46:03 mynode fulcrum[10521]: [2025-09-13 15:46:03.331] Max open files: 1048576
Sep 13 15:46:03 mynode fulcrum[10521]: [2025-09-13 15:46:03.332] Loading database ...
Sep 13 15:46:03 mynode fulcrum[10521]: [2025-09-13 15:46:03.616] DB memory: 512.00 MiB
Sep 13 15:46:03 mynode fulcrum[10521]: [2025-09-13 15:46:03.616] Coin: BTC
Sep 13 15:46:03 mynode fulcrum[10521]: [2025-09-13 15:46:03.616] Chain: main
Sep 13 15:46:03 mynode fulcrum[10521]: [2025-09-13 15:46:03.616] FATAL: Caught exception: It appears that Fulcrum was forcefully killed in the middle of committing a block to the db. We cannot figure out where exactly in the update process Fulcrum was killed, so we cannot undo the inconsistent state caused by the unexpected shutdown. Sorry!
Sep 13 15:46:03 mynode fulcrum[10521]: The database has been corrupted. Please delete the datadir and resynch to bitcoind.
Sep 13 15:46:03 mynode fulcrum[10521]: [2025-09-13 15:46:03.616] Stopping Controller ...
Sep 13 15:46:03 mynode fulcrum[10521]: [2025-09-13 15:46:03.616] Closing storage ...
Sep 13 15:46:03 mynode fulcrum[10521]: [2025-09-13 15:46:03.660] Shutdown complete

[cculianu]

This is being fixed as I type this. I'm working on Fulcrum 2.0 which will be hopefully faster for you (but not but that much, we are at the limits of what rocksdb can do) -- but very importantly -- you should never see these corruption messages ever again and you can kill anytime. See: #287 .

[SoFTCureOrigin]

Hi Cculianu, we are all waiting for this....
When released i can do some beta test about this:
1/kill -9 (SIGKILL)
2/Power outage / kernel panic / hard reset

[cculianu]

@SoFTCureOrigin Beta test was just released by me. Get it here: https://github.com/cculianu/Fulcrum/releases/tag/v2.0.0-pre1

[gus4rs]

I am running v2.0.0 and experiencing an extreme slow initial sync. My config is :

datadir=/data/user/mainnet/fulcrum
tcp=0.0.0.0:50001
bitcoind=127.0.0.1:8332
rpcuser=bitcoin
rpcpassword=bitcoin
stats=127.0.0.1:51001
peering=false
announce=false

In about 8h, it synced up to 39.2%, last speed stat was 10.5 blocks/sec

[cculianu]

Sorry to hear that. You are on an SSD, yes? Also try bumping up db_mem in the config file. It defaults now to 2048 MB or 25% of physical RAM, whichever is smaller. If you have tons of RAM try db_mem=4096 or something larger.

Note that on BTC mainnet it can take days. It is what it is. History doesn't scale well.

[gus4rs]

It is what it is

Please refresh my memory, is the initial sync roughly the same speed as pre 2.0 versions?

[cculianu]

I believe it is, yes.

[nostitos]

I've got it running with 8000 db_mem, It's really hard to see why it's so slow, CPU 8% RAM at 5GB, NVME at 20mb/s, only thing that's high is IOPS ~50% with some spikes at 80%.

~1.5 days for Bitcoin's IBD and close to 4 days for Fulcum sync.

[mischalight]

this ist normal, but it is worth to wait now. Thank you very much cculiano for stopping the corruption-problem!

[cculianu]

My pleasure!

I'm glad it was a success and finally put the nail in the coffin for reasons not to run Fulcrum. Now there is every reason to run it.. hopefully, for more people out there.

Electrs still has the edge on minimal space requirement.. with the tradeoff that it can be much slower (understandably) for some types of queries. It sacrifices speed for space savings.. and that's a good tradeoff for some, not so good for others.

Electrs also does synch faster since it builds less of an index.. but then you pay for that later if you do lots of complex queries/have a big wallet.

It's always about tradeoffs, with these types of situations.