💬 romanz commented on pull request "rest: fetch spent transaction outputs by blockhash":
(https://github.com/bitcoin/bitcoin/pull/32540#discussion_r2117417395)
Will prepare a benchmark to compare both formats :)

💬 fanquake commented on pull request "cmake: Replace deprecated `qt6_add_translation` with `qt6_add_lrelease`":
(https://github.com/bitcoin/bitcoin/pull/32651#discussion_r2117446696)
Delete it from here now?

⚠️ hMsats reopened an issue: "bitcoind 29.0 much slower than 28.0 on my system: cause found"
(https://github.com/bitcoin/bitcoin/issues/32455)
I always compile the bitcoin software myself (`Ubuntu 24.04.2 LTS`). For `bitcoin-29.0` I compiled it (of course) for the first time with `cmake` (with and without `berkeley-db`).

For both (with and without `berkeley-db`), `bitcoind-29.0` is much slower than `bitcoin-28.0` which gives me problems on my server.

To investigate I wrote a shell script that determines the time difference in seconds between "Saw new header" and "UpdateTip":

```
2025-05-09T05:24:11Z Saw new header hash=000000000000
...

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2924559680)
I was too forgiving in my search for the problematic commit and did the search again holding on to my original low cpu system settings. A (very) long story short, the problematic commit for my system is [097c66f](https://github.com/bitcoin/bitcoin/commit/097c66f61487a2cfb4998bf7c53e4b1d048cf612), where the LevelDB max file size is increase to 32 MiB.

I tested that my system ran perfectly again on (almost) master (v29.99.0-14c16e81598a) removing the code changes by this commit (so removing: `opt
...

💬 hebasto commented on pull request "cmake: Replace deprecated `qt6_add_translation` with `qt6_add_lrelease`":
(https://github.com/bitcoin/bitcoin/pull/32651#discussion_r2117473948)
Sure! The comment has been deleted.

💬 TheCharlatan commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2924584571)
Does your server use a SSD, or a spinning disk?

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2924665003)
@TheCharlatan a 2 TB SSD, see "System info"

💬 fjahr commented on pull request "thread-safety: fix annotations with REVERSE_LOCK":
(https://github.com/bitcoin/bitcoin/pull/32465#issuecomment-2924853250)
utACK 96a341d4064132292621af404de908f01fbe3e2f

💬 sipa commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925098509)
What filesystem are you using?

💬 andrewtoth commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925105024)
Not necessarily related to validation, but I would remove the `rpcthreads` and `rpcworkqueue` lines from your config. Fulcrum and clightning will make a lot of concurrent requests, and the default threads were increased in v29 from 4 to 16. That should help with errors, especially with Fulcrum.

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925124875)
@sipa @andrewtoth

Maybe the solution is as trivial as increasing:

```
options.block_cache = leveldb::NewLRUCache(nCacheSize / 2);
options.write_buffer_size = nCacheSize / 4; // up to two write buffers may be held in memory simultaneously
```

in `src/dbwrapper.cpp`?

I have naively set (after putting back the LevelDB max file size increase to 32 MiB):

```
options.block_cache = leveldb::NewLRUCache(nCacheSize / 2 *16);
options.write_buffer_size = nCacheSize / 4 *16; // up to two write buffers
...

💬 sipa commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925132859)
@hMsats That's worth looking into or benchmarking, but I would be surprised if that has such a dramatic effect.

What filesystem are you using?

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925136624)
@sipa

`/dev/sdb1 ext4 1.8T 935G 805G 54% /media/ssd`

it contains .bitcoin and the CLN and Fulcrum data

💬 andrewtoth commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925137848)
> Fulcrum would retry every 5 seconds which would fill up my rpcworkqueue quickly

v29 also increased `rpcworkqueue` to 64 by default, so that line is redundant. By keeping `rpcthreads` at 4 you are limiting the number of concurrent requests to 4, while default can now service 16 at a time. That would also help keep the work queue lower since requests in the queue can be processed faster.

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925138046)
The following are the `Verifying last 3 blocks at level 3` times on the last 3 runs, and my new run

```
debug.log_Fri_May_30_05:58:19_AM_CEST_2025:2025-05-29T11:26:33Z Verification progress: 0%
debug.log_Fri_May_30_05:58:19_AM_CEST_2025-2025-05-29T11:26:38Z Verification progress: 33%
debug.log_Fri_May_30_05:58:19_AM_CEST_2025-2025-05-29T11:26:53Z Verification progress: 66%
debug.log_Fri_May_30_05:58:19_AM_CEST_2025-2025-05-29T11:26:58Z Verification progress: 99%
25 s
--
debug.log_Fri_May_30_09:
...

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925140605)
@andrewtoth but `nproc` command gives the answer 4. Is it still worth will to set `rpcthreads` to 16?

💬 andrewtoth commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925144203)
Yes, since the requests are io bound they will mostly be waiting concurrently and not using much CPU.

💬 sean-k1 commented on pull request "rpc: Support v3 raw transactions creation":
(https://github.com/bitcoin/bitcoin/pull/31936#issuecomment-2925148327)
@achow101 @maflcko
we fixed the lint error.
There seems to be a lot of discussion, let me know when it's clear.

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925149364)
OK, thanks a lot. I will remove it sooner or later!

💬 sipa commented on pull request "Replace cluster linearization algorithm with SFL":
(https://github.com/bitcoin/bitcoin/pull/32545#issuecomment-2925180422)
@instagibbs @ismaelsadeeq @gmaxwell FWIW, I didn't include apples-to-apples comparison because the large-scale comparison [benchmarks](https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303/73) I did (especially, [this one](https://delvingbitcoin.org/uploads/default/original/2X/2/22ad16f71db37fcb8cadb8a8f73c4acfd3def203.png)) were just overwhelmingly in favor of SFL over the existing one. The benchmarks were mostly done to decide between SFL and another replacement algorithm, GGT, but se
...