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.

Sign up for GitHub

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

Re-apply qs backpressure increase with buffer latency increase #13961

Merged
merged 3 commits into from
Jul 10, 2024
Merged

Re-apply qs backpressure increase with buffer latency increase #13961

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
3c9938d
[quorum store] reduce backpressure significantly for more TPS (#13558)
bchocho Jun 7, 2024
d7b7653
increase buffer for expiration in batch creation
igor-aptos Jul 9, 2024
f32ed12
adding buffers on inner traffic as well
igor-aptos Jul 10, 2024
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
4 changes: 2 additions & 2 deletions config/src/config/mempool_config.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -85,8 +85,8 @@ impl Default for MempoolConfig {
system_transaction_timeout_secs: 600,
system_transaction_gc_interval_ms: 60_000,
broadcast_buckets: DEFAULT_BUCKETS.to_vec(),
eager_expire_threshold_ms: Some(10_000),
eager_expire_time_ms: 3_000,
eager_expire_threshold_ms: Some(15_000),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explain the downside of increasing this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

new constants make the logic like this:

if there is any transaction in the mempool (that never entered parking lot) that was there for longer than eager_expire_threshold_ms (which is increased from 10s -> 15s here) - that means we have a significant backlog.

if that is the case, we pull into batches only transactions that have at least eager_expire_time_ms time left (increased from 3s to 6s)

We've increased both, as with reduced QS backpressure, we see it taking more time from batch creation to batch being included in the block.

So the side-consequence of this change is that - if that during backlog, if you use expiration <6s, your transactions will be ignored (previously <3s).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good to me. Slightly orthogonal but do we really need this logic after @vusirikala 's change to exclude expired transaction in QS backpressure calculation in https://github.com/aptos-labs/aptos-core/pull/13850/files. cc - @bchocho

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

creating useless batches, and then requiring everyone to fetch them, just in order to throw them out - probably has negative effect on our overall throughput.

Copy link
Contributor

@vusirikala vusirikala Jul 10, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sitalkedia This is the run for graceful overload test with my changes and increasing QS backpressure limits without changing the eager_expire_threshold_ms config.
#13964 (comment)

eager_expire_time_ms: 6_000,
}
}
}
Expand Down
6 changes: 3 additions & 3 deletions config/src/config/quorum_store_config.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,14 +29,14 @@ impl Default for QuorumStoreBackPressureConfig {
QuorumStoreBackPressureConfig {
// QS will be backpressured if the remaining total txns is more than this number
// Roughly, target TPS * commit latency seconds
backlog_txn_limit_count: 12_000,
backlog_txn_limit_count: 36_000,
// QS will create batches at the max rate until this number is reached
backlog_per_validator_batch_limit_count: 4,
backlog_per_validator_batch_limit_count: 20,
decrease_duration_ms: 1000,
increase_duration_ms: 1000,
decrease_fraction: 0.5,
dynamic_min_txn_per_s: 160,
dynamic_max_txn_per_s: 4000,
dynamic_max_txn_per_s: 12000,
}
}
}
Expand Down
16 changes: 8 additions & 8 deletions testsuite/forge-cli/src/main.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1118,10 +1118,10 @@ fn realistic_env_workload_sweep_test() -> ForgeConfig {
]),
// Investigate/improve to make latency more predictable on different workloads
criteria: [
(7700, 100, 0.3, 0.3, 0.5, 0.5),
(7000, 100, 0.3, 0.3, 0.5, 0.5),
(2000, 300, 0.3, 0.8, 0.6, 1.0),
(3200, 500, 0.3, 0.4, 0.7, 0.7),
(7700, 100, 0.3, 0.5, 0.5, 0.5),
(7000, 100, 0.3, 0.5, 0.5, 0.5),
(2000, 300, 0.3, 1.0, 0.6, 1.0),
(3200, 500, 0.3, 1.5, 0.7, 0.7),
// (150, 0.5, 1.0, 1.5, 0.65),
]
.into_iter()
Expand Down Expand Up @@ -1966,9 +1966,9 @@ fn realistic_env_max_load_test(
.add_system_metrics_threshold(SystemMetricsThreshold::new(
// Check that we don't use more than 18 CPU cores for 10% of the time.
MetricsThreshold::new(18.0, 10),
// Memory starts around 3GB, and grows around 1.2GB/hr in this test.
// Memory starts around 3.5GB, and grows around 1.4GB/hr in this test.
// Check that we don't use more than final expected memory for more than 10% of the time.
MetricsThreshold::new_gb(3.3 + 1.4 * (duration_secs as f64 / 3600.0), 10),
MetricsThreshold::new_gb(3.5 + 1.4 * (duration_secs as f64 / 3600.0), 10),
))
.add_no_restarts()
.add_wait_for_catchup_s(
Expand All @@ -1986,8 +1986,8 @@ fn realistic_env_max_load_test(
LatencyBreakdownThreshold::new_with_breach_pct(
vec![
(LatencyBreakdownSlice::QsBatchToPos, 0.35),
// only reaches close to threshold during epoch change
(LatencyBreakdownSlice::QsPosToProposal, 0.6),
// quorum store backpressure is relaxed, so queueing happens here
(LatencyBreakdownSlice::QsPosToProposal, 2.5),
// can be adjusted down if less backpressure
(LatencyBreakdownSlice::ConsensusProposalToOrdered, 0.85),
// can be adjusted down if less backpressure
Expand Down
Loading