hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiroshi Ikeda (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-14268) Improve KeyLocker
Date Fri, 04 Sep 2015 10:12:45 GMT

     [ https://issues.apache.org/jira/browse/HBASE-14268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Hiroshi Ikeda updated HBASE-14268:
    Attachment: KeyLockerIncrKeysPerformance.java

Added a performance application. This application gets new lock at all time. The outputs in
my environment are as follows.

The new KeyLocker is not appropriate for creating continuously new locks that are rarely needed
to exclusively control, as sort of insurance for a rainy day.

I said that is because weak references may require several GC, but I also think that garbage-collecting
WeakReference objects removed from the reference queue is accompanied with adding new WeakReference
objects to the reference queue, and the memory usage doesn't reduce and may affect the performance.

new KeyLocker
[GC 33280K->26277K(124928K), 0.0315760 secs]
[GC 59557K->51803K(158208K), 0.0411313 secs]
[GC 118363K->113643K(180736K), 0.0674596 secs]
[Full GC 113643K->71099K(261632K), 0.4572814 secs]
[GC 137659K->135131K(283648K), 0.0830925 secs]
[Full GC 135131K->49669K(310272K), 0.2595013 secs]
[GC 138245K->135781K(339968K), 0.1358634 secs]
[Full GC 135781K->63914K(410624K), 0.2819740 secs]
[GC 182186K->142186K(500736K), 0.1859324 secs]
[GC 254826K->162474K(506368K), 0.1923356 secs]
[GC 275114K->162410K(520704K), 0.1829767 secs]
[GC 279658K->165386K(520704K), 0.1820236 secs]
[GC 282634K->165498K(520704K), 0.1829841 secs]
[GC 282746K->165498K(520704K), 0.1720680 secs]
[GC 282746K->165466K(520704K), 0.1829380 secs]
[GC 282714K->165514K(520704K), 0.1885966 secs]
[GC 282762K->165498K(517632K), 0.1889385 secs]

old KeyLocker
[GC 33280K->776K(124928K), 0.0016239 secs]
[GC 34056K->669K(124928K), 0.0014578 secs]
[GC 33949K->717K(124928K), 0.0012017 secs]
[GC 33997K->669K(158208K), 0.0011863 secs]
[GC 67229K->669K(158208K), 0.0019523 secs]
[GC 67229K->669K(220672K), 0.0011686 secs]
[GC 133789K->650K(220672K), 0.0018851 secs]
[GC 133770K->650K(353792K), 0.0005309 secs]
[GC 266890K->650K(353792K), 0.0008266 secs]
[GC 266890K->650K(434176K), 0.0007151 secs]
[GC 347274K->618K(418304K), 0.0004791 secs]

> Improve KeyLocker
> -----------------
>                 Key: HBASE-14268
>                 URL: https://issues.apache.org/jira/browse/HBASE-14268
>             Project: HBase
>          Issue Type: Improvement
>          Components: util
>            Reporter: Hiroshi Ikeda
>            Assignee: Hiroshi Ikeda
>            Priority: Minor
>             Fix For: 2.0.0, 1.3.0
>         Attachments: 14268-V5.patch, HBASE-14268-V2.patch, HBASE-14268-V3.patch, HBASE-14268-V4.patch,
HBASE-14268-V5.patch, HBASE-14268-V5.patch, HBASE-14268-V6.patch, HBASE-14268-V7.patch, HBASE-14268-V7.patch,
HBASE-14268.patch, KeyLockerIncrKeysPerformance.java, KeyLockerPerformance.java
> 1. In the implementation of {{KeyLocker}} it uses atomic variables inside a synchronized
block, which doesn't make sense. Moreover, logic inside the synchronized block is not trivial
so that it makes less performance in heavy multi-threaded environment.
> 2. {{KeyLocker}} gives an instance of {{RentrantLock}} which is already locked, but it
doesn't follow the contract of {{ReentrantLock}} because you are not allowed to freely invoke
lock/unlock methods under that contract. That introduces a potential risk; Whenever you see
a variable of the type {{RentrantLock}}, you should pay attention to what the included instance
is coming from.

This message was sent by Atlassian JIRA

View raw message