search

openethereum / openethereum

(deprecated) The fast, light, and robust client for the Ethereum mainnet.
GNU General Public License v3.0
1.64k stars 356 forks source link

Peers are dropped when too much transaction is in the txpool #346

Open iFA88 opened 3 years ago

iFA88 commented 3 years ago

Hey everyone. I have re-synced the whole DB with OpenEthereum/v3.1.1-stable-15b5581-20210119/x86_64-linux-gnu/rustc1.49.0 and it was more than one month.. but thats not the issue here. When it was done i updated my client to OpenEthereum/v3.2.1-stable-5fdedf0-20210317/x86_64-linux-gnu/rustc1.50.0. Previous was everything okay.. but now the sync hangs many times randomly. The environment is the same as previous.. The older client was OpenEthereum/v3.0.1-stable-8ca8089-20200601/x86_64-unknown-linux-gnu/rustc1.43.1.

Here is a log: https://www.fusionsolutions.io/doc/eth_2021-04-07_19-22.log The process eats 7-9 GB RES, which is normal like on the older ones.

I ran a service and it is very irritating that the client goes out of sync.

Run parameters:

openethereum --base-path /mnt/node-1/eth --chain foundation --tracing on --pruning fast --no-ancient-blocks --no-warp --no-ws --port 3001 --interface 94.199.178.233 --nat=extip:94.199.178.233 --cache-size-db 4096 --cache-size-blocks 64 --cache-size-queue 128 --cache-size-state 1024 --ipc-path /own/sockets/ethNode.ipc --ipc-apis all --jsonrpc-port 3000 --jsonrpc-apis all --jsonrpc-server-threads 12 --jsonrpc-allow-missing-blocks --min-gas-price 100000000 --tx-queue-mem-limit 0 --tx-queue-size 1000000 --tx-queue-per-sender=1024

Many thanks.

iFA88 commented 3 years ago

OpenEthereum/v3.2.2-rc.1-stable-582bca3-20210331/x86_64-linux-gnu/rustc1.51.0 produces the same issue.

iFA88 commented 3 years ago

OpenEthereum/v3.2.0-stable-458d555-20210308/x86_64-linux-gnu/rustc1.50.0 produces the same issue.

Little update: I query both parity_allTransactions and parity_pendingTransactionsStats request in every minute. They are the most expensive requests what I do. I have 110k to 250k pending transactions in the node. Maybe the sync hang caused by this?

sunce86 commented 3 years ago

For a fast checkup, why don't you try to remove the run parameter: --tx-queue-size 1000000, this way it will default to 8192 as default value.

iFA88 commented 3 years ago

The issue definitely caused by the big pending tx pool. Without the --tx-queue-size the client works as excepted.

Some log with -l sync=debug: https://www.fusionsolutions.io/doc/issue.tar.gz ( Syncing hangs about 2021-04-08 22:26:20 )

hfaakerx commented 3 years ago

Before the Berlin fork, I used 3.0.1 and everything was fine. After the Berlin fork, I had to upgrade the version, and then tried 3.2.3/3.2.4 and the same problem occurred.

iFA88 commented 2 years ago

Copied: So it seems it happens when i have more TX in the pool than 8k. Here is the log with the current parameters: https://www.fusionsolutions.io/doc/eth_2022-02-21_14-36.log I will now apply the --min-peers 50 and the -l sync=trace and will send later the log. Here is: https://www.fusionsolutions.io/doc/eth_2022-02-21_19-29.log Parameters what i use: --min-gas-price 10000000000 --no-persistent-txqueue --tx-queue-mem-limit 256 --tx-queue-size 10000 --tx-queue-no-early-reject --tx-queue-per-sender=128 --refuse-service-transactions --reseal-on-txs=none -lsync=trace --min-peers 50 --max-peers 50