Skip to content

Cherry pick #80777 to 25.3: Fix excessive number of files (leads to excessive memory usage) for external ORDER BY#80952

Merged
robot-clickhouse-ci-2 merged 8 commits intobackport/25.3/80777from
cherrypick/25.3/80777
May 28, 2025
Merged

Cherry pick #80777 to 25.3: Fix excessive number of files (leads to excessive memory usage) for external ORDER BY#80952
robot-clickhouse-ci-2 merged 8 commits intobackport/25.3/80777from
cherrypick/25.3/80777

Conversation

@robot-clickhouse-ci-1
Copy link
Copy Markdown
Contributor

Original pull-request #80777

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 #80777 for pr-backports-created label and delete it.

Manually merging will do nothing. The pr-backports-created label prevents the original PR #80777 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 #80777 for pr-backports-created, and delete if it's presented there

The PR source

The PR is created in the CI job

azat added 7 commits May 24, 2025 23:01
…xternal ORDER BY

In #72598 the behavior of `max_bytes_before_external_sort` has been
changed, it has been switched to rely on the total memory usage of the
query instead of the size of a sorting data.

But, the problem with this approach is that you can have a lot of memory
used outside of sorting (FINAL, aggregation), and spilling sorting
blocks to disk will not help reduce memory usage obviously, but it will
make things even worse, because it will create lots of small files, that
will require a lot of memory to merge them.

So this patch reverts the behavior of `max_bytes_before_external_sort`
back, now it will rely on the sorting block size.
Set max_bytes_before_external_sort=min_external_sort_block_bytes=100Mi
The problem is that now both conditions should be met:
- max_bytes_ratio_before_external_sort
- max_bytes_before_external_sort

So it is not possible to use max_bytes_ratio_before_external_sort=0.9,
this will lead to MEMORY_LIMIT_EXCEEDED errors
Fix excessive number of files (leads to excessive memory usage) for external ORDER BY
@robot-clickhouse-ci-1 robot-clickhouse-ci-1 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 May 28, 2025
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.

4 participants