-
Notifications
You must be signed in to change notification settings - Fork 3.7k
[improvement](memory) disable page cache and chunk allocator, optimize memory allocate size #13285
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
Conversation
|
Gives the performance impact of |
|
If want to discard the doris application layer cache. what is the replacement method? There are more application layer caches in doris, such as segment cache. I think a self-managed application layer cache is necessary. |
|
Maybe we can discuss the idea of subsequent cache optimization~, I mentioned a proposal a long time ago |
Doris's memory usage is not very stable, I want to disable them first, and try to fix other memory problems and then open them again. This may need about 2 months and there are many releases during this stage, so that I disable them like we have done in branch 1.1-lts. |
I agree, Later we can find a time to talk about the use of the cache |
8b7d928 to
95f4830
Compare
| return Status::InternalError(ss.str()); | ||
| } | ||
| chunk_reserved_bytes_limit = | ||
| BitUtil::RoundDown(chunk_reserved_bytes_limit, config::min_chunk_reserved_bytes); |
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.
The BitUtil::RoundDown(chunk_reserved_bytes_limit, 4096) here ensures that chunk_reserved_bytes_limit is a multiple of 4096
4096 is the minimum chunk size currently allocated by the chunk allocator
A separate conf min_chunk_reserved_bytes is not necessary, but RoundDown is meaningful
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.
yes ... I will move back min_chunk_reserved_bytes
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.
can remove min_chunk_reserved_bytes, const 4096 is fine, the user will not modify it
This knowledge suggests~
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.
OK, I remove it.
| /// Not round up, keep the size just as the application pass in like std::vector | ||
| void alloc_for_num_elements(size_t num_elements) { | ||
| alloc(round_up_to_power_of_two_or_zero(minimum_memory_for_elements(num_elements))); | ||
| alloc(minimum_memory_for_elements(num_elements)); |
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.
Allocating in powers of 2 has a positive impact on performance, if you wish to reduce memory usage,
join #ifndef STRICT_MEMORY_USE, similar to hash_table.h expansion
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.
I do not think this should be a config, because if it is a config, we do not know when to open the config since it is a macro. Actually, there are two types of memory allocation in PODArray:
- reserve, sometimes the developer know the expected size of the array, then he should call reserve method to allocate the EXPECTED memory.
- push_back, the developer does not know the expected size of the array, then he just call push back to allocate memory. In this scenario, we should allocate memory using power of 2.
For most cases, we should reserve or resize memory size before push back, then we could reduce memory reallocation or memory copy.
This PR try to fix some problems. #13088.
| CONF_Int32(min_chunk_reserved_bytes, "1024"); | ||
|
|
||
| // Whether using chunk allocator to cache memory chunk | ||
| CONF_Bool(disable_chunk_allocator, "true"); |
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.
disable_chunk_allocator_in_mem_pool
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.
No, I will remove mempool after we removed non-vectorized engine. MemPool is used as MemPool.cpp, it is like a arena. The config disable_mem_pools is also very confused. I will remove them.
| DCHECK(chunk.core_id != -1); | ||
| CHECK((chunk.size & (chunk.size - 1)) == 0); | ||
| if (config::disable_mem_pools) { | ||
| if (config::disable_chunk_allocator) { |
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.
Is it better to move the condition into MemPool and rename disable_chunk_allocator_in_mem_pool, Similar to disable_chunk_allocator_in_vec
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.
Not use this. I will remove disable_mem_pools in the future after non-vectorized engine is removed. It is very confused with MemPool.
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.
Try removing disable_chunk_allocator_in_vec and replace with disable_chunk_allocator. (more detailed config comments)
e906afb to
eb659d1
Compare
eb659d1 to
f8ad6c0
Compare
xinyiZzz
left a comment
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.
LGTM
|
PR approved by at least one committer and no changes requested. |
|
PR approved by anyone and no changes requested. |
… optimize memory allocate size (apache#13285)" This reverts commit a5f3880.
… optimize memory allocate size (apache#13285)" This reverts commit a5f3880.
… optimize memory allocate size (apache#13285)" This reverts commit a5f3880.
Proposed changes
Problem summary
Describe your changes.
Checklist(Required)
Further comments
If this is a relatively large or complex change, kick off the discussion at dev@doris.apache.org by explaining why you chose the solution you did and what alternatives you considered, etc...