Skip to content
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.

After upgraded to 1.11.8, new bottleneck appears #9255

Closed
Caoxuyang opened this issue Jul 31, 2018 · 11 comments
Closed

After upgraded to 1.11.8, new bottleneck appears #9255

Caoxuyang opened this issue Jul 31, 2018 · 11 comments
Assignees
Labels
F3-annoyance 💩 The client behaves within expectations, however this “expected behaviour” itself is at issue. M4-core ⛓ Core client code / Rust.
Milestone

Comments

@Caoxuyang
Copy link

Caoxuyang commented Jul 31, 2018

I'm running:

  • Which Parity version?: 1.11.8 (1.11.5 before that)
  • Which operating system?: Linux
  • How installed?: from source
  • Are you fully synchronized?: no
  • Which network are you connected to?: private chain
  • Did you try to restart the node?: yes

I developed a benchmark tools to test TPS performance on Parity private chain.
Before I upgrade to 1.11.8, I was using 1.11.5. And my benchmark tests went our fine.
Tps can go above 3000.

My test goes like this:

I usually start 20 processes and send totallly 200000 signed txs to the network and calculate TPS from the blocks. The network consists of one transaction node to receive RPC requests and two mining nodes.
All the nodes are running in separate VMs.
My gasLimit is big enough for more than 50000 transactions to be mined in a single block.

But in 1.11.8, I run the exactly same test mentioned above.
Tps is limited by the mining-node. (tx-node has the same behavior, cpu, memory, throughput ...)

In each block, at most 4096 txs are mined. (One transaction uses 21000 gas.)
And I will paste my configure parameters for parity:

--gasprice 0 --tx-queue-size 400000 --tx-queue-per-sender=25000 --jsonrpc-threads=8 --jsonrpc-server-threads=8
And my gasLimit is big enough, well, my previous tests proved that.

I looked through all the releases from 1.11.5 to 1.11.8, but I didn't get any idea.
Any help will be great, thanks in advance.

@Tbaut
Copy link
Contributor

Tbaut commented Jul 31, 2018

This looks like an interesting project, thanks for building it.
What is your actual question?

@Tbaut Tbaut added Z1-question 🙋‍♀️ Issue is a question. Closer should answer. M4-core ⛓ Core client code / Rust. labels Jul 31, 2018
@Tbaut Tbaut added this to the 2.1 milestone Jul 31, 2018
@Caoxuyang
Copy link
Author

@Tbaut Question is everything works fine with parity v 1.11.5. (TPS was around 3000.)
But after I upgrade my parity to 1.11.8, the performance of mining node seems to appear a new bottleneck.
In each block, there are at most 4096 txs mined. (TPS is only around 800 now)
I wonder if you guys added some new tags to restrict the performance?

@debris
Copy link
Collaborator

debris commented Aug 1, 2018

@tomusdrw were there any changes to tx queue that could affect this?

@tomusdrw
Copy link
Collaborator

tomusdrw commented Aug 1, 2018

Yes: https://github.com/paritytech/parity-ethereum/blob/master/ethcore/sync/src/chain/mod.rs#L155

We only propagate up to 4096 transactions from the queue, so the mining nodes just don't have more transactions. I suppose we should make this number dynamic (dependent on the block gas limit) and propagate up to BLOCKS * block_gas_limit / 21_000 transactions from the pool, with BLOCKS = 4 | 5.

Also it would be good to implement additional propagation strategy, where each new transaction (or at least every local transaction) in the pool is propagated right away (1tx per packet) - currently propagation is triggered every second afair.

@tomusdrw tomusdrw self-assigned this Aug 1, 2018
@Tbaut Tbaut added F3-annoyance 💩 The client behaves within expectations, however this “expected behaviour” itself is at issue. and removed Z1-question 🙋‍♀️ Issue is a question. Closer should answer. labels Aug 1, 2018
@Tbaut Tbaut added this to Needs Assignment in Core via automation Aug 1, 2018
@Tbaut Tbaut moved this from Needs Assignment to Straightforward Picks in Core Aug 1, 2018
@Caoxuyang
Copy link
Author

@tomusdrw Thx! So for now in parity 1.11.8, this parameter is kind of hard coded, right? Maybe provide a tag to allow developers to tune this value will be great.

@tomusdrw
Copy link
Collaborator

tomusdrw commented Aug 2, 2018

@Caoxuyang yes, although have a look at the submitted PR (#9265) it should solve the issue and bring the perf back. Let me know the tests results :)

Core automation moved this from Straightforward Picks to Done Aug 2, 2018
andresilva pushed a commit that referenced this issue Aug 2, 2018
Closes #9255 

This PR also removes the limit of max 64 transactions per packet, currently we only attempt to prevent the packet size to go over 8MB. This will only be the case for super-large transactions or high-block-gas-limit chains.

Patching this is important only for chains that have blocks that can fit more than 4k transactions (over 86M block gas limit)

For mainnet, we should actually see a tiny bit faster propagation since instead of computing 4k pending set, we only need `4 * 8M / 21k = 1523` transactions.

Running some tests on `dekompile` node right now, to check how it performs in the wild.
@Caoxuyang
Copy link
Author

@tomusdrw I tested on 1.11.8. It's cool and the result stays the same, around 3000 tps. Thanks a million.

However I meet another issue, if I set the tx-queue-size to a large number like 500000.
And I send 500000 transactions to the transaction node, after like 200000 txs mined, the transaction node will automatically disconnect with the mining nodes. The transaction node is still running but the transaction node just can't join the network anymore. (Mining nodes are still connected with each other.) This issue happened on both 1.11.5 and 1.11.8.

@tomusdrw
Copy link
Collaborator

tomusdrw commented Aug 8, 2018

Could you run the transaction node with -lsync=trace and send us some logs from the time when it happens?

@Caoxuyang
Copy link
Author

Caoxuyang commented Aug 8, 2018

@tomusdrw I opened the logs actually, and just now I tried again to reproduce it. Here is the logs:

`2018-08-08 09:05:28 UTC Verifier #0 INFO import Imported #18 0xf5d6…dc0d (1 txs, 0.07 Mgas, 1 ms, 0.73 KiB)

2018-08-08 09:05:29 UTC IO Worker #1 TRACE sync Skipping warp sync. State: Idle
2018-08-08 09:05:29 UTC IO Worker #0 DEBUG network Connecting peers: 2 sessions, 4 pending + 1 started

2018-08-08 09:05:29 UTC IO Worker #1 DEBUG sync Error sending packet: Error(OversizedPacket, State { next_error: None, backtrace: None })

2018-08-08 09:05:29 UTC IO Worker #1 TRACE sync 02 <- Transactions (108994 entries)
2018-08-08 09:05:29 UTC IO Worker #1 TRACE sync 07 <- Transactions (64 entries)
2018-08-08 09:05:29 UTC IO Worker #1 DEBUG sync Sent up to 108994 transactions to 2 peers.
2018-08-08 09:05:29 UTC IO Worker #0 TRACE sync == Disconnecting 2: Parity/v1.11.5-beta-0487c5b-20180629/x86_64-linux-gnu/rustc1.27.0

2018-08-08 09:05:29 UTC IO Worker #0 DEBUG sync Disconnected 2
2018-08-08 09:05:29 UTC IO Worker #0 TRACE sync Syncing with peers: 1 active, 1 confirmed, 1 total
2018-08-08 09:05:29 UTC IO Worker #0 TRACE sync Considering peer 7, force=false, td=None, our td=6125082604576892342340742933771060947139, latest=0xf5d6…dc0d, have_latest=true, state=Idle`

I think the problem is the Error inside, OversizedPacket. However all of the transactions I sent are of the same content and size.
And thank you for your quick reply!

@tomusdrw
Copy link
Collaborator

tomusdrw commented Aug 8, 2018

@Caoxuyang please try with #9308

@Caoxuyang
Copy link
Author

@tomusdrw NP, I will try this later today.

5chdn pushed a commit that referenced this issue Aug 23, 2018
Closes #9255 

This PR also removes the limit of max 64 transactions per packet, currently we only attempt to prevent the packet size to go over 8MB. This will only be the case for super-large transactions or high-block-gas-limit chains.

Patching this is important only for chains that have blocks that can fit more than 4k transactions (over 86M block gas limit)

For mainnet, we should actually see a tiny bit faster propagation since instead of computing 4k pending set, we only need `4 * 8M / 21k = 1523` transactions.

Running some tests on `dekompile` node right now, to check how it performs in the wild.
andresilva pushed a commit that referenced this issue Aug 27, 2018
Closes #9255

This PR also removes the limit of max 64 transactions per packet, currently we only attempt to prevent the packet size to go over 8MB. This will only be the case for super-large transactions or high-block-gas-limit chains.

Patching this is important only for chains that have blocks that can fit more than 4k transactions (over 86M block gas limit)

For mainnet, we should actually see a tiny bit faster propagation since instead of computing 4k pending set, we only need `4 * 8M / 21k = 1523` transactions.

Running some tests on `dekompile` node right now, to check how it performs in the wild.
5chdn added a commit that referenced this issue Aug 30, 2018
* parity-version: bump stable to 1.11.9

* Fix compilation error on nightly rust (#8707)

On nightly rust passing `public_url` works but that breaks on stable. This works for both.

* parity-version: bump stable to 1.11.10

* Check if synced when using eth_getWork (#9193) (#9210)

* Check if synced when using eth_getWork (#9193)

* Don't use fn syncing

* Fix identation

* Fix typo

* Don't check for warping

* rpc: avoid calling queue_info twice on eth_getWork

* Fix potential as_usize overflow when casting from U256 in miner (#9221)

* Allow old blocks from peers with lower difficulty (#9226)

Previously we only allow downloading of old blocks if the peer
difficulty was greater than our syncing difficulty. This change allows
downloading of blocks from peers where the difficulty is greater then
the last downloaded old block.

* Update Dockerfile (#9242)

* Update Dockerfile

fix Docker build

* fix dockerfile paths: parity -> parity-ethereum (#9248)

* Update tobalaba.json (#9313)

* Light client `Provide default nonce in transactions when it´s missing` (#9370)

* Provide `default_nonce` in tx`s when it´s missing

When `nonce` is missing in a `EthTransaction` will cause it to fall in
these cases provide `default_nonce` value instead!

* Changed http:// to https:// on Yasm link (#9369)

Changed http:// to https:// on Yasm link in README.md

* Provide `default_nonce` in tx`s when it´s missing

When `nonce` is missing in a `EthTransaction` will cause it to fall in
these cases provide `default_nonce` value instead!

* Address grumbles

* ethcore: kovan: delay activation of strict score validation (#9406)

* Use impl Future in the light client RPC helpers (#8628)

* Better support for eth_getLogs in light mode (#9186)

* Light client on-demand request for headers range.

* Cache headers in HeaderWithAncestors response.

Also fulfills request locally if all headers are in cache.

* LightFetch::logs fetches missing headers on demand.

* LightFetch::logs limit the number of headers requested at a time.

* LightFetch::logs refactor header fetching logic.

* Enforce limit on header range length in light client logs request.

* Fix light request tests after struct change.

* Respond to review comments.

* Propagate transactions for next 4 blocks. (#9265)

Closes #9255

This PR also removes the limit of max 64 transactions per packet, currently we only attempt to prevent the packet size to go over 8MB. This will only be the case for super-large transactions or high-block-gas-limit chains.

Patching this is important only for chains that have blocks that can fit more than 4k transactions (over 86M block gas limit)

For mainnet, we should actually see a tiny bit faster propagation since instead of computing 4k pending set, we only need `4 * 8M / 21k = 1523` transactions.

Running some tests on `dekompile` node right now, to check how it performs in the wild.

* ethcore: fix pow difficulty validation (#9328)

* ethcore: fix pow difficulty validation

* ethcore: validate difficulty is not zero

* ethcore: add issue link to regression test

* ethcore: fix tests

* ethcore: move difficulty_to_boundary to ethash crate

* ethcore: reuse difficulty_to_boundary and boundary_to_difficulty

* ethcore: fix grumbles in difficulty_to_boundary_aux
5chdn added a commit that referenced this issue Aug 31, 2018
* parity-version: bump beta to 2.0.2

* remove ssl from dockerfiles, closes #8880 (#9195)

* snap: remove ssl dependencies from snapcraft definition (#9222)

* parity-version: bump beta to 2.0.3

* Remove all dapp permissions related settings (#9120)

* Completely remove all dapps struct from rpc

* Remove unused pub use

* Remove dapp policy/permission func in ethcore

* Remove all dapps settings from rpc

* Fix rpc tests

* Use both origin and user_agent

* Address grumbles

* Address grumbles

* Fix tests

* Check if synced when using eth_getWork (#9193) (#9210)

* Check if synced when using eth_getWork (#9193)

* Don't use fn syncing

* Fix identation

* Fix typo

* Don't check for warping

* rpc: avoid calling queue_info twice on eth_getWork

* Fix potential as_usize overflow when casting from U256 in miner (#9221)

* Allow old blocks from peers with lower difficulty (#9226)

Previously we only allow downloading of old blocks if the peer
difficulty was greater than our syncing difficulty. This change allows
downloading of blocks from peers where the difficulty is greater then
the last downloaded old block.

* Update Dockerfile (#9242)

* Update Dockerfile

fix Docker build

* fix dockerfile paths: parity -> parity-ethereum (#9248)

* Propagate transactions for next 4 blocks. (#9265)

Closes #9255 

This PR also removes the limit of max 64 transactions per packet, currently we only attempt to prevent the packet size to go over 8MB. This will only be the case for super-large transactions or high-block-gas-limit chains.

Patching this is important only for chains that have blocks that can fit more than 4k transactions (over 86M block gas limit)

For mainnet, we should actually see a tiny bit faster propagation since instead of computing 4k pending set, we only need `4 * 8M / 21k = 1523` transactions.

Running some tests on `dekompile` node right now, to check how it performs in the wild.

* Update tobalaba.json (#9313)

* Fix load share (#9321)

* fix(light_sync): calculate `load_share` properly

* refactor(api.rs): extract `light_params` fn, add test

* style(api.rs): add trailing commas

* ethcore: fix pow difficulty validation (#9328)

* ethcore: fix pow difficulty validation

* ethcore: validate difficulty is not zero

* ethcore: add issue link to regression test

* ethcore: fix tests

* ethcore: move difficulty_to_boundary to ethash crate

* ethcore: reuse difficulty_to_boundary and boundary_to_difficulty

* ethcore: fix grumbles in difficulty_to_boundary_aux

* Light client `Provide default nonce in transactions when it´s missing` (#9370)

* Provide `default_nonce` in tx`s when it´s missing

When `nonce` is missing in a `EthTransaction` will cause it to fall in
these cases provide `default_nonce` value instead!

* Changed http:// to https:// on Yasm link (#9369)

Changed http:// to https:// on Yasm link in README.md

* Provide `default_nonce` in tx`s when it´s missing

When `nonce` is missing in a `EthTransaction` will cause it to fall in
these cases provide `default_nonce` value instead!

* Address grumbles

* ethcore: kovan: delay activation of strict score validation (#9406)

* Better support for eth_getLogs in light mode (#9186)

* Light client on-demand request for headers range.

* Cache headers in HeaderWithAncestors response.

Also fulfills request locally if all headers are in cache.

* LightFetch::logs fetches missing headers on demand.

* LightFetch::logs limit the number of headers requested at a time.

* LightFetch::logs refactor header fetching logic.

* Enforce limit on header range length in light client logs request.

* Fix light request tests after struct change.

* Respond to review comments.

* Add update docs script to CI (#9219)

* Add update docs script to CI

Added a script to CI that will use the jsonrpc tool to update rpc
documentation then commit and push those to the wiki repo.

* fix gitlab ci lint

* Only apply jsonrpc docs update on tags

* Update gitlab-rpc-docs.sh

* Copy correct parity repo to jsonrpc folder

Copy correct parity repo to jsonrpc folder before attempting to build docs since the CI runner clones the repo as parity and not parity-ethereum.

* Fix JSONRPC docs CI job

Update remote config in wiki repo before pushing changes using a github
token for authentication. Add message to wiki tag when pushing changes.
Use project directory to correctly copy parity code base into the
jsonrpc repo for doc generation.

* Fix set_remote_wiki function call in CI

* Prevent blockchain & miner racing when accessing pending block. (#9310)

* Prevent blockchain & miner racing when accessing pending block.

* Fix unavailability of pending block during reseal.

* Prevent sync restart if import queue full (#9381)

* Add POA Networks: Core and Sokol (#9413)

* ethcore: add poa network and sokol chainspecs

* rpc: simplify chain spec docs

* cli: rearrange networks by main/test and size/range

* parity: don't blacklist 0x00a328 on sokol testnet

* parity: add sokol and poanet to params and clean up a bit, add tests

* ethcore: add the poa networks and clean up a bit

* ethcore: fix path to poacore chain spec

* parity: rename poa networks to poacore and poasokol

* parity: fix configuration tests

* parity: fix parameter tests

* ethcore: rename POA Core and POA Sokol

* Update tobalaba.json (#9419)

* Update hardcoded sync (#9421)

- Update foundation hardcoded header to block 6219777 
- Update ropsten hardcoded header to block 3917825 
- Update kovan hardcoded header to block 8511489
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
F3-annoyance 💩 The client behaves within expectations, however this “expected behaviour” itself is at issue. M4-core ⛓ Core client code / Rust.
Projects
None yet
Development

No branches or pull requests

4 participants