-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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
lightning: add send-kv-size to avoid oom when each kv is large on default config #43870
Conversation
[REVIEW NOTIFICATION] This pull request has been approved by:
To complete the pull request process, please ask the reviewers in the list to review by filling The full list of commands accepted by this bot can be found here. Reviewer can indicate their review by submitting an approval review. |
@@ -395,7 +395,9 @@ type BackendConfig struct { | |||
ConnCompressType config.CompressionType | |||
// concurrency of generateJobForRange and import(write & ingest) workers | |||
WorkerConcurrency int | |||
KVWriteBatchSize int |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
renamed to KVWriteBatchCount
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we'd better use a new name, rather than change the meaning of it. If we debug in different release version this is confusing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we have this name start from 7.1, if we pick to 7.1, i think it's ok
/run-integration-br-test |
4 similar comments
/run-integration-br-test |
/run-integration-br-test |
/run-integration-br-test |
/run-integration-br-test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rest lgtm
@@ -395,7 +395,9 @@ type BackendConfig struct { | |||
ConnCompressType config.CompressionType | |||
// concurrency of generateJobForRange and import(write & ingest) workers | |||
WorkerConcurrency int | |||
KVWriteBatchSize int |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we'd better use a new name, rather than change the meaning of it. If we debug in different release version this is confusing
KVWriteBatchCount = 32768 | ||
// KVWriteBatchSize batch size when write to TiKV. | ||
// this is the default value of linux send buffer size(net.ipv4.tcp_wmem) too. | ||
KVWriteBatchSize = 16 * units.KiB |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's too small considering a large row KV. Maybe we should use 4M which is the maximun value of it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it depends on how often do customer tune network parameters, if user do set to 4M
(256 * (accumulate 16k + serialize + append to linux send buffer)) + send to network
compared to (accumulate 4M + serialize + append to linux send buffer) + send to network
, seems no much difference, will test the default tcp_wmem + 16k/4m batch size using qa env
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i misunderstand, it works like this:
When a new TCP connection is established, a Send Buffer will be created using the default value (16KB); the buffer size will then be automatically adjusted within the maximum and minimum boundaries as needed and based on usage.
no speed difference during write/ingest whether use default 16k or 4m(573.1GiB source data)
|
/retest |
1 similar comment
/retest |
/merge |
This pull request has been accepted and is ready to merge. Commit hash: 48d321d
|
/retest |
4 similar comments
/retest |
/retest |
/retest |
/retest |
unstable cases will be fixed in #43880 |
/merge |
This pull request has been accepted and is ready to merge. Commit hash: 86b6e11
|
In response to a cherrypick label: new pull request created to branch |
In response to a cherrypick label: new pull request created to branch |
Signed-off-by: ti-chi-bot <[email protected]>
What problem does this PR solve?
Issue Number: close #43853
Problem Summary:
What is changed and how it works?
send-kv-size
together with existing configsend-kv-pairs
to control how much data to accumulate before send to tikvCheck List
Tests
range-concurrency=1
(2 thread writing concurrently); use a separatemembuf.Pool
forwriteToTiKV
and disable CGO version of membuf pool so we can know how much memory used by it; add sleep beforesend to tikv
, so we can take a heap profilebefore this pr:
after
Side effects
Documentation
Release note
Please refer to Release Notes Language Style Guide to write a quality release note.