Hi Hoss,
...why is SolrRequestParsers 51 MB ?
Instances of this class shouldn't by fluctuating in size, it doesn't
maintain any mutable state -- so WTF?
You can try to debug it if you add an afterclass hook and dump the
size tree using, for example:
: (b) is unlikely. Dump the allocation tree and see what's the major
: contributor to the size.
Right, see rmuir's response and the subsequent collection of aggregation
of info in my comment on SOLR-4825...
https://issues.apache.org/jira/browse/SOLR-4825#comment-13659117
-Hoss
My suspicion is that its that map key'ed on solrcore.
in this case it would be holding references to SolrCores from previous
tests. Because test order and other things are randomized, it would
explain the huge size fluctuations.
On Thu, May 16, 2013 at 12:35 PM, Chris Hostetter
What's a little odd is that this should work exactly as it did before we used
log4j - I just pure copied the code from a Formatter to a Layout. I originally
suspected that the Layout is holding onto stuff, but thought perhaps that had
something to do with java util logging vs log4j, since this
On May 16, 2013, at 12:59 PM, Mark Miller markrmil...@gmail.com wrote:
In any case, it seems likely we can improve the Layout - I can take a look.
Seems like we could get away with just using SolrCore#hashCode rather than
keying by the SolrCore.
- Mark
: What's a little odd is that this should work exactly as it did before we
It just occured to me that one thing rmuir and i noticed in IRC never made
it into email or my jira comments: the Logger used by SolrRequestParsers
is not static, so the mem estimator would count that as ram used by
is not static, so the mem estimator would count that as ram used by the
object itself.
The estimation actually includes static fields -- if it didn't you
could easily overflow memory simply by allocating static byte[]
buffers or something else. Object-level fields are garbage collected
because
: is not static, so the mem estimator would count that as ram used by the
: object itself.
:
: The estimation actually includes static fields -- if it didn't you
: could easily overflow memory simply by allocating static byte[]
But clearly there is a diff between statics in the tests, and
...surely if the SolrRequestParser *class* had a static var the Logger
(instead of an instance var) that wouldn't have counted against the amount
of memory being used by the SolrRequestParser ?
No, it wouldn't. We collect static fields from the suite class and
then traverse the object graph
: ...surely if the SolrRequestParser *class* had a static var the Logger
: (instead of an instance var) that wouldn't have counted against the amount
: of memory being used by the SolrRequestParser ?
:
: No, it wouldn't. We collect static fields from the suite class and
: then traverse the
The estimation actually includes static fields
Yeah, I probably misunderstood something along the way, apologies.
When you look at the code I linked to things are pretty simple:
1) collect values of static fields from the test suite class (and its
superclasses),
2) for non-null values, estimate
Something is fishy with this sudden onset of RegexBoostProcessorTest
failures
- happening on diff hosts, diff OSes, diff JVMs
- happening on trunk and 4x
- only started happening today
- SolrRequestParsers object is huge for no explicible reason...
: Stack Trace:
On Wed, May 15, 2013 at 9:12 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
Something is fishy with this sudden onset of RegexBoostProcessorTest
failures
- happening on diff hosts, diff OSes, diff JVMs
- happening on trunk and 4x
- only started happening today
-
13 matches
Mail list logo
