Skip to content

Cherry pick #73081 to 24.3: Fix possible overestimate memory tracking#73121

Merged
robot-clickhouse merged 3 commits intobackport/24.3/73081from
cherrypick/24.3/73081
Dec 11, 2024
Merged

Cherry pick #73081 to 24.3: Fix possible overestimate memory tracking#73121
robot-clickhouse merged 3 commits intobackport/24.3/73081from
cherrypick/24.3/73081

Conversation

@robot-clickhouse
Copy link
Copy Markdown
Member

Original pull-request #73081

This pull-request is a first step of an automated backporting.
It contains changes similar to calling git cherry-pick locally.
If you intend to continue backporting the changes, then resolve all conflicts if any.
Otherwise, if you do not want to backport them, then just close this pull-request.

The check results does not matter at this step - you can safely ignore them.

Note

This pull-request will be merged automatically. Please, do not merge it manually (but if you accidentally did, nothing bad will happen).

Troubleshooting

If the PR was manually reopened after being closed

If this PR is stuck (i.e. not automatically merged after one day), check #73081 for pr-backports-created label and delete it.

Manually merging will do nothing. The pr-backports-created label prevents the original PR #73081 from being processed.

If the conflicts were resolved in a wrong way

If this cherry-pick PR is completely screwed by a wrong conflicts resolution, and you want to recreate it:

  • delete the pr-cherrypick label from the PR
  • delete this branch from the repository

You also need to check the original PR #73081 for pr-backports-created, and delete if it's presented there

azat and others added 3 commits December 10, 2024 19:50
Before this patch the untracked_memory was dumped before reseting the
current_thread which could lead to leaking some of untracked_memory in
`ThreadStatus::detachFromGroup` [1].

In particular I found that the local_data (which is 136 bytes) can be
"leaked" that way.

  [1]: https://github.com/ClickHouse/ClickHouse/blob/8999fdd95ea98fa083133d5cdf64ee149cd7f864/src/Interpreters/ThreadStatusExt.cpp#L292-L306

This pops up on one of clusters where I noticed that the difference
between MemoryTracking and MemoryResident keeps growing over the time.
the difference grows ~200KiB per second - 16.5GiB per day.

That cluster has tons MVs triggered from Buffer/Distributed (i.e. now
query context), and this is indeed is the reason for leaking local_data,
since in this case there is no thread group in the query, and it is
created explicitly in `InterpreterInsertQuery::buildChain` [1].

  [1]: https://github.com/ClickHouse/ClickHouse/blob/20ccb638ba00103f116855afbc473950ef2b867b/src/Interpreters/InterpreterInsertQuery.cpp#L321

Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>
Fix possible overestimate memory tracking
@robot-clickhouse robot-clickhouse added pr-cherrypick Cherry-pick of merge-commit before backporting. Do not use manually - automated use only! do not test disable testing on pull request pr-bugfix Pull request with bugfix, not backported by default labels Dec 11, 2024
@robot-clickhouse robot-clickhouse merged commit 631df90 into backport/24.3/73081 Dec 11, 2024
@robot-clickhouse robot-clickhouse deleted the cherrypick/24.3/73081 branch December 11, 2024 14:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

do not test disable testing on pull request pr-bugfix Pull request with bugfix, not backported by default pr-cherrypick Cherry-pick of merge-commit before backporting. Do not use manually - automated use only!

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants