Open fylsan3 opened 1 year ago
29 lags within 12 hours
This issue is stale because it has been open for 40 days with no activity. Remove stale label or comment, or this will be closed in 7 days.
We experience the same problem with Version v2.52.5 with two different senderIDs in the logs.
The same warning occurs on version 2.58.2 on Ubuntu (every 20-30 seconds day by day):
Mar 14 07:43:10 backup2 erigon[1617922]: [WARN] [03-14|07:43:10.045] [txpool] flush: sender address not found by ID senderID=14107
Mar 14 07:43:25 backup2 erigon[1617922]: [WARN] [03-14|07:43:25.110] [txpool] flush: sender address not found by ID senderID=14107
Mar 14 07:43:40 backup2 erigon[1617922]: [WARN] [03-14|07:43:40.179] [txpool] flush: sender address not found by ID senderID=14107
Mar 14 07:43:55 backup2 erigon[1617922]: [WARN] [03-14|07:43:55.241] [txpool] flush: sender address not found by ID senderID=14107
Mar 14 07:44:10 backup2 erigon[1617922]: [WARN] [03-14|07:44:10.305] [txpool] flush: sender address not found by ID senderID=14107
Mar 14 07:44:25 backup2 erigon[1617922]: [WARN] [03-14|07:44:25.367] [txpool] flush: sender address not found by ID senderID=14107
Moreover, if Erigon is restarted, the error in the logs disappears, but after some time, it appears again, but with a different senderID. Exactly the same behavior was observed in the two previous release versions.
bump
System information
Erigon version:
erigon version 2.48.1-stable-674b77f0
OS & Version: Ubuntu 20.04.4 LTS
Commit hash: 674b77f0
Erigon Command (with flags/config):nohup /data/polygon/erigon/build/bin/erigon --chain=bor-mainnet \ --datadir='/data/polygon/' \ --maxpeers='500' --torrent.upload.rate='128mb' \ --torrent.download.rate='128mb' \ --bor.heimdall='https://heimdall-api.polygon.technology' \ --ethash.dagdir='/data/polygon/ethash/' \ --http --http.corsdomain='' \ --http.addr='0.0.0.0' \ --http.api='erigon,web3,eth,net,engine,admin,trace,debug,txpool' \ --ws --http.vhosts='' \ --rpc.gascap 100000000 --rpc.returndata.limit 1000000 --rpc.batch.limit 1000 \ --db.size.limit 8TB \ --sentry.drop-useless-peers=true \
Synchronization often lags behind and has not been working properly since using version 2.48.0 Please fix this issue, it will exist for a period of time and recover on its own