Suraj
thank you very much!
there is another reason :some one keep scanning the table and delete it's
rows!
2010/12/18 Suraj Varma
> Can you check your master.log and see if there is region reassignment
> happening continously? See
> https://issues.apache.org/jira/browse/HBASE-2599and use the p
Hi Suraj Varam
Thank you ! I don't think that is the reason. See below
$ echo $JAVA_HOME
/etc/java-config-2/current-system-vm
$ /etc/java-config-2/current-system-vm/bin/java -version
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM
I also had long GC pauses on G1 when I tried it last summer. Check out
this thread for the gory details:
http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2010-July/000653.html
-Todd
On Sat, Dec 18, 2010 at 10:37 PM, Stack wrote:
> Setting swap to zero is going to an extreme but changing it
Setting swap to zero is going to an extreme but changing it so its not
the default -- 60% IIRC -- could help.
I made HBASE-3376 for the NPE. I'll take a look into it.
Congrats on the 113second G1 pause. I thought G1 was to be the end of
such pauses? (Smile). Its good to hear that its staying
2010-12-18 18:11:00,333 DEBUG
org.apache.hadoop.hbase.regionserver.CompactSplitThread: Compaction
requested for region cjjBeeDocument,\x00\x00\x00\
x00\x00\x0F\xF7x,1292667057185/110111081 because: Region has references on
open
2010-12-18 18:11:00,333 INFO org.apache.hadoop.hbase.regionserver.HRegi
Hey Friso,
> The GC is G1, so it may look different from what you expect
> from a GC log. I know it is considered experimental, but I
> like the concept of it and think it's nice to gain some
> experience with it.
You are probably the first to use the G1 GC seriously with HBase. Would love to
he
Unfortunately this would be quite expensive to implement, that data is not
necessarly at hand when doing a put.
On Dec 18, 2010 10:11 AM, "Claudio Martella"
wrote:
> Hello list,
>
> just two lines for a proposal. Wouldn't it make more sense if put would
> return the old value in case the put ends
I guess what I really want to do is make sure that hbase api calls are
most efficient. The issue is not the front end tcp persistency.
Ryan says:
>> > The multi interface in 0.90 will minimize rpc calls
>> > from the client to the region server. This isn't exposed
>> > in the thrift api but would
Hello list,
just two lines for a proposal. Wouldn't it make more sense if put would
return the old value in case the put ends up being an update instead of
an insert?
This would mimic HashMap's behavior and would be very useful. What do
you think?
--
Claudio Martella
Digital Technologies
Unit Re
Can you check your master.log and see if there is region reassignment
happening continously? See
https://issues.apache.org/jira/browse/HBASE-2599and use the patched
0.20.6 in the last message.
The symptoms seem to indicate this issue.
--Suraj
On Fri, Dec 17, 2010 at 11:05 PM, 陈加俊 wrote:
> HBase
Check your JAVA_HOME settings - I suspect an older JRE is being picked up.
HBase needs at least JRE 1.6 ...
--Suraj
On Sat, Dec 18, 2010 at 2:12 AM, 陈加俊 wrote:
> Strange, suddenly shell cannot use！
>
> errors:
>
> bin/hbase shell
> ClassLoader.java:-2:in `defineClass1': java.lang.ClassFormatErro
Strange, suddenly shell cannot use！
errors:
bin/hbase shell
ClassLoader.java:-2:in `defineClass1': java.lang.ClassFormatError: Unknown
constant tag 26 in class file
org/jruby/RubyIO$s_method_multi$RUBYINVOKER$read
from ClassLoader.java:632:in `defineClassCond'
from ClassLoader.jav
Hi J-D,
I redid the job as before to once more verify. The real problem appears to be
something I had not noticed, because I never expected it. The machines started
swapping during the job. I did not expect that, because there is a total of
about 45GB heap allocated on a 64GB machine and nothin
13 matches
Mail list logo
