[
https://issues.apache.org/jira/browse/SOLR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13539552#comment-13539552
]
Uwe Schindler commented on SOLR-1972:
-------------------------------------
bq. As for seeing what looks like a leak with each query, after 1024 queries,
the growth in non-garbage objects should stop, because it throws away an entry
to make room for the new one.
That might be correct, the problem here is a leak, that might also affect
people reloading Solr in their App-Server. The problem is that somehow on
CoreShutdown the MBeans are not destroyed. Maybe this is fine how it is
implemented, but when the Solr core shuts down, all statistics data have to be
removed and nulled out or whatever.
I would revert this patch for now, until there is a better solution. Once you
have a new patch, that does not leak those objects on core shutdowns.
The horrible thing is that all those huge maps contains stupid strings, all
starting with some solr class name (a RequestHandler), followed by an id and
various other information. There are (in the dump analyzed with visualvm)
millions of String looking like that (OQL executed on heap dump):
{code:sql}
select count(heap.objects("java.lang.String"),
'it.toString().startsWith("org.apache.solr.handler")')
{code}
This looks like a huge waste!
> 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
