-
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
import: fix memory leak #39332
import: fix memory leak #39332
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. |
/run-integration-br-test |
/cc @3pointer @lance6716 |
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.
seems we can add a simple unit test that after some AllocateBuf
/Set
and Recycle
, the mb.availableBufs
does not grow badly
existingBuf *bytesBuf | ||
existingBufIdx int | ||
) | ||
for i, buf := range mb.availableBufs { |
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.
should we limit max length of mb.availableBufs
? in case encodeLoop
is slow down for we might loop through all availableBufs on every AllocateBuf
in worst case
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.
Maybe no need to limit the max length. There are two reasons:
- the allocation size is by the power of 2, starting from 1MB. So the possible byte buffer capacities are 1MB, 2MB, 4MB, ... Since the memory limit is typically around 256GB, and the reuse mechanism has fixed now, in the extreme case without any reuse, the available byte buffer pool's size is around 18 (1MB, 2MB, 4MB, .... 256GB), otherwise a reuse will happen .
- the typical allocation size will fall into only some byte buffer sizes. Since the reuse mechanism has fixed now, the reuse will happen frequently. So the overall
availableBufs
size is controllable.
But it is OK to add a defending mechanism for the performance degration here.
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.
Fixed in a71021c
Fixed in a71021c |
/run-integration-br-test |
/run-integration-br-test |
} | ||
|
||
func TestKVMemBufBatchAllocAndRecycle(t *testing.T) { | ||
type testCase struct { |
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.
this type is not used?
/merge |
This pull request has been accepted and is ready to merge. Commit hash: 0174d56
|
In response to a cherrypick label: new pull request created: #39407. |
Signed-off-by: ti-chi-bot <[email protected]>
In response to a cherrypick label: new pull request created: #39408. |
Signed-off-by: ti-chi-bot <[email protected]>
In response to a cherrypick label: new pull request created: #39409. |
Signed-off-by: ti-chi-bot <[email protected]>
TiDB MergeCI notify✅ Well Done! New fixed [1] after this pr merged.
|
What problem does this PR solve?
Issue Number: close #39331
Problem Summary:
What is changed and how it works?
When
kvMemBuf
reuses the byte buffer in the available byte buffer pool, iterate on all the byte buffer's capacity. If it can find at least one byte buffer with a large capacity, it will choose to reuse it, rather than create a new byte buffer.Check List
Tests
compile the modified version, and check whether memory leak has been fixed. Here are the heap profiles of the Lightning process after the modification:
Side effects
Documentation
Release note
Please refer to Release Notes Language Style Guide to write a quality release note.