[ 
https://issues.apache.org/jira/browse/SOLR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13539544#comment-13539544
 ] 

Shawn Heisey commented on SOLR-1972:
------------------------------------

This is really useful to me, I'm very sad to learn it's causing problems.  I 
haven't noticed anything in my own running of branch_4x, which runs for days at 
a time.  I'm attempting to get some heap dumps so I can compare them.  Based on 
what I know from my own experience, I don't think this is actually a leak, but 
even a minimal test JVM ends up with a lot of request handlers, each of which 
has these additional objects.  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.

I wonder if there might be an easy way to make these new statistics optional in 
the request handler, so they do not cause memory problems with minimal test 
configs.  Although it's really cool to be able to see detailed query statistics 
on the SolrInfoMBeanHandler, it's unnecessary.

If it does get removed, I guess I'll have to go back to the previous version of 
the patch that only has additional statistics on qtime.  I depend on these 
statistics - the average values otherwise available are nearly useless.

I will attempt a patch.  No guarantees about success!

                
> 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

Reply via email to