Block catching speed downgrade on BSC v1.6.1-beta

[swift1911]

System information

Geth version: geth_linux version 1.6.1-91e0d265-20250922
OS & Version: Linux
Commit hash : v1.6.1-beta
Arguments:
- "--datadir=/bsc"
- "--config=/bsc/config.toml"
- "--rpc.allow-unprotected-txs"
- "--tries-verify-mode=none"
- "--db.engine=pebble"
- "--state.scheme=path"
- "--txpool.overflowpoolslots=100"
- "--history.transactions=0"
- "--history.blocks=90000"
- "--history.state=90000"
- "--discv5"
- "--cache=8192"
- "--metrics"
- "--metrics.addr=0.0.0.0"
- "--ws"
- "--ws.port=8546"
- "--ws.addr=0.0.0.0"
- "--miner.gasprice=50000000"

Description

• Steps to reproduce the behaviour
  ...
  Running a bsc nodes with bnb48 snapshot with 1.6.1-beta

• Expected behaviour
  ...
  Blocks are going to insert in each block.

• Actual behaviour
  ...

The bsc nodes sometimes going to hang for a few seconds and resume working, from my logs I can see my disk performance should not be the cause.

I tried v1.5.19, it does not have the same issue.

Backtrace

INFO [10-18|07:59:57.156] Imported new chain segment               number=65,031,541 hash=ecd1f8..3eda7c miner=0x5009317FD4F6F8FeEa9dAe41E5F0a4737BB7A7D5 blocks=6  txs=1142 blobs=2 mgas=174.350 elapsed=332.283ms   mgasps=524.703  snapdiffs=9.52MiB  triedirty=0.00B trieimutabledirty=0.00B
INFO [10-18|07:59:52.171] Imported new chain segment               number=65,031,535 hash=8f5abf..04984c miner=0x4e5acf9684652BEa56F2f01b7101a225Ee33d23f blocks=1  txs=178  blobs=0 mgas=26.779  elapsed=30.283ms    mgasps=884.265  snapdiffs=13.19MiB triedirty=0.00B trieimutabledirty=0.00B
INFO [10-18|07:59:51.497] Imported new chain segment               number=65,031,534 hash=66057b..184da1 miner=0x4e5acf9684652BEa56F2f01b7101a225Ee33d23f blocks=1  txs=188  blobs=1 mgas=28.563  elapsed=36.710ms    mgasps=778.059  snapdiffs=13.12MiB triedirty=0.00B trieimutabledirty=0.00B
INFO [10-18|07:59:50.680] Imported new chain segment               number=65,031,533 hash=32c94d..5e3d18 miner=0x4e5acf9684652BEa56F2f01b7101a225Ee33d23f blocks=1  txs=176  blobs=0 mgas=23.091  elapsed=27.850ms    mgasps=829.093  snapdiffs=13.05MiB triedirty=0.00B trieimutabledirty=0.00B

When submitting logs: please submit them as text and not screenshots.

[zzzckck]

Hi @swift1911 , thank you for your feedback, based on your logs, it is an issue of BSC sync stuck, the mgasps is ok.

We didn't see similar issue on our nodes and based on the log that you uploaded:

Seems like, we don't have the log: "EthScheduler-Workers-0...", is the log printed by our client or your own service?

Meanwhile, v1.6.1 would try to generate the log filter index from scratch, which could impact performance, could you disable it to have a try? The LogFilter is for RPC node to make it faster to query historical log, you can disable it by adding the flag: --history.logs.disable.

[swift1911]

Hi @zzzckck , I tried with the --history.logs.disable=true but it does not fix that. And the quick fetching feature is enabled in the config file.

[zzzckck]

Hi @zzzckck , I tried with the --history.logs.disable=true but it does not fix that. And the quick fetching feature is enabled in the config file.

Maybe your node was not connected with enough stable P2P nodes?
Here is some P2P nodes, you may add it in config.toml to have a try:

StaticNodes = [
...
"enode://551c8009f1d5bbfb1d64983eeb4591e51ad488565b96cdde7e40a207cfd6c8efa5b5a7fa88ed4e71229c988979e4c720891287ddd7d00ba114408a3ceb972ccb@34.245.203.3:30311",
"enode://c637c90d6b9d1d0038788b163a749a7a86fed2e7d0d13e5dc920ab144bb432ed1e3e00b54c1a93cecba479037601ba9a5937a88fe0be949c651043473c0d1e5b@34.244.120.206:30311",
"enode://bac6a548c7884270d53c3694c93ea43fa87ac1c7219f9f25c9d57f6a2fec9d75441bc4bad1e81d78c049a1c4daf3b1404e2bbb5cd9bf60c0f3a723bbaea110bc@3.255.117.110:30311",
"enode://94e56c84a5a32e2ef744af500d0ddd769c317d3c3dd42d50f5ea95f5f3718a5f81bc5ce32a7a3ea127bc0f10d3f88f4526a67f5b06c1d85f9cdfc6eb46b2b375@3.255.231.219:30311",
"enode://5d54b9a5af87c3963cc619fe4ddd2ed7687e98363bfd1854f243b71a2225d33b9c9290e047d738e0c7795b4bc78073f0eb4d9f80f572764e970e23d02b3c2b1f@34.245.16.210:30311"
]

[swift1911]

Hi @zzzckck , it looks better when the node discovery was disabled and running with static nodes, and I found out that there is no logs to show slow peers error on v1.6.1-beta.

Here is the logs for v1.5.19, but there is no logs like that on v1.6.1-beta

Is there any logic changed on v1.6.1-beta about dropping high latency peers and reconnect with new peers?