You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A user can specify too large background_pool_size, and merges can constantly fail and make no progress due to memory exhaustion.
Horizontal merges of wide tables with many LowCardinality or AggregateFunction columns can have high memory usage.
Mutations can have high memory usage if they use complex expressions for updating or deleting.
We should not let too many merges be processed at once if the memory usage is high.
Implementation proposal
Add two global configuration options:
merges_memory_usage_soft_limit and merges_memory_usage_soft_limit_to_ram_ratio
similarly to max_server_memory_usage and max_server_memory_usage_to_ram_ratio. The latter setting should be 0.5 by default.
Track the total memory usage by merges.
Caveat: it cannot be done with MemoryTracker. Because a merge operation can free some memory (primary keys) that were allocated outside of the context of the merge, the resulting memory usage at the end of the merge can be negative. We cannot reset it to zero at the end of the merge operation because the MemoryTracker of the merge is attached to the server's global MemoryTracker and should be consistent with it. The only reasonable way is to track the sum of memory usage by active merges separately.
If the current memory usage by merges is higher than the soft limit, do not start new merges.
The text was updated successfully, but these errors were encountered:
Use case
A user can specify too large
background_pool_size
, and merges can constantly fail and make no progress due to memory exhaustion.Horizontal merges of wide tables with many
LowCardinality
orAggregateFunction
columns can have high memory usage.Mutations can have high memory usage if they use complex expressions for updating or deleting.
We should not let too many merges be processed at once if the memory usage is high.
Implementation proposal
Add two global configuration options:
merges_memory_usage_soft_limit
andmerges_memory_usage_soft_limit_to_ram_ratio
similarly to
max_server_memory_usage
andmax_server_memory_usage_to_ram_ratio
. The latter setting should be 0.5 by default.Track the total memory usage by merges.
Caveat: it cannot be done with MemoryTracker. Because a merge operation can free some memory (primary keys) that were allocated outside of the context of the merge, the resulting memory usage at the end of the merge can be negative. We cannot reset it to zero at the end of the merge operation because the MemoryTracker of the merge is attached to the server's global MemoryTracker and should be consistent with it. The only reasonable way is to track the sum of memory usage by active merges separately.
If the current memory usage by merges is higher than the soft limit, do not start new merges.
The text was updated successfully, but these errors were encountered: