Hi Chris, Robert
Thank you very much. First, answers to your questions:
1) which version of Solr are you using?
3.6.0
2) is it possibly you have multiple searchers open (ie: one in use
while another one is warming up) when you're seeing these stats?
No, no multiple searchers.
Now, after one day of experiments, I think I got what's happening.
Briefly, the behaviour seems to be exactly what Chris described (Weak
references that are garbage collected when needed). Instead I'm not
seeing what described by Robert.
This is what I understood aboyut my problem:
- Xms4GB
- sort fields definitely too big...once loaded they got about more than
2GB of memory
So when replication occurs "new" sort field values (belonging to the new
replicated segment) are loaded in memory...but before old segment are
garbage collected on slave (I mean, sort field values belonging to the
old segment) I have no enough memory (2GB + 2GB...only for sort
fields)....so et voilà: OutOfMemory
What I've done is to reduce unique values of sort fields (now the
FieldCacheImpl is about 600MB) so there's enough memory for ordinary
work, for replication stuff and for retaining two different
FieldCacheImpl references (old and replicated segment)...in this way I
see exatcly what Chris described: when replication occurs, memory grows
(on slave) for about 800MB; hereafter the memory has a constant growing
(very slowly) graph but when it reaches a certain point (about 3.7GB)
garbage collector run and frees something like 2.2GB. Good, I repeat
this test a lot of times and the behaviour is always the same.
Thank you very much to both of you
Andrea
On 08/14/2013 11:58 PM, Chris Hostetter wrote:
: > FieldCaches are managed using a WeakHashMap - so once the IndexReader's
: > associated with those FieldCaches are no logner used, they will be garbage
: > collected when and if the JVMs garbage collector get arround to it.
: >
: > if they sit arround after you are done with them, they might look like the
: > ytake upa log of memory, but that just means your JVM Heap has that memory
: > to spare and hasn't needed to clean them up yet.
:
: I don't think this is correct.
:
: When you register an entry in the fieldcache, it registers event
: listeners on the segment's core so that when its close()d, any entries
: are purged rather than waiting on GC.
:
: See FieldCacheImpl.java
Ah ... sweet. I didn't realize that got added.
(In any case: it looks like a WeakHashMap is still used in case the
listeners never get called, correct?)
But bassed on the details from the OP's first message, it looks like he's
running Solr 3.x (there's mentions of "SolrIndexReader" which fromat what
i can tell was gone by 4.0) so perhaps this is an older version before all
the kinks were worked out in the reader close listeners used by
fieldcache? (I'm noticing things like LUCENE-3644 in particular)
Andrea:
1) which version of Solr are you using?
2) is it possibly you have multiple searchers open (ie: one in use
while another one is warming up) when you're seeing these stats?
-Hoss
