st...@duboce.net
Subject: Coprocessor tax?
To: HBase Dev List dev@hbase.apache.org
Date: Tuesday, March 1, 2011, 11:51 AM
So, I'm debugging something else but
thread dumping I see a bunch of this:
IPC Server handler 6 on 61020 daemon prio=10
tid=0x422d2800
nid=0x7714 runnable
Looking at the source of
ReentrantReadWriteLock$Sync#tryAcquireShared(), contention on shared
lock acquisition is a little expensive. It's basically equally as
expensive as doing an atomic-increment on a contended counter.
Basically the lock is a bit-field with the top 16 bits being a shared
, 3/1/11, Ryan Rawson ryano...@gmail.com wrote:
From: Ryan Rawson ryano...@gmail.com
Subject: Re: Coprocessor tax?
To: dev@hbase.apache.org
Cc: Gary Helmling ghelml...@gmail.com
Date: Tuesday, March 1, 2011, 12:08 PM
My own profiling shows that a read write lock can be up to 3-6% of the
CPU
Yeah, I was just looking at the write lock references as well.
I'm not sure RegionCoprocessorHost.preClose() would really need the write
lock? As you say, there is still a race in HRegion.doClose() between
preClose() completing and HRegion.lock.writeLock() being taken out, so other
methods could
I don't think we need a lock even for updating, check it copy on write array
list.
On Mar 1, 2011 12:45 PM, Gary Helmling ghelml...@gmail.com wrote:
Yeah, I was just looking at the write lock references as well.
I'm not sure RegionCoprocessorHost.preClose() would really need the write
lock? As
Sure, even better (it's doing the locking for you).
On Tue, Mar 1, 2011 at 12:49 PM, Ryan Rawson ryano...@gmail.com wrote:
I don't think we need a lock even for updating, check it copy on write
array list.
On Mar 1, 2011 12:45 PM, Gary Helmling ghelml...@gmail.com wrote:
Yeah, I was just
Created HBASE-3587: https://issues.apache.org/jira/browse/HBASE-3587
https://issues.apache.org/jira/browse/HBASE-3587Please comment/correct if
I left anything out or summed it up wrong.
On Tue, Mar 1, 2011 at 12:59 PM, Gary Helmling ghelml...@gmail.com wrote:
Sure, even better (it's doing the
