[Bug]: Bitcoind is slow #4

New Issue

ssmithx · 2026-05-19T04:22:56Z

ssmithx commented

2026-05-19 04:22:56 +00:00

Description

IBD is taking forever

Steps to Reproduce

start bitcoin knots and analyze the IPD

Expected Behavior

Should be relatively fast

Actual Behavior

The logs confirm three overlapping problems.

No parallel validation (-par=0 not set)
The logs show txindex is catching up on block notifications repeatedly. The node is validating blocks sequentially on only one core instead of using all cores in parallel. On a slow dual-core laptop this is catastrophic.
cache=2016.5MiB - the database cache is only ~2 GiBiB. According to the deploy-bitcoin-knots.sh script, it should be set to -dbcache=4096 (4 GiB). The config isn't being applied correctly.
txindex is enabled. The deploy script uses txindex=1 instead of prune=550. This doubles the write workload during IBD as every index entry is stored.

Hardware limitations

This is a Lenovo ThinkPad X250 with an Intel Core i7-5600U (2-core / 4-thread laptop CPU). Combined with a SATA SSD (not NVMe), the I/O-bound single-threaded validation is the bottleneck.

Solutions (in order of impact)

Set -dbcache=4096 — doubles cache from 2GB to 4GB
Set prune=550 instead of txindex=1 — halves IBD write volume
Restart the node with the new settings — force IBD to complete with optimized params

Archipelago Version

1.7.67

Hardware

x86_64 (Intel/AMD)

Relevant Logs

No response

Screenshots

No response

### Description IBD is taking forever ### Steps to Reproduce start bitcoin knots and analyze the IPD ### Expected Behavior Should be relatively fast ### Actual Behavior The logs confirm three overlapping problems. 1. **No parallel validation (`-par=0` not set)** The logs show `txindex is catching up on block notifications` repeatedly. The node is validating blocks sequentially on **only one core** instead of using all cores in parallel. On a slow dual-core laptop this is catastrophic. 2. **`cache=2016.5MiB`** - the database cache is only **~2 GiBiB**. According to the `deploy-bitcoin-knots.sh` script, it should be set to `-dbcache=4096` (4 GiB). The config isn't being applied correctly. 3. **`txindex` is enabled.** The deploy script uses `txindex=1` instead of `prune=550`. This **doubles the write workload** during IBD as every index entry is stored. ### **Hardware limitations** This is a **Lenovo ThinkPad X250** with an Intel Core i7-5600U (2-core / 4-thread laptop CPU). Combined with a SATA SSD (not NVMe), the I/O-bound single-threaded validation is the bottleneck. ### **Solutions (in order of impact)** 1. **Set `-dbcache=4096`** — doubles cache from 2GB to 4GB 2. **Set `prune=550`** instead of `txindex=1` — halves IBD write volume 3. **Restart the node** with the new settings — force IBD to complete with optimized params ### Archipelago Version 1.7.67 ### Hardware x86_64 (Intel/AMD) ### Relevant Logs _No response_ ### Screenshots _No response_

lfg2025 commented

2026-06-11 06:09:57 +00:00

Believe this is fixes, need to confirm with testing

lfg2025 commented

2026-06-17 16:00:51 +00:00

Verified fixed in code: bitcoind/knots launch args now set -dbcache=4096 and -par=0 (use all cores) — core/archipelago/src/api/rpc/package/config.rs (~L692-693, documented L677-680). Parallel validation + larger UTXO cache address the slow-IBD root causes. Closing as implemented.

Verified fixed in code: bitcoind/knots launch args now set `-dbcache=4096` and `-par=0` (use all cores) — `core/archipelago/src/api/rpc/package/config.rs` (~L692-693, documented L677-680). Parallel validation + larger UTXO cache address the slow-IBD root causes. Closing as implemented.

lfg2025 closed this issue

2026-06-17 16:00:51 +00:00

lfg2025 referenced this issue from a commit

2026-06-23 08:36:45 +00:00

test(gate): poll immich lan_address to absorb mid-recreate churn

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: lfg2025/archy#4