Skip to content

[server] add support of KvPreWriteBuffer backpressure - #3751

Open
zuston wants to merge 3 commits into
apache:mainfrom
zuston:backpressureWithBuffer
Open

[server] add support of KvPreWriteBuffer backpressure#3751
zuston wants to merge 3 commits into
apache:mainfrom
zuston:backpressureWithBuffer

Conversation

@zuston

@zuston zuston commented Jul 23, 2026

Copy link
Copy Markdown
Member

Purpose

Linked issue: close #3532

Without a backpressure mechanism for KvPreWriteBuffer , the tablet server is at risk of OOM, particularly when ingestion throughput is high but replication is slow. A similar issue can occur during recovery: if the follower is not yet ready while the leader continues accepting client writes, buffered data may accumulate rapidly, causing the leader tablet server to run out of memory and exit.

Brief change log

  1. Introduce a global KvPreWriteBuffer memory pool for each tablet server. When memory usage reaches the configured high watermark, incoming client writes are temporarily rejected and retried until usage falls below the low watermark.

In the first phase, I will implement the recovery logic using this unified mechanism. However, recovery may fail when buffer utilization is high due to high-throughput client ingestion. This issue is unlikely to occur under normal conditions.

Tests

API and Format

Documentation

@zuston zuston changed the title [server] add support of KvPreWriteBuffer backpressure [server] add support of KvPreWriteBuffer backpressure Jul 23, 2026
@zuston
zuston marked this pull request as ready for review July 24, 2026 03:38
@zuston

zuston commented Jul 24, 2026

Copy link
Copy Markdown
Member Author

ptal @fresh-borzoni

@beryllw

beryllw commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

@platinumhamburg Could you take a look when you get a chance?

@luoyuxia

Copy link
Copy Markdown
Contributor

I fell like #3463 can solve this backpressure problem

* The tablet server rejected a KV write because its global pre-write buffer high watermark was
* reached.
*
* <p>The client may retry the write after a backoff. The rejected write has not been appended to

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thanks for working on this. We also have #3463, which implements cooperative KV backpressure based on RocksDB L0 metrics. Could you try it and see whether it also addresses the problem described here?

In general, backpressure needs client-side cooperation—for example, retry with exponential backoff—rather than only returning a retriable error from the server. #3463 introduces the server-client throttling/backoff mechanism, so it may be better to let #3463 land first and then build this change on top of it.

My understanding is that the main difference between the two PRs is the source of the pressure signal: #3463 derives pressure from the RocksDB L0 file count, while this PR derives it from KvPreWriteBuffer memory usage to prevent OOM. If so, could this PR reuse the mechanism introduced by #3463 and add pre-write-buffer memory pressure as another backpressure source?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[server] add the metric of KV preWriteBuffer

4 participants