[
https://issues.apache.org/jira/browse/HBASE-13903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14587266#comment-14587266
]
Duo Zhang commented on HBASE-13903:
-----------------------------------
What about just use a StripedLock and give each stripe an individual HashMap?
ConcurrentHashMap is fast because it does not require locking when getting
entry from map at most time, but here we use putIfAbsent which will always lock
a segment.
And for the profiling result, is lots of 'time' or lots of 'cpu' spent in
IdLock? This is important. If we spent lots of time waiting a lock, then the
problem is contention, not the implementation of IdLock.
Thanks.
> Speedup IdLock
> --------------
>
> Key: HBASE-13903
> URL: https://issues.apache.org/jira/browse/HBASE-13903
> Project: HBase
> Issue Type: Improvement
> Components: regionserver
> Affects Versions: 2.0.0, 1.0.1, 1.1.0, 0.98.13
> Reporter: Matteo Bertozzi
> Assignee: Matteo Bertozzi
> Priority: Minor
> Fix For: 2.0.0, 1.2.0
>
> Attachments: HBASE-13903-v0.patch, IdLockPerf.java
>
>
> while testing the read path, I ended up with the profiler showing a lot of
> time spent in IdLock.
> The IdLock is used by the HFileReader and the BucketCache, so you'll see a
> lot of it when you have an hotspot on a hfile.
> we end up locked by that synchronized() and with too many calls to
> map.putIfAbsent()
> {code}
> public Entry getLockEntry(long id) throws IOException {
> while ((existing = map.putIfAbsent(entry.id, entry)) != null) {
> synchronized (existing) {
> ...
> }
> // If the entry is not locked, it might already be deleted from the
> // map, so we cannot return it. We need to get our entry into the map
> // or get someone else's locked entry.
> }
> }
> public void releaseLockEntry(Entry entry) {
> synchronized (entry) {
> ...
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
