[
https://issues.apache.org/jira/browse/SOLR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13539526#comment-13539526
]
Uwe Schindler edited comment on SOLR-1972 at 12/26/12 12:50 PM:
----------------------------------------------------------------
This commit causes a huge memory leak in Solr: The whole heap (60% while
running tests) is filled with (interned) Strings, ConcurrentHashMap.Entry, and
lots of class instances from the com.yammer.metrics package. This causes the
the recent permgen issues in running Solr tests.
We should revert this and investigate how to remove the com.yammer.metrics
package dependency (or make the stats cleaner). To me it looks like every query
to solr creates a new entry in those huge maps, causing them to grow and grow
and grow... There is also no cleanup that shuts down the MBean servers holding
all those references on core shutdown.
See:
http://lucene.472066.n3.nabble.com/JENKINS-Lucene-Solr-trunk-Linux-32bit-jdk1-6-0-37-Build-3421-Failure-td4029050.html
was (Author: thetaphi):
This commit causes a huge memory leak in Solr: The hole heap is filled with
(interned) Strings, ConcurrentHashMap.Entry, and lots of class instances from
com.yammer.metrics package.
This causes the the recent permgen issues in running Solr tests.
We should revert this and investigate how to remove the com.yammer.metrics
package dependency (or make the stats cleaner). To me it looks like every query
to solr creates a new entry in those huge maps, causing them to grow and grow
and grow... There is also no cleanup that shuts down the MBean servers holding
all those references on core shutdown.
See:
http://lucene.472066.n3.nabble.com/JENKINS-Lucene-Solr-trunk-Linux-32bit-jdk1-6-0-37-Build-3421-Failure-td4029050.html
> Need additional query stats in admin interface - median, 95th and 99th
> percentile
> ---------------------------------------------------------------------------------
>
> Key: SOLR-1972
> URL: https://issues.apache.org/jira/browse/SOLR-1972
> Project: Solr
> Issue Type: Improvement
> Components: web gui
> Affects Versions: 1.4
> Reporter: Shawn Heisey
> Assignee: Alan Woodward
> Priority: Minor
> Fix For: 4.1, 5.0
>
> Attachments: elyograg-1972-3.2.patch, elyograg-1972-3.2.patch,
> elyograg-1972-trunk.patch, elyograg-1972-trunk.patch,
> SOLR-1972-branch3x-url_pattern.patch, SOLR-1972-branch4x.patch,
> SOLR-1972-branch4x.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch,
> SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch,
> SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch,
> solr1972-metricsregistry-branch4x-failure.log, SOLR-1972.patch,
> SOLR-1972.patch, SOLR-1972.patch, SOLR-1972.patch, SOLR-1972-url_pattern.patch
>
>
> I would like to see more detailed query statistics from the admin GUI. This
> is what you can get now:
> requests : 809
> errors : 0
> timeouts : 0
> totalTime : 70053
> avgTimePerRequest : 86.59209
> avgRequestsPerSecond : 0.8148785
> I'd like to see more data on the time per request - median, 95th percentile,
> 99th percentile, and any other statistical function that makes sense to
> include. In my environment, the first bunch of queries after startup tend to
> take several seconds each. I find that the average value tends to be useless
> until it has several thousand queries under its belt and the caches are
> thoroughly warmed. The statistical functions I have mentioned would quickly
> eliminate the influence of those initial slow queries.
> The system will have to store individual data about each query. I don't know
> if this is something Solr does already. It would be nice to have a
> configurable count of how many of the most recent data points are kept, to
> control the amount of memory the feature uses. The default value could be
> something like 1024 or 4096.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
