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

💬 ismaelsadeeq commented on issue "test: `feature_fee_estimation` failure after duplicate coinbase tx weight reservation fix [AssertionError: Estimated fee (0.00923427) out of range]":
(https://github.com/bitcoin/bitcoin/issues/32461#issuecomment-2925282272)
> Also, it's quite strange that the test started failing on this commit: [https://github.com/bitcoin/bitcoin/commit/6b165f5906fc53bd10bedff85a6ef26e0aabdc5c](https://github.com/bitcoin/bitcoin/commit/6b165f5906fc53bd10bedff85a6ef26e0aabdc5c)
> I haven't looked into that yet.

I’ve debugged the issue and discovered why this seed only fails on commit 6b165f5906fc53bd10bedff85a6ef26e0aabdc5c

This is because, prior to that commit, we reserved only 8000 WU only when using the default `-blockmaxweigh
...

💬 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-2925284510)
Increasing `options.block_cache` and `options.write_buffer_size` didn't (really) help. Back to removing the LevelDB max file size increase.

💬 pinheadmz commented on pull request "[28.x] Backport #31407":
(https://github.com/bitcoin/bitcoin/pull/32563#issuecomment-2925310556)
Should I try to build and sign again? Recent just looks like a repository change.