Am 05.06.2013 18:09, schrieb SandeepM:
> /So we see the jagged edge waveform which keeps climbing (GC cycles don't
> completely collect memory over time).  Our test has a short capture from
> real traffic and we are replaying that via solrmeter./
> 
> Any idea why the memory climbs over time.  The GC should cleanup after data
> is shipped back.  Could there be a memory leak in SOLR?

Sorting can be a killer so take care about sorting only on fields prepared for 
sorting
and on fields which really make sense to sort.
The ultimate test/killer is sorting and faceting on doc id (the id field).
The problem is most times the fieldCache:
"Provides introspection of the Lucene FieldCache, this is **NOT** a cache that 
is managed by Solr."

Yes, the memory footprint right after start is higher for 4.2.1 than for 3.5, 
but
during runtime it is much lower with 4.2.1 (because of FST).

As for my system (45 mio. docs / 125 GB index) with 3.x I had 4 to 5 GB right 
after start
and 10 to 12 GB during runtime after several days. Now I have with 4.2.1 about 
6 GB right
after start and are between 6.5 to 8 GB at runtime.
I don't see any increase in memory usage even after weeks, only peaks to 10 GB 
during replication
which will then decrease back to normal (6.5 to 8 GB).
So definately no memory leak.

What helped me a lot was switching to G1GC.
Faster, smoother, very little ripple, nearly no sawtooth.

Bernd

Reply via email to