-
Notifications
You must be signed in to change notification settings - Fork 151
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
[Improvement] Fine-grained memory control for spark client #706
Comments
And I also find that some apps in our production failed due to requiring memory failed, but it works well with ESS, although the available memory is less in ESS. |
Ok for me. |
And the available memory is tight, could we support append record to temp files and at the final step, send them to remote shuffle-server, rather than using memory to hold them. |
### What changes were proposed in this pull request? 1. Introduce the `DataPusher` to replace the `eventLoop`, this could be as general part for spark2 and spark3. 2. Implement the `spill` method in `WriterBufferManager` to avoid memory deadlock. ### Why are the changes needed? In current codebase, if having several `WriterBufferManagers`, when each other is acquiring memory, the deadlock will happen. To solve this, we should implement spill function to break this deadlock condition. Fix: #706 ### Does this PR introduce _any_ user-facing change? No. ### How was this patch tested? 1. Existing UTs 2. Newly added UTs
…che#714) ### What changes were proposed in this pull request? 1. Introduce the `DataPusher` to replace the `eventLoop`, this could be as general part for spark2 and spark3. 2. Implement the `spill` method in `WriterBufferManager` to avoid memory deadlock. ### Why are the changes needed? In current codebase, if having several `WriterBufferManagers`, when each other is acquiring memory, the deadlock will happen. To solve this, we should implement spill function to break this deadlock condition. Fix: apache#706 ### Does this PR introduce _any_ user-facing change? No. ### How was this patch tested? 1. Existing UTs 2. Newly added UTs
…ock (apache#714)" This reverts commit 1b48c12.
…ock (apache#714)" This reverts commit 1b48c12.
Code of Conduct
Search before asking
What would you like to be improved?
memoryConsumer
when fetching remote data, especially for after supporting async read. [FEATURE] Async Reader #291How should we improve?
No response
Are you willing to submit PR?
The text was updated successfully, but these errors were encountered: