Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> LIRS cache as an alternative to LRU cache


Copy link to this message
-
Re: LIRS cache as an alternative to LRU cache
Vlad,

You're correct.  The existing algorithm is called an Adaptive Replacement
Cache.  However, note that this cache does need some proper tuning for
optimal efficiency.

Nicolas

On 2/21/12 12:09 PM, "Vladimir Rodionov" <[EMAIL PROTECTED]> wrote:

>afaik, existing LruBlockCache is not exactly LRU cache
>It utilizes more advanced algorithm to avoid cache trashing during scan
>ops by
>dividing cache into three sub-caches (for newly added blocks, for
>promoted blocks and for in-memory blocks)
>
>
>Best regards,
>Vladimir Rodionov
>Principal Platform Engineer
>Carrier IQ, www.carrieriq.com
>e-mail: [EMAIL PROTECTED]
>
>________________________________________
>From: Nicolas Spiegelberg [[EMAIL PROTECTED]]
>Sent: Tuesday, February 21, 2012 9:01 AM
>To: [EMAIL PROTECTED]
>Subject: Re: LIRS cache as an alternative to LRU cache
>
>We had the author of LIRS come to Facebook last year to talk about his
>algorithm and general benefits.  At the time, we were looking at
>increasing block cache efficiency.  The general consensus was that it
>wasn't an exponential perf gain, so we could get bigger wins from
>cache-on-write intelligence, in-memory data compression techniques, and
>adding stats so we could understand how to tune the existing LRU
>algorithm.  I still think that these 3 goals are more important at the
>moment because LIRS would be a decent bit of code and only incremental
>gain.  It's probably something to revisit in a year or two.
>
>Nicolas
>
>On 2/21/12 8:26 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
>>Hi,
>>Shall we experiment with low inter-reference recency set replacement
>>policy to see if block cache becomes more effective ?
>>
>>Cheers
>>
>>
>
>
>Confidentiality Notice:  The information contained in this message,
>including any attachments hereto, may be confidential and is intended to
>be read only by the individual or entity to whom this message is
>addressed. If the reader of this message is not the intended recipient or
>an agent or designee of the intended recipient, please note that any
>review, use, disclosure or distribution of this message or its
>attachments, in any form, is strictly prohibited.  If you have received
>this message in error, please immediately notify the sender and/or
>[EMAIL PROTECTED] and delete or destroy any copy of this
>message and its attachments.
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB