lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <apa...@elyograg.org>
Subject Re: Solr hangs / LRU operations are heavy on cpu
Date Fri, 20 Mar 2015 15:39:14 GMT
On 3/19/2015 8:49 PM, Umesh Prasad wrote:
> It might be because LRUCache by default will try to evict its entries on
> each call to put and putAll. LRUCache is built on top of java's
> LinkedHashMap. Check the javadoc of removeEldestEntry
> <http://docs.oracle.com/javase/7/docs/api/java/util/LinkedHashMap.html#removeEldestEntry%28java.util.Map.Entry%29>
>
>
> Try using LFUCache and a separate cleanup thread .. We have been using that
> for over 2 yrs now without any issues ..

All cache implementations evict old entries on "put" if the cache is
full, including LFUCache.  What's different is how the evicted entry is
chosen and how efficient the eviction process is.

I wrote the LFUCache implementation that's currently in Solr.  It is the
most basic naive implementation of LFU that you can write, the kind of
thing that a beginning Computer Science student would write to show a
correct implementation. :)  It's probably suitable for very small cache
sizes (double digits), but if the cache size is large, LFUCache is very
inefficient at eviction.  With a large size, it might hit the CPU even
harder than LRUCache.

I have written a much better implementation that's more efficient, I
need to polish the code and commit it.

As a general rule, I would expect the LRU implementations to always be
more efficient at eviction than any implementation of LFU, but some
query patterns will have a higher cache hitCount with an LFU
implementation, so the tradeoff might be worth making.

Thanks,
Shawn


Mime
View raw message