Why don't we create a patch that allows one to check a box to get the Field Cache stats and then reload? Off by default.
On Jan 8, 2010, at 2:33 PM, Jay Hill wrote: > Actually my cases were all with customers I work with, not just one case. A > common practice is to monitor cache stats to tune the caches properly. Also, > noting the warmup times for new IndexSearchers, etc. I've worked with people > that have excessive auto-warm count values which is causing extremely long > warmup times for the new Searchers. So the stats.jsp page has always been a > handy, simple tool to monitor this stuff and set caches appropriately. But > at some point (around the release of 1.4) I started to notice this problem. > Since it causes the memory spike it pretty much prevents the use of > stats.jsp in production. I've had to resort to log-parsing and other tricks > which is a bit of a waste since it was so simple to do before this surfaced. > > -Jay > > > On Fri, Jan 8, 2010 at 10:41 AM, Chris Hostetter > <hossman_luc...@fucit.org>wrote: > >> >> : >> 2009-05-28) to the Solr 1.4.0 released code. Every 3 hours we have a >> : >> cron task to log some of the data from the stats.jsp page from each >> : >> core (about 100 cores, most of which are small indexes). >> >> 1) what stats are you actaully interested in? ... in Jay's case the >> LukeRequestHandler made more sense to get the data he wnated anyway. >> >> 2) what does the output of stats.jsp say when you see these load spikes? >> ... it should be fairly lightweight unless it detects some "insanity" in >> the way the FieldCaches are being used, in which case it does memory >> estimation to make it clear how significant the problem is. >> >> >> -Hoss >> -------------------------- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem using Solr/Lucene: http://www.lucidimagination.com/search
