hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guilherme Germoglio <germog...@gmail.com>
Subject Re: Problems when executing many (?) HTable.lockRow()
Date Sat, 09 May 2009 23:47:27 GMT
But with 200 threads, the problem is back. =\

On Sat, May 9, 2009 at 8:44 PM, Guilherme Germoglio <germoglio@gmail.com>wrote:

> maybe you've just spotted the problem! I've raised
> hbase.regionserver.handler.count to 100 and the threads are now executing
> much faster! When 20 are running, they take about 80~90 ms each.
>
>
> On Sat, May 9, 2009 at 8:36 PM, Ryan Rawson <ryanobjc@gmail.com> wrote:
>
>> if we had a compare and set operation would this help you?
>>
>> Another thing, normally hbase regionserver only runs 10 ipc handler
>> threads... I'm not sure how relevant or important this is yet. Holding a
>> row
>> open should not tie up an ipc thread though.
>>
>> On May 9, 2009 4:19 PM, "Guilherme Germoglio" <germoglio@gmail.com>
>> wrote:
>>
>> Hey Ryan,
>>
>> Thank for such a quick response!
>>
>> The log is here: http://germoglio.googlepages.com/log.zip Unfortunately,
>> I
>> wasn't running with debug on. I'll do it tomorrow in order to get more
>> data
>> (Will I be able to find how to turn on debug in the mailing list archives
>> or
>> in hbase wiki?). Also, you will notice that the log is only from the
>> master
>> server. The reason for this is that I'm running on the pseudodistributed
>> mode and the region server log has only one message "2009-05-09
>> 19:04:26,242
>> WARN org.apache.hadoop.hbase.regionserver.HRegionServer: Not starting a
>> distinct region server because hbase.master is set to 'local' mode".
>>
>> Thank you for the advice. I understand that a simple put doesn't make
>> sense
>> to lock a row. However, I'm just considering the performance of it. If the
>> put operation into a single row (which I think is the fastest operation)
>> isn't fast enough for my project, I'll not even try what I'm really
>> intending to do, which is atomically getting a value, modifying it (not
>> necessarily incrementing it), and then putting it back to the table.
>>
>> I wasn't expecting great performance either, but is it ok to execute a
>> single put into a locked row in 5~10 minutes?
>>
>> On Sat, May 9, 2009 at 7:54 PM, Ryan Rawson <ryanobjc@gmail.com> wrote: >
>> Hey Guilherme, > > We'd ...
>> --
>>
>> Guilherme msn: guigermoglio@hotmail.com homepage:
>> http://germoglio.googlepages.com
>>
>
>
>
> --
> Guilherme
>
> msn: guigermoglio@hotmail.com
> homepage: http://germoglio.googlepages.com
>



-- 
Guilherme

msn: guigermoglio@hotmail.com
homepage: http://germoglio.googlepages.com

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