On Thu, Jan 20, 2011 at 2:58 PM, Todd Lipcon wrote:
> On Thu, Jan 20, 2011 at 2:52 PM, tsuna wrote:
>
>> On Thu, Jan 20, 2011 at 9:33 AM, Todd Lipcon wrote:
>> > I did some experiments to understand our full GC issues better last
>> night.
>> > Here are the results:
>> > http://people.apache.org
Hi Todd,
Thanks for the great report. I came up with an idea to suppress the
fragmentation by the memstore, so I wrote a comment on the JIRA. Would you like
to examine it?
https://issues.apache.org/jira/browse/HBASE-3455
--
Tatsuya Kawano (Mr.)
Tokyo, Japan
On Thu, Jan 20, 2011 at 2:52 PM, tsuna wrote:
> On Thu, Jan 20, 2011 at 9:33 AM, Todd Lipcon wrote:
> > I did some experiments to understand our full GC issues better last
> night.
> > Here are the results:
> > http://people.apache.org/~todd/hbase-fragmentation/
>
> Just curious: what hardware c
On Thu, Jan 20, 2011 at 9:33 AM, Todd Lipcon wrote:
> I did some experiments to understand our full GC issues better last night.
> Here are the results:
> http://people.apache.org/~todd/hbase-fragmentation/
Just curious: what hardware configuration was used during this test?
--
Benoit "tsuna" S
rs available in the queue, and you
> need to write, trigger a flush. That means it'll be the same buffers,
> which won't create new heap fragmentation as they'll presumably
> migrate down to the bottom of old gen heap after the first major
> compaction or two.. you're
available in the queue, and you
need to write, trigger a flush. That means it'll be the same buffers,
which won't create new heap fragmentation as they'll presumably
migrate down to the bottom of old gen heap after the first major
compaction or two.. you're just passing refere
udera.com]
>> Sent: Thursday, January 20, 2011 9:33 AM
>> To: dev
>> Subject: Heap fragmentation
>>
>> I did some experiments to understand our full GC issues better last night.
>> Here are the results:
>> http://people.apache.org/~todd/hbase-fragmentation/
011 9:33 AM
> To: dev
> Subject: Heap fragmentation
>
> I did some experiments to understand our full GC issues better last night.
> Here are the results:
> http://people.apache.org/~todd/hbase-fragmentation/
>
> <http://people.apache.org/~todd/hbase-fragmentation/>Basic
AM
To: dev
Subject: Heap fragmentation
I did some experiments to understand our full GC issues better last night.
Here are the results:
http://people.apache.org/~todd/hbase-fragmentation/
<http://people.apache.org/~todd/hbase-fragmentation/>Basically my conclusion
here is that (for thes
ote:
> >
> > > I did some experiments to understand our full GC issues better last
> > night.
> > > Here are the results:
> > > http://people.apache.org/~todd/hbase-fragmentation/
> > >
> > > <http://people.apache.org/~todd/hbase-fragme
t; http://people.apache.org/~todd/hbase-fragmentation/
> >
> > <http://people.apache.org/~todd/hbase-fragmentation/>Basically my
> > conclusion
> > here is that (for these YCSB workloads) the memstore is way worse for
> heap
> > fragmentation than the block cach
e.apache.org/~todd/hbase-fragmentation/>Basically my
> conclusion
> here is that (for these YCSB workloads) the memstore is way worse for heap
> fragmentation than the block cache.
>
> Also we now have some tools and reference for comparison if we make any
> changes to memstore
>
> <http://people.apache.org/~todd/hbase-fragmentation/>Basically my
> conclusion
> here is that (for these YCSB workloads) the memstore is way worse for heap
> fragmentation than the block cache.
>
> Also we now have some tools and reference for comparison if we make any
> changes
se for heap
fragmentation than the block cache.
Also we now have some tools and reference for comparison if we make any
changes to memstore to try to combat this issue.
-Todd
--
Todd Lipcon
Software Engineer, Cloudera
14 matches
Mail list logo
