FYI, I opened https://issues.apache.org/jira/browse/SOLR-2036
for this.
-Yonik
http://www.lucidimagination.com
On Tue, Aug 10, 2010 at 8:35 PM, entdeveloper
cameron.develo...@gmail.com wrote:
Apologies if this was resolved, but we just deployed Solr 1.4.1 and the stats
page takes over a
Apologies if this was resolved, but we just deployed Solr 1.4.1 and the stats
page takes over a minute to load for us as well and began causing
OutOfMemory errors so we've had to refrain from hitting the page. From what
I gather, it is the fieldCache part that's causing it.
Was there ever an
Yes, we do have some fields (like the creation date) that we use for
both sorting and faceting.
-Peter
On Tue, Jan 26, 2010 at 8:55 PM, Yonik Seeley
yo...@lucidimagination.com wrote:
On Tue, Jan 26, 2010 at 8:49 PM, Peter Wolanin peter.wola...@acquia.com
wrote:
Sorry for not following up
Heya -
So we just upgraded our Solr install to 1.4, and there's a great CPU drop
and query response time drop. Good!
But we're seeing the slowdown in the collection of statistics (stats.jsp)
mentioned here:
http://www.mail-archive.com/solr-user@lucene.apache.org/msg30224.html
to the tune of
john allspaw wrote:
Heya -
So we just upgraded our Solr install to 1.4, and there's a great CPU drop
and query response time drop. Good!
But we're seeing the slowdown in the collection of statistics (stats.jsp)
mentioned here:
Sorry for not following up sooner- been a busy last couple weeks.
We do see a significant instanity count - could this be due to
updating indexes from the dev Solr build? E.g. on one server I see
stat name=insanity_count
61
/stat
and entries like:
stat
On Tue, Jan 26, 2010 at 8:49 PM, Peter Wolanin peter.wola...@acquia.com wrote:
Sorry for not following up sooner- been a busy last couple weeks.
We do see a significant instanity count - could this be due to
updating indexes from the dev Solr build? E.g. on one server I see
Do you both sort
- stats page slow
I recently noticed the same sort of thing.
The attached screenshot shows the transition on a search server
when we updated from a Solr 1.4 dev build (revision 779609 from
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
I thought this was fixed...
http://issues.apache.org/jira/browse/SOLR-1292
http://www.lucidimagination.com/search/document/57103830f0655776/stats_page_slow_in_latest_nightly
-Yonik
http://www.lucidimagination.com
It's definitely still an issue. I've seen this with at least four different
Solr implementations. It clearly seems to be a problem when there is a large
field cache. It would be bad enough if the stats.jsp was just slow to load
(usually takes 1 to 2 minutes), but when monitoring memory usage with
Yonik Seeley wrote:
I thought this was fixed...
http://issues.apache.org/jira/browse/SOLR-1292
http://www.lucidimagination.com/search/document/57103830f0655776/stats_page_slow_in_latest_nightly
-Yonik
http://www.lucidimagination.com
It should be fixed in trunk, but that was after 1.4.
Mark Miller wrote:
Yonik Seeley wrote:
I thought this was fixed...
http://issues.apache.org/jira/browse/SOLR-1292
http://www.lucidimagination.com/search/document/57103830f0655776/stats_page_slow_in_latest_nightly
-Yonik
http://www.lucidimagination.com
It should be fixed in
On Fri, Jan 8, 2010 at 1:03 PM, Mark Miller markrmil...@gmail.com wrote:
It should be fixed in trunk, but that was after 1.4. Currently, it
should only do it if it sees insanity - which there shouldn't be any
with stock Solr.
Yonik Seeley wrote:
On Fri, Jan 8, 2010 at 1:03 PM, Mark Miller markrmil...@gmail.com wrote:
It should be fixed in trunk, but that was after 1.4. Currently, it
should only do it if it sees insanity - which there shouldn't be any
with stock Solr.
: 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
: We should prob switch to never calculating the size unless an explicit
: param is pass to the stats page.
I don't think that's as easy as it sounds considdering stats.jsp is just
iterating over MBeans - that level of control over the Insanity checker is
abstracted away.
-Hoss
Chris Hostetter wrote:
: We should prob switch to never calculating the size unless an explicit
: param is pass to the stats page.
I don't think that's as easy as it sounds considdering stats.jsp is just
iterating over MBeans - that level of control over the Insanity checker is
abstracted
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
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
On Fri, Jan 8, 2010 at 1:38 PM, Mark Miller markrmil...@gmail.com wrote:
Yonik Seeley wrote:
So people seeing this should also being seeing an insanity count over one.
I'd think that would be rarer than one this sounds like though ... whats
left that could cause insanity?
faceting on a
Yonik Seeley wrote:
ord(field)
I thought you used those leaf readers to get around top level for ord?
--
- Mark
http://www.lucidimagination.com
On Fri, Jan 8, 2010 at 3:02 PM, Mark Miller markrmil...@gmail.com wrote:
Yonik Seeley wrote:
ord(field)
I thought you used those leaf readers to get around top level for ord?
ord()/rord() now works via top()... by popping back to the top level reader.
-Yonik
http://www.lucidimagination.com
I recently noticed the same sort of thing.
The attached screenshot shows the transition on a search server
when we updated from a Solr 1.4 dev build (revision 779609 from
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
Sent: Thu, January 7, 2010 9:32:26 PM
Subject: Re: Solr 1.4 - stats page slow
I recently noticed the same sort of thing.
The attached screenshot shows the transition on a search server
when we updated from a Solr 1.4 dev build (revision 779609 from
2009-05-28) to the Solr 1.4.0 released code
Sorry, know I'm a little late in replying but the LukeRequestHandler
tip was just what I needed! Thank you so much.
--
Steve
On Dec 25, 2009, at 2:03 AM, Chris Hostetter wrote:
: I've noticed this as well, usually when working with a large field
cache. I
: haven't done in-depth analysis
I've noticed this as well, usually when working with a large field cache. I
haven't done in-depth analysis of this yet, but it seems like when the stats
page is trying to pull data from a large field cache it takes quite a long
time.
Are you doing a lot of sorting? If so, what are the field types
Also, what is your heap size and the amount of RAM on the machine?
I've also noticed that, when watching memory usage through JConsole or
YourKit while loading the stats page, the memory usage spikes dramatically -
are you seeing this as well?
-Jay
On Thu, Dec 24, 2009 at 9:12 AM, Jay Hill
: I've noticed this as well, usually when working with a large field cache. I
: haven't done in-depth analysis of this yet, but it seems like when the stats
: page is trying to pull data from a large field cache it takes quite a long
: time.
In Solr 1.4, the stats page was modified to start
We've been using Solr 1.4 for a few days now and one slight downside
we've noticed is the stats page comes up very slowly for some reason -
sometimes more than 10 seconds. We call this programmatically to
retrieve the last commit date so that we can keep users from
committing too
29 matches
Mail list logo
