-
Notifications
You must be signed in to change notification settings - Fork 86
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
Mempool: Allow for dynamically adjusting the capacity #1498
Comments
intricate
added
consensus
issues related to ouroboros-consensus
mempool
priority low
labels
Jan 23, 2020
mrBliss
added a commit
that referenced
this issue
May 27, 2020
Fixes #1498. The capacity of the Mempool can be manually overridden using 'MempoolCapacityBytesOverride'. When not overridden, the default capacity is computed as 2x the maximum transaction capacity of a block, which is derived from the protocol parameters in the ledger state. Previously, this default capacity was computed *once* based on the ledger state at the time of starting the Mempool. So when the maximum transaction capacity of a block changes in the ledger, a restart of the node was needed to let the Mempool update its capacity accordingly. In this commit, we make it dynamic: we derive it from the ledger that the Mempool watches. When the capacity shrinks, we don't remove transactions to satisfy the new capacity, but we treat the Mempool as if it is *at* capacity. This means no new transactions are admitted until some have been invalidated by an update to the ledger.
mrBliss
added a commit
that referenced
this issue
May 27, 2020
Fixes #1498. The capacity of the Mempool can be manually overridden using 'MempoolCapacityBytesOverride'. When not overridden, the default capacity is computed as 2x the maximum transaction capacity of a block, which is derived from the protocol parameters in the ledger state. Previously, this default capacity was computed *once* based on the ledger state at the time of starting the Mempool. So when the maximum transaction capacity of a block changes in the ledger, a restart of the node was needed to let the Mempool update its capacity accordingly. In this commit, we make it dynamic: we derive it from the ledger that the Mempool watches. When the capacity shrinks, we don't remove transactions to satisfy the new capacity, but we treat the Mempool as if it is *at* capacity. This means no new transactions are admitted until some have been invalidated by an update to the ledger.
mrBliss
added a commit
that referenced
this issue
May 27, 2020
Fixes #1498. The capacity of the Mempool can be manually overridden using 'MempoolCapacityBytesOverride'. When not overridden, the default capacity is computed as 2x the maximum transaction capacity of a block, which is derived from the protocol parameters in the ledger state. Previously, this default capacity was computed *once* based on the ledger state at the time of starting the Mempool. So when the maximum transaction capacity of a block changes in the ledger, a restart of the node was needed to let the Mempool update its capacity accordingly. In this commit, we make it dynamic: we derive it from the ledger that the Mempool watches. When the capacity shrinks, we don't remove transactions to satisfy the new capacity, but we treat the Mempool as if it is *at* capacity. This means no new transactions are admitted until some have been invalidated by an update to the ledger.
mrBliss
added a commit
that referenced
this issue
May 27, 2020
Fixes #1498. The capacity of the Mempool can be manually overridden using 'MempoolCapacityBytesOverride'. When not overridden, the default capacity is computed as 2x the maximum transaction capacity of a block, which is derived from the protocol parameters in the ledger state. Previously, this default capacity was computed *once* based on the ledger state at the time of starting the Mempool. So when the maximum transaction capacity of a block changes in the ledger, a restart of the node was needed to let the Mempool update its capacity accordingly. In this commit, we make it dynamic: we derive it from the ledger that the Mempool watches. When the capacity shrinks, we don't remove transactions to satisfy the new capacity, but we treat the Mempool as if it is *at* capacity. This means no new transactions are admitted until some have been invalidated by an update to the ledger.
mrBliss
added a commit
that referenced
this issue
May 27, 2020
Fixes #1498. The capacity of the Mempool can be manually overridden using 'MempoolCapacityBytesOverride'. When not overridden, the default capacity is computed as 2x the maximum transaction capacity of a block, which is derived from the protocol parameters in the ledger state. Previously, this default capacity was computed *once* based on the ledger state at the time of starting the Mempool. So when the maximum transaction capacity of a block changes in the ledger, a restart of the node was needed to let the Mempool update its capacity accordingly. In this commit, we make it dynamic: we derive it from the ledger that the Mempool watches. When the capacity shrinks, we don't remove transactions to satisfy the new capacity, but we treat the Mempool as if it is *at* capacity. This means no new transactions are admitted until some have been invalidated by an update to the ledger.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As of #1468, by default (unless overridden in the
NodeArgs
), the mempool capacity is calculated as 2x that of the maximum block size from the protocol parameters in the ledger.However, the mempool capacity is only calculated once at node initialization time which means that, if the ledger's max block size changes during the node's runtime, the mempool capacity will not be automatically recalculated to reflect this. The mempool capacity would only be calculated again upon restarting the node.
See #1468 (review) for discussion WRT this.
The text was updated successfully, but these errors were encountered: