[
https://issues.apache.org/jira/browse/SOLR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13485280#comment-13485280
]
Shawn Heisey commented on SOLR-1972:
------------------------------------
I ran into some trouble with tests failing, so I checked out a fresh branch_4x,
applied this patch, and tried running solr tests. There are major explosions.
I'll be attaching the full putty log for review. It appears that the first
exception is an out of memory error:
[junit4:junit4] 2> 7800 T177
ccr.RandomizedRunner$QueueUncaughtExceptionsHandler.uncaughtException WARNING
Uncaught exception in thread:
Thread[metrics-meter-tick-thread-1,5,TGRP-TestRandomFaceting]
java.lang.OutOfMemoryError: unable to create new native thread
[junit4:junit4] 2> at
__randomizedtesting.SeedInfo.seed([2191B18B87EDCD66]:0)
[junit4:junit4] 2> at java.lang.Thread.start0(Native Method)
[junit4:junit4] 2> at java.lang.Thread.start(Thread.java:691)
[junit4:junit4] 2> at
java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:943)
[junit4:junit4] 2> at
java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:992)
[junit4:junit4] 2> at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[junit4:junit4] 2> at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
[junit4:junit4] 2> at java.lang.Thread.run(Thread.java:722)
[junit4:junit4] 2>
If I edit out the MetricsRegistry and go back to creating the objects directly
from Metrics and using this.toString() as the scope, the tests all pass.
The Metrics documentation talks about MetricsRegistry as being something you
create on a per-application basis. That suggests that it's a very heavy
object, and even a barebones Solr install probably has at least a dozen
requestHandlers defined. I don't know how many are defined in the JVMs used
for testing.
On my test branch_4x installation, I see 29 handlers between QUERYHANDLER and
UPDATEHANDLER in the stats visible in the gui, and that's just on one core.
I've got 16 cores defined.
> 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
>
> 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.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
