[
https://issues.apache.org/jira/browse/HDDS-9668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787553#comment-17787553
]
Duong edited comment on HDDS-9668 at 11/19/23 2:17 AM:
-------------------------------------------------------
I made an implementation and tested it out in an internal cluster with 16
datanodes, each equipped with 10 NVMe disks for data, using warp. Below are
some details:
# The zero-copy solution increases EC write I/O by {*}18%{*}. I think after
zero-copy, I hit another bottleneck in S3 and the improvement could be indeed
higher. Please see the bottom of this comment for test result details.
!ec-dn-io-comparison.png|width=1801,height=305!
# JVM metrics show a much lower GC footprint and significantly less CPU
utilization for zero-copy.
!ec_jvm_metric_comparison.png|width=705,height=605!
In conclusion, as we avoid buffer copy cost and its consequences to GC, we can
increase EC write performance while using less CPU power. All of those are
shown in the profiler [^datanode-on-write-ec-zerocopies.html].
Warp test details:
{code:java}
WARP command:
warp put --warp-client=x.x.x.{1...16} --host=localhost:9879 --tls --insecure
--access-key=<accessKey> --secret-key=<secretKey> --obj.size=64mb
--concurrent=40 --bucket bucket-obs --duration 10m --noclear
1. EC baseline (with buffer copies)
----------------------------------------
Operation: PUT
* Average: 20855.62 MiB/s, 341.70 obj/sThroughput, split into 104 x 5s:
* Fastest: 25.10GiB/s, 421.06 obj/s
* 50% Median: 23.78GiB/s, 399.00 obj/s
* Slowest: 1891.7MiB/s, 30.99 obj/s
2. EC zerocopy
----------------------------------------
Operation: PUT
* Average: 24612.08 MiB/s, 403.24 obj/sThroughput, split into 118 x 5s:
* Fastest: 26.73GiB/s, 448.39 obj/s
* 50% Median: 25.59GiB/s, 429.37 obj/s
* Slowest: 8261.7MiB/s, 135.36 obj/s {code}
was (Author: JIRAUSER290990):
I made an implementation and tested it out in an internal cluster with 16
datanodes, each equipped with 10 NVMe disks for data, using warp. Below are
some details:
# The zero-copy solution increases EC write I/O by {*}18%{*}. I think after
zero-copy, I hit another bottleneck in S3 and the improvement could be indeed
higher. Please see the bottom of this comment for test result details.
!ec-dn-io-comparison.png|width=1801,height=305!
# JVM metrics show a much lower GC footprint and significantly less CPU
utilization for zero-copy.
!ec_jvm_metric_comparison.png|width=705,height=605!
In conclusion, as we avoid buffer copy cost and its consequences to GC, we can
increase EC write performance while using less CPU power.
Warp test details.
{code:java}
WARP command:
warp put --warp-client=x.x.x.{1...16} --host=localhost:9879 --tls --insecure
--access-key=<accessKey> --secret-key=<secretKey> --obj.size=64mb
--concurrent=40 --bucket bucket-obs --duration 10m --noclear
1. EC baseline (with buffer copies)
----------------------------------------
Operation: PUT
* Average: 20855.62 MiB/s, 341.70 obj/sThroughput, split into 104 x 5s:
* Fastest: 25.10GiB/s, 421.06 obj/s
* 50% Median: 23.78GiB/s, 399.00 obj/s
* Slowest: 1891.7MiB/s, 30.99 obj/s
2. EC zerocopy
----------------------------------------
Operation: PUT
* Average: 24612.08 MiB/s, 403.24 obj/sThroughput, split into 118 x 5s:
* Fastest: 26.73GiB/s, 448.39 obj/s
* 50% Median: 25.59GiB/s, 429.37 obj/s
* Slowest: 8261.7MiB/s, 135.36 obj/s {code}
> Zero-Copy in EC GRPC (write)
> ----------------------------
>
> Key: HDDS-9668
> URL: https://issues.apache.org/jira/browse/HDDS-9668
> Project: Apache Ozone
> Issue Type: Improvement
> Reporter: Duong
> Assignee: Duong
> Priority: Major
> Labels: pull-request-available
> Attachments: datanode-on-write-ec-ncopies.html,
> datanode-on-write-ec-zerocopies.html, datanode_write_ratis_0copy.html,
> ec-dn-io-comparison.png, ec-ncopies.png, ec_jvm_metric_comparison.png
>
>
> Today EC with GRPC copies input data buffer several times:
> * when parsing protobuf objects from the input network stream, data is
> copied from the original netty direct buffer to heap.
> * when writing data to files, the heap buffer needs to be copied to direct
> buffers by NIO.
> The cost of buffer copies themself is inefficient, it comes with GC
> consequences of cleaning up the intermediate buffers. Those together slow EC
> I/O down.
> !ec-ncopies.png|width=807,height=292!
> We can use the ZeroCopyMarshaller from RATIS-1932 to avoid all those issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
