[ 
https://issues.apache.org/jira/browse/HBASE-22412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16874107#comment-16874107
 ] 

Hudson commented on HBASE-22412:
--------------------------------

Results for branch branch-2
        [build #2029 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/2029/]: 
(x) *{color:red}-1 overall{color}*
----
details (if available):

(x) {color:red}-1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/2029//General_Nightly_Build_Report/]




(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/2029//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/2029//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


(/) {color:green}+1 client integration test{color}


> Improve the metrics in ByteBuffAllocator
> ----------------------------------------
>
>                 Key: HBASE-22412
>                 URL: https://issues.apache.org/jira/browse/HBASE-22412
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Zheng Hu
>            Assignee: Zheng Hu
>            Priority: Major
>         Attachments: HBASE-22412.HBASE-21879.v1.patch, 
> HBASE-22412.HBASE-21879.v2.patch, HBASE-22412.HBASE-21879.v3.patch, JMX.png, 
> web-UI.png
>
>
> gAddress the comment in HBASE-22387: 
> bq. The ByteBuffAllocator#getFreeBufferCount will be O(N) complexity, because 
> the buffers here is an ConcurrentLinkedQueue. It's worth file an issue for 
> this.
> Also I think we should use the allcated bytes instead of allocation number to 
> evaluate the heap allocation percent , so that we can decide whether the 
> ByteBuffer is too small and whether will have higher GC pressure.  Assume the 
> case:  the buffer size is 64KB, and each time we have a block with 65KB, then 
> it will have one heap allocation (1KB) and one pool allocation (64KB), if 
> only consider the allocation num, then the heap allocation ratio will be 1 / 
> (1 + 1) = 50%, but if consider the allocation bytes, the allocation ratio 
> will be  1KB / 65KB = 1.5%.
> If the heap allocation percent is less than  
> hbase.ipc.server.reservoir.minimal.allocating.size /  
> hbase.ipc.server.allocator.buffer.size,  then the allocator  works fine, 
> otherwise it's overload. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to