-
Notifications
You must be signed in to change notification settings - Fork 154
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] Set Netty as the default server type #1651
Comments
rickyma
added a commit
to rickyma/incubator-uniffle
that referenced
this issue
Apr 17, 2024
rickyma
added a commit
to rickyma/incubator-uniffle
that referenced
this issue
Apr 17, 2024
rickyma
added a commit
to rickyma/incubator-uniffle
that referenced
this issue
Apr 17, 2024
rickyma
added a commit
to rickyma/incubator-uniffle
that referenced
this issue
Apr 17, 2024
rickyma
added a commit
to rickyma/incubator-uniffle
that referenced
this issue
Apr 17, 2024
Closed
3 tasks
3 tasks
rickyma
added a commit
to rickyma/incubator-uniffle
that referenced
this issue
Jul 17, 2024
rickyma
added a commit
to rickyma/incubator-uniffle
that referenced
this issue
Jul 17, 2024
rickyma
added a commit
to rickyma/incubator-uniffle
that referenced
this issue
Jul 17, 2024
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Code of Conduct
Search before asking
What would you like to be improved?
After #1650, we can know that gRPC mode will not perform very well under high pressure. I think it's time for us to set the default server type to Netty, based on the following reasons.
Netty mode brings about a 20% performance improvement compared to gRPC mode
Refer to https://github.com/apache/incubator-uniffle/blob/master/docs/benchmark_netty_case_report.md.
gRPC mode will cause higher CPU load
We can see that gRPC mode will cause the machine's load to be much higher than Netty mode:

gRPC mode will cause memory usage to double
We will find that in gRPC mode, both off-heap and on-heap memory may be heavily occupied. In extreme cases, this may cause memory usage to double:

This is because gRPC enables off-heap memory by default, and this part of the memory will be allocated and used by the gRPC framework. When the request enters the
ShuffleServerGrpcService
method, this part of the memory will be converted into on-heap memory and used in the business code. However, this is completely unnecessary, as we can simply use either off-heap memory or on-heap memory, without the need for conversion.gRPC mode will cause inaccurate
usedMemory
leading to OOMgRPC enables off-heap memory by default, and this part of the memory will be allocated and used by the gRPC framework, which is not calculated in
usedMemory
.By default, gRPC uses PooledByteBufAllocator to allocate off-heap memory for requests, with a chunkSize of 2MB. Therefore, when doing pre-allocation, it will also require allocating 2MB of off-heap memory. So in high-pressure and high-concurrency scenarios, we may easily encounter the following error exceptions when the shuffle server is receiving plenty of
SendShuffleDataRequest
andRequireBufferRequest
at the same time:gRPC does not support sending
ByteString
using off-heap memoryRefer to grpc/grpc-java#9704.
More flexible
Using Netty is more direct and flexible, and it won't be constrained by the gRPC layer's wrapping.
Netty's iterative upgrades will be faster
Netty's iterative upgrades will be faster, and the gRPC community cannot guarantee timely updates to Netty's version.
So I think it's time for us to set the default server type to Netty.
How should we improve?
Tasks:
Are you willing to submit PR?
The text was updated successfully, but these errors were encountered: