Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
HBase >> mail # user >> Does HBase RegionServer benefit from OS Page Cache


+
Pankaj Gupta 2013-03-20, 07:34
+
Jean-Daniel Cryans 2013-03-20, 17:30
+
Enis Söztutar 2013-03-21, 20:28
+
Pankaj Gupta 2013-03-24, 00:31
+
Ted Yu 2013-03-24, 01:13
+
Liyin Tang 2013-03-24, 04:44
Copy link to this message
-
Re: Does HBase RegionServer benefit from OS Page Cache
Interesting.

> 2) The blocks in the block cache will be naturally invalid quickly after the compactions.

Should one keep the block cache small in order to increase the OS page cache?

Does you data suggest we should not use the block cache at all?
Thanks.

-- Lars

________________________________
 From: Liyin Tang <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Saturday, March 23, 2013 9:44 PM
Subject: Re: Does HBase RegionServer benefit from OS Page Cache
 
We (Facebook) are closely monitoring the OS page cache hit ratio in the
production environments. My experience is if your data access pattern is
very random, then the OS page cache won't help you so much even though the
data locality is very high. On the other hand, if the requests are always
against the recent data points, then the page cache hit ratio could be much
higher.

Actually, there are lots of optimizations could be done in HDFS. For
example, we are working on fadvice away the 2nd/3rd replicated data from OS
page cache so that it potentially could improve your OS page cache by 3X.
Also, by taking advantage of the tiered-based compaction+fadvice in HDFS,
the region server could keep more hot data in OS page cache based on the
read access pattern.

Another separate point is that we probably should NOT reply on the
memstore/block cache to keep hot data. 1) The more data in the memstore,
the more data the region server need to recovery from the server failures.
So the tradeoff is the recovery time. 2) The blocks in the block cache will
be naturally invalid quickly after the compactions. So region server
probably won't be benefit from large JVM size at all.

Thanks a lot
Liyin

On Sat, Mar 23, 2013 at 6:13 PM, Ted Yu <[EMAIL PROTECTED]> wrote:

> Coming up is the following enhancement which would make MSLAB even better:
>
> HBASE-8163 MemStoreChunkPool: An improvement for JAVA GC when using MSLAB
>
> FYI
>
> On Sat, Mar 23, 2013 at 5:31 PM, Pankaj Gupta <[EMAIL PROTECTED]
> >wrote:
>
> > Thanks a lot for the explanation. It's good to know that MSlab is stable
> > and safe to enable (we don't have it enable right now, we're using 0.92).
> > This would allow us to more freely allocate memory to HBase. I really
> > enjoyed the depth of explanation from both Enis and J-D. I was indeed
> > mistakenly referring to HFile as HLog, fortunately you were still able
> > understand my question.
> >
> > Thanks,
> > Pankaj
> > On Mar 21, 2013, at 1:28 PM, Enis Söztutar <[EMAIL PROTECTED]> wrote:
> >
> > > I think the page cache is not totally useless, but as long as you can
> > > control the GC, you should prefer the block cache. Some of the reasons
> of
> > > the top of my head:
> > > - In case of a cache hit, for OS cache, you have to go through the DN
> > > layer (an RPC if ssr disabled), and do a kernel jump, and read using
> the
> > > read() libc vs  for reading a block from the block cache, only the
> HBase
> > > process is involved. There is no process switch involved and no kernel
> > > jumps.
> > > - The read access path is optimized per hfile block. FS page boundaries
> > > and hfile block boundaries are not aligned at all.
> > > - There is very little control to the page cache to cache / not cache
> > > based on expected access patterns. For example, we can mark META region
> > > blocks, and some column families, and hfile index blocks always cached
> or
> > > cached with high priority. Also, for full table scans, we can
> explicitly
> > > disable block caching to not trash the current working set. With OS
> page
> > > cache, you do not have this control.
> > >
> > > Enis
> > >
> > >
> > > On Wed, Mar 20, 2013 at 10:30 AM, Jean-Daniel Cryans <
> > [EMAIL PROTECTED]>wrote:
> > >
> > >> First, MSLAB has been enabled by default since 0.92.0 as it was deemed
> > >> stable enough. So, unless you are on 0.90, you are already using it.
> > >>
> > >> Also, I'm not sure why you are referencing the HLog in your first
> > >> paragraph in the context of reading from disk, because the HLogs are
+
Liyin Tang 2013-03-25, 05:15
+
Enis Söztutar 2013-03-25, 18:24
+
Liyin Tang 2013-03-25, 19:18
+
Enis Söztutar 2013-03-25, 20:26
+
谢良 2013-03-26, 03:01
+
Andrew Purtell 2013-03-25, 18:42