[
https://issues.apache.org/jira/browse/HBASE-21657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16736095#comment-16736095
]
stack commented on HBASE-21657:
-------------------------------
[~openinx] Nice graphs. Did you dump the ycsb output into mysql? Nice.
On the v3 patch, there is heap size and serialized size. We need to be careful
distinguishing the two. Can cause issues when comes to sizing around flush
time. The patch equates estimatedSizeOfCell and heapSize. This may be fine but
just need to be careful.
How we get away with adding getSerializedSize to Cell w/o using a default impl?
Otherwise, patch is great (especially the 40% improvement making us more like
1.4 -- interesting that we are just getting back to 1.4 speeds -- though to be
fair, our pipeline is more flexible/complicated now).
bq. But why still 5.6% ? this method just return the length of a cell now,
maybe it's too frequent ...
For sure its just doing this? It is calling through to ExtendedCell.
estimatedSerializedSizeOf in some cases at least. If for all, it maybe
expensive dispatch that is responsible here (figuring what to call in a
complicated hierarchy of Cell-types checking instanceof etc.)
> PrivateCellUtil#estimatedSerializedSizeOf has been the bottleneck in 100%
> scan case.
> ------------------------------------------------------------------------------------
>
> Key: HBASE-21657
> URL: https://issues.apache.org/jira/browse/HBASE-21657
> Project: HBase
> Issue Type: Bug
> Components: Performance
> Reporter: Zheng Hu
> Assignee: Zheng Hu
> Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21657.v1.patch, HBASE-21657.v2.patch,
> HBASE-21657.v3.patch, HBASE-21657.v3.patch,
> HBase1.4.9-ssd-10000000-rows-flamegraph.svg,
> HBase1.4.9-ssd-10000000-rows-qps-latency.png,
> HBase2.0.4-patch-v2-ssd-10000000-rows-qps-and-latency.png,
> HBase2.0.4-patch-v2-ssd-10000000-rows.svg,
> HBase2.0.4-patch-v3-ssd-10000000-rows-flamegraph.svg,
> HBase2.0.4-patch-v3-ssd-10000000-rows-qps-and-latency.png,
> HBase2.0.4-ssd-10000000-rows-flamegraph.svg,
> HBase2.0.4-ssd-10000000-rows-qps-latency.png, HBase2.0.4-with-patch.v2.png,
> HBase2.0.4-without-patch-v2.png, hbase2.0.4-ssd-scan-traces.2.svg,
> hbase2.0.4-ssd-scan-traces.svg, hbase20-ssd-100-scan-traces.svg,
> image-2019-01-07-19-03-37-930.png, image-2019-01-07-19-03-55-577.png,
> overview-statstics-1.png, run.log
>
>
> We are evaluating the performance of branch-2, and find that the throughput
> of scan in SSD cluster is almost the same as HDD cluster. so I made a
> FlameGraph on RS, and found that the
> PrivateCellUtil#estimatedSerializedSizeOf cost about 29% cpu, Obviously, it
> has been the bottleneck in 100% scan case.
> See the [^hbase20-ssd-100-scan-traces.svg]
> BTW, in our XiaoMi branch, we introduce a
> HRegion#updateReadRequestsByCapacityUnitPerSecond to sum up the size of cells
> (for metric monitor), so it seems the performance loss was amplified.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
