Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Describe the migration to and how to configure the layered txpool #6006

Merged
merged 3 commits into from
Oct 10, 2023
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 21 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,27 @@
# Changelog

## 23.10.0-RC
### Layered Transaction Pool: the new default transaction pool implementation
With this release the previously experimental Layered txpool is marked stable and enabled by default, so please read the following instructions if you used to tune txpool behaviour,
otherwise you can simply go with the default and enjoy the improved performance of the new txpool.

#### Upgrading to Layered Transaction Pool
If you do not specify any txpool option, then you can skip this section.
If you have tuned the txpool using one of these options: `tx-pool-retention-hours`, `tx-pool-limit-by-account-percentage` or `tx-pool-max-size`,
then you need to update your configuration as described below:
- `tx-pool-retention-hours`: simply remove it, since it is not applicable in the Layered txpool, old transactions will eventually expire when the memory cache is full.
- `tx-pool-limit-by-account-percentage`: replace it with `tx-pool-max-future-by-sender`, which specify the max number of sequential transactions of single sender are kept in the txpool, by default it is 200.
- `tx-pool-max-size`: the Layered txpool is not limited by a max number of transactions, but by the estimated memory size the transactions occupy, so you need to remove this option, and to tune the max amount of memory<sup>*</sup> use the new option `tx-pool-layer-max-capacity` as described below.

You can still opt-out of the Layered txpool, setting `tx-pool=legacy` in config file or via cli argument, but be warned that the Legacy implementation will be deprecated for removal soon, so start testing the new implementation.

#### Configuring the Layered Transaction Pool
By default, the txpool is tuned for mainnet usage, but if you are using private networks or want otherwise tune it, these are the new options:
fab-10 marked this conversation as resolved.
Show resolved Hide resolved
- `tx-pool-max-future-by-sender`: specify the max number of sequential transactions of a single sender are kept in the txpool, by default it is 200, increase it to allow a single sender to fit more transactions in a single block.
fab-10 marked this conversation as resolved.
Show resolved Hide resolved
- `tx-pool-layer-max-capacity`: set the max amount of memory<sup>*</sup> in bytes, a single memory limited layer can occupy, by default is 12.5MB, keep in mind that there are 2 memory limited layers, so the expected memory consumption is twice the value specified by this option, so 25MB by default. Increase this value if you have spare ram and the eviction rate is high for you network.
fab-10 marked this conversation as resolved.
Show resolved Hide resolved
- `tx-pool-max-prioritized`: set the max number of transactions allowed in the first layer, that only contains transactions that are candidate for inclusion in the next block creation task, here it make sense to limit the value to the max number of transactions that fix in a block in your network, by default is 2000.
fab-10 marked this conversation as resolved.
Show resolved Hide resolved

<sup>*</sup>: the memory used by the txpool is an estimation, we are working to make it always more accurate.

### Breaking Changes
- Removed support for Kotti network (ETC) [#5816](https://github.com/hyperledger/besu/pull/5816)
Expand Down
Loading