hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Helmling <ghelml...@gmail.com>
Subject Re: Coprocessor tax?
Date Tue, 01 Mar 2011 22:52:09 GMT
Created HBASE-3587: https://issues.apache.org/jira/browse/HBASE-3587

<https://issues.apache.org/jira/browse/HBASE-3587>Please comment/correct if
I left anything out or summed it up wrong.


On Tue, Mar 1, 2011 at 12:59 PM, Gary Helmling <ghelmling@gmail.com> wrote:

> Sure, even better (it's doing the locking for you).
>
>
> On Tue, Mar 1, 2011 at 12:49 PM, Ryan Rawson <ryanobjc@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" <ghelmling@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 you say, there is still a race in HRegion.doClose() between
>> > preClose() completing and HRegion.lock.writeLock() being taken out, so
>> other
>> > methods could still be called after.
>> >
>> > RegionCoprocessorHost.postClose() occurs under the HRegion write lock,
>> so
>> > any read lock operations would already have to have completed by this
>> point.
>> > So here we wouldn't really need the coprocessor write lock either?
>> >
>> > It seems like we could actually drop the coprocessor lock, since
>> > coprocessors are currently loaded prior to region open completing.
>> >
>> > Online coprocessor loading (not currently provided) could be handled in
>> the
>> > future by a lock just for loading, and creating a new coprocessor
>> collection
>> > and assigning when done.
>> >
>> > On Tue, Mar 1, 2011 at 12:08 PM, Ryan Rawson <ryanobjc@gmail.com>
>> wrote:
>> >
>> >> My own profiling shows that a read write lock can be up to 3-6% of the
>> >> CPU budget in our put/get query path. Adding another one if not
>> >> necessary would probably not be good.
>> >>
>> >> In fact in the region coprocessor the only thing the write lock is
>> >> used for is the preClose and postClose, but looking in the
>> >> implementation of those methods I don't really get why this is
>> >> necessary. The write lock ensures single thread access, but there is
>> >> nothing that prevents other threads from calling other methods AFTER
>> >> the postClose?
>> >>
>> >> -ryan
>> >>
>> >> On Tue, Mar 1, 2011 at 12:02 PM, Gary Helmling <ghelmling@gmail.com>
>> >> wrote:
>> >> > All the CoprocessorHost invocations should be wrapped in "if (cpHost
>> !=
>> >> > null)". We could just added an extra check for whether any
>> coprocessors
>> >> are
>> >> > loaded -- "if (cpHost != null && cpHost.isActive())", something
like
>> >> that?
>> >> > Or the CoprocessorHost methods could do this checking internally.
>> >> >
>> >> > Either way should be relatively easy to bypass the lock acquisition.
>> Is
>> >> > there much overhead to acquiring a read lock if the write lock is
>> never
>> >> > taken though? (just wondering)
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Mar 1, 2011 at 11:51 AM, Stack <stack@duboce.net> wrote:
>> >> >
>> >> >> 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=0x00000000422d2800
>> >> >> nid=0x7714 runnable [0x00007f1c5acea000]
>> >> >> java.lang.Thread.State: RUNNABLE
>> >> >> at
>> >> >>
>> >>
>> java.util.concurrent.locks.ReentrantReadWriteLock$Sync.fullTryAcquireShared(ReentrantReadWriteLock.java:434)
>> >> >> at
>> >> >>
>> >>
>> java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryAcquireShared(ReentrantReadWriteLock.java:404)
>> >> >> at
>> >> >>
>> >>
>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1260)
>> >> >> at
>> >> >>
>> >>
>> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:594)
>> >> >> at
>> >> >>
>> >>
>> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.prePut(RegionCoprocessorHost.java:532)
>> >> >> at
>> >> >>
>> >>
>> org.apache.hadoop.hbase.regionserver.HRegion.doMiniBatchPut(HRegion.java:1476)
>> >> >> at
>> >> >> org.apache.hadoop.hbase.regionserver.HRegion.put(HRegion.java:1454)
>> >> >> at
>> >> >>
>> >>
>> org.apache.hadoop.hbase.regionserver.HRegionServer.multi(HRegionServer.java:2652)
>> >> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> >> >> at
>> >> >>
>> >>
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> >> >> at
>> >> >>
>> >>
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> >> >> at java.lang.reflect.Method.invoke(Method.java:597)
>> >> >> at
>> >> >>
>> >>
>> org.apache.hadoop.hbase.ipc.WritableRpcEngine$Server.call(WritableRpcEngine.java:309)
>> >> >> at
>> >> >>
>> >>
>> org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1060)
>> >> >>
>> >> >>
>> >> >> Do others? I don't have any CPs loaded. I'm wondering if we can
do
>> >> >> more to just avoid the CP codepath if no CPs loaded.
>> >> >>
>> >> >> St.Ack
>> >> >>
>> >> >
>> >>
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message