Salman, Yeah, that first cache is too small. Double it and evictions may go away.
Re warm-up queries - yes, they'll be slower than when executed later when they get pulled out of the cache. Plus if these are warm-up queries, the relevant parts of the index may not be in the OS buffer cache. Otis ---- Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch Lucene ecosystem search :: http://search-lucene.com/ ----- Original Message ---- > From: Salman Akram <salman.ak...@northbaysolutions.net> > To: markus.jel...@openindex.io > Cc: solr-user@lucene.apache.org > Sent: Thu, January 20, 2011 7:26:39 AM > Subject: Re: Mem allocation - SOLR vs OS > > I will be looking into JConsole. > > One more question regarding caching. When we talk about warm-up queries does > that mean that some of the complex queries (esp those which require high I/O > e.g. phrase queries) will really be very slow (on lets say an index of > 200GB) if they are not cached? I am talking about difference of more than > few seconds... > > Also regarding the cache settings I wanted to get another advice when you > talk about evictions do you mean the cumulative or current? I know ideally > the hit rate should be high and evictions low but can you please look into > the below stats for documentCache of both indexes and see what is it really > 'saying'. Should the size be increased/decreases/kept same or this data is > not enough to judge and should collect at least few days data? > > Note: Tomcat was restarted a day back and as I said there isn't much > workload but complex queries and index is updated every hour (currently > haven't implemented replication). > > Max Size and InitialSize for both is 4096 > > lookups : 9849 > hits : 5144 > hitratio : 0.52 > inserts : 4705 > evictions : 609 > size : 4096 > warmupTime : 0 > cumulative_lookups : 82492 > cumulative_hits : 52059 > cumulative_hitratio : 0.63 > cumulative_inserts : 30433 > cumulative_evictions : 685 > -------------------------- > lookups : 5539 > hits : 3765 > hitratio : 0.67 > inserts : 1774 > evictions : 0 > size : 1774 > warmupTime : 0 > cumulative_lookups : 29062 > cumulative_hits : 20568 > cumulative_hitratio : 0.70 > cumulative_inserts : 8494 > cumulative_evictions : 0 > > > > On Wed, Jan 19, 2011 at 11:48 PM, Markus Jelsma > <markus.jel...@openindex.io>wrote: > > > You only need so much for Solr so it can do its thing. Faceting can take > > quite > > some memory on a large index but sorting can be a really big RAM consumer. > > > > As Erick pointed out, inspect and tune the cache settings and adjust RAM > > allocated to the JVM if required. Using tools like JConsole you can monitor > > various things via JMX including RAM consumption. > > > > > Hi, > > > > > > I know this is a subjective topic but from what I have read it seems more > > > RAM should be spared for OS caching and much less for SOLR/Tomcat even on > > a > > > dedicated SOLR server. > > > > > > Can someone give me an idea about the theoretically ideal proportion b/w > > > them for a dedicated Windows server with 32GB RAM? Also the index is > > > updated every hour. > > > > > > -- > Regards, > > Salman Akram >
