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 >
