In case you haven't yet heard, hbasecon2013 was announced today [1]. The
call for speakers is open so please consider giving a talk on anything that
falls within the pull of the hbase planet. We (your lovely hbasecon2013
program committee listed along the bottom of [1]), would love to have you.
I
>From some of their presentations, I've gathered that they implement
B-Tree's instead of LSM's on top of their file system which allows random
writes. They also claim that they are converting random mutation requests
to the B-Tree leafs to sequential-writes. They are also talking about
mini-WALs to
Hi,
Maybe you can implement a SplitAlgorithm, and use the RegionSplitter
utility. You can find some information about the usage of SplitAlgorithm
here:
http://hortonworks.com/blog/apache-hbase-region-splitting-and-merging/
Enis
On Tue, Feb 19, 2013 at 11:11 PM, Farrokh Shahriari <
mohandes.zebe
How does avoid memory hogging the region server when multiple queries with
group by are executed, which is done in Hbase jvm. I know that Hbase does
not handle well when heap space is set beyond 12G, and combined with
compactions happening concurrently with queries, it creates a memory
competition.
Another good point.
Warm Regards,
Tariq
https://mtariq.jux.com/
cloudfront.blogspot.com
On Fri, Feb 22, 2013 at 3:45 AM, Asaf Mesika wrote:
> An easier way is to place one byte before the time stamp which is called a
> bucket. You can calculate it by using modulu on the time stamp by the
> num
An easier way is to place one byte before the time stamp which is called a
bucket. You can calculate it by using modulu on the time stamp by the
number of buckets. We are now in the process of field testing it.
On Tuesday, February 19, 2013, Paul van Hoven wrote:
> Yeah it worked fine.
>
> But a
I already fixed this script to make it working mid last year, we used it in our
production since. Also we don't need to run hbck -fix afterwards. The script
works for both 92 and 94. I will publish my patch.
Thanks
Tian-Ying
-Original Message-
From: Harsh J [mailto:ha...@cloudera.co
Bryan:
Just want to confirm. Your fix (resetting) is put into the following method:
/**
* Filters that are purely stateless and do nothing in their reset()
methods can inherit
* this null/empty implementation.
*
* @inheritDoc
*/
@Override
public void reset() {
Thanks
On Thu,
Hi Tian-Ying,
If the need is urgent, try out the solution from Shrijeet at
https://issues.apache.org/jira/browse/HBASE-643 (see my comment there
at around end). We tried it out earlier today for another purpose, and
it had a few hitches but nothing unfixable by "hbck -fix".
On Thu, Feb 21, 2013 a
Our customers need to use rename_table to solve an issue in our production
cluster. Since 92 does not have it, we copied it from CDH3. However it does not
work. I then found several issues with it, and fixed them. We used it in our
production cluster to rename some very big tables. Even when the
I think that if your intention is to do some kind of scan filtering on the
server side then maybe an EndPoint coprocessor would be more fitting.
You can iterate over the InternalScanner and return a Map<> with your
filtered values.
You can also check this link:
http://hbase-coprocessor-experiments
What is this filtering at client side doing exactly?
postScannerClose() wont deal with any scanned data. This hook will be
called later.. You should be using hooks with scanner's next calls. Mind
telling the exact thing you are doing now at client side. Then we might be
able to suggest some thin
:( I saw 0.96 instead of 0.90 :(
So then I will agre with Anoop's comment on HBASE-7893.
Sorry.
JM
2013/2/21 ramkrishna vasudevan
> Hi JM
>
> As per the fix versions it is fixed even in 0.90 version. So it is
> available in the version that Pranav is currently using.
>
> Regards
> Ram
>
> On
Hi JM
As per the fix versions it is fixed even in 0.90 version. So it is
available in the version that Pranav is currently using.
Regards
Ram
On Thu, Feb 21, 2013 at 8:58 PM, Jean-Marc Spaggiari <
jean-m...@spaggiari.org> wrote:
> Hi Pranav,
>
> I don't think this feature is available on the v
Just asking, how did you confirm major compaction is happening?
>From logs or the UI indicated every 24 hrs that major compaction is going
on?
Regards
Ram
On Thu, Feb 21, 2013 at 3:21 PM, Pranav Sharma wrote:
> Hi,
>
> For disabling auto major compaction, I configured
> hbase.hregion.majorcompac
Hi Pranav,
I don't think this feature is available on the versino you are using:
https://issues.apache.org/jira/browse/HBASE-2559
It seems to be available only in trunk for now.
You night want to request this to be applied in 0.94.x branch too, or apply
it manually yourself.
JM
2013/2/21 Prana
Hi,
For disabling auto major compaction, I configured
hbase.hregion.majorcompaction = 0 in the config file and restarted the
cluster. In spite of this, major compaction continues to run everyday. Here
is the config I set:
hbase.hregion.majorcompaction
0
What other way can I disable auto major
Hello again,
I've used PostScannerClose Regionobserver as the hbase book (Definitive
Guide) says,but it doesn't seem worked.And I noticed that the
PostScannerClose doesn't return any value like result.
In fact,I just wanna doing a simple job as described below:
Up to now,I've used a scanner to filt
Logged this issue[1] to have the change made.
[1] - https://issues.apache.org/jira/browse/HBASE-7894
On Thu, Feb 21, 2013 at 12:13 AM, lars hofhansl wrote:
> This is not really obvious. I think we might want to add something to the
> Javadoc to that extend.
>
> Otherwise we'll see what you've
comments in line
发件人: Varun Sharma [va...@pinterest.com]
发送时间: 2013年2月21日 17:21
收件人: user@hbase.apache.org
主题: Re: 答复: 答复: GC frequency
This is a very interesting article indeed, it seems to say that for heap
size > 4-8GB - time of new gen collection could
This is a very interesting article indeed, it seems to say that for heap
size > 4-8GB - time of new gen collection could be dominated by size of the
heap rather than size of new generation. This is interesting and I have not
found any such guideline in hbase book etc.
Do you think the overall heap
Here is a good formula to estimate:
http://blog.ragozin.info/2011/06/understanding-gc-pauses-in-jvm-hotspots.html
Hope it helpful:)
发件人: Varun Sharma [va...@pinterest.com]
发送时间: 2013年2月21日 16:22
收件人: user@hbase.apache.org
主题: Re: 答复: GC frequency
What do
What do you mean by normal size heap ? Here is JVM settings
-Xms11480m -Xmx11480m -XX:NewSize=512m -XX:MaxNewSize=512m
-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=60
-XX:+UseCMSInitiatingOccupancyOnly -XX:ParallelGCThreads=4
I was told that for a 4 core machine, it typically takes
Of course, you'll hit the nightmarish "CMS fragement" easier if NewSize too
low:)
Generally speaking, most of YGC should be less than 5ms for a normal size heap.
maybe your load is too high or there're vm options be misconfigured ?
发件人: Varun Sharma [va...@
24 matches
Mail list logo
