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
Summary:
When decreasing temptable_max_ram system variable, I am not
seeing decrease in memory when running workloads.
create_tmp_table is still taking significant amount of memory in
temptable APIs. This is because temptable_max_ram limit does not
apply to shared block. The shared block is a TLS variable. In
multithreaded environment, this takes a significant amount of
memory (>150 MB). The shared block is unconditionally allocated from
RAM. Also the shared_block is never deallocated once allocated in a
thread.
The fix introduces a system variable temptable_track_shared_block_ram.
When enabled, the shared block memory allocation is also tracked.
This tracking enables shared block to be allocated from mmap files
in case the total allocated memory by temptable exceeds
temptable_max_ram. Also with the fix, shared_block is deallocated
after all the chunks are destroyed. This allows us to reclaim memory
space more proactively.
With this fix, I am seeing savings of >150 MB in our workloads.
Reviewed By: yizhang82
Differential Revision: D27520132
0 commit comments