Skip to content
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

Reduce thread congestion in HashBuilderOperator #22668

Conversation

losipiuk
Copy link
Member

@losipiuk losipiuk commented Jul 15, 2024

Memory management in HashBuilderOperator.addInput caused significant
thread congestion. When memory tracking accuracy is traded for calling
delegate.setBytes() less frequently, we are getting better performance
for queries which tend to process tiny pages in HashBuilder operator.

Improvement is very much visible in couple TPC-DS queries run in FTE mode.
Queries run on unpartitioned iceberg, sf1000, 8 nodes cluseter.

image

Release notes

(x) This is not user-visible or is docs only, and no release notes are required.
( ) Release notes are required. Please propose a release note for me.
( ) Release notes are required, with the following suggested text:

@wendigo
Copy link
Contributor

wendigo commented Jul 15, 2024

TestHashBuilderOperator.test failure is related.

@losipiuk losipiuk force-pushed the lukaszos/reduce-thread-congestion-in-hashbuilderoperator-f4bee1 branch from 09d6720 to 11c0340 Compare July 15, 2024 09:35
Memory management in HashBuilderOperator.addInput caused significant
thread congestion. When memory tracking accuracy is traded for calling
delegate.setBytes() less frequently, we are getting better performance
for queries which tend to process tiny pages in HashBuilder operator.
@losipiuk losipiuk force-pushed the lukaszos/reduce-thread-congestion-in-hashbuilderoperator-f4bee1 branch from 11c0340 to 32941d5 Compare July 15, 2024 09:58
@losipiuk
Copy link
Member Author

TestHashBuilderOperator.test failure is related.

updated

public class ThresholdLocalMemoryContext
implements LocalMemoryContext
{
public static final long DEFAULT_SYNC_THRESHOLD = 65536;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

somewhere (query context? driver context? don't remember) there is already a similar mechanism, with 1 MB threshold (AFAIR)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is some guaranteed memory somewhere - do you mean this one?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah - there is - but it is handled in the AggregatedMemoryContext in the synchronized section already here.
It is just to ensure we are reuturning non-blocked future. The accounting is still 100% correct - so it does not help with thread congestion.

@losipiuk
Copy link
Member Author

CI: #18697

@losipiuk
Copy link
Member Author

CI: #21736

@losipiuk losipiuk merged commit cae2e9b into trinodb:master Jul 16, 2024
96 checks passed
@github-actions github-actions bot added this to the 453 milestone Jul 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

3 participants