On 3/3/2014 1:54 AM, KNitin wrote:
3. 2.8 Gb - Perm Gen (I am guessing this is because of interned strings)
As others have pointed out, this is really unusual for Solr. We often
see high permgen in our app servers due to dynamic class loading that
the framework performs; maybe you are somehow
Regarding PermGen: Yes we have a bunch of custom jars loaded in solrcloud
(containing custom parsing, analyzers). But I haven't specifically enabled
any string interning. Does solr intern all strings in a collection by
default?
I agree with doc and Filter Query Cache. Query Result cache hits are
Is there a way to dump the contents of permgen and look at which classes
are occupying the most memory in that?
- Nitin
On Mon, Mar 3, 2014 at 11:19 AM, KNitin nitin.t...@gmail.com wrote:
Regarding PermGen: Yes we have a bunch of custom jars loaded in solrcloud
(containing custom parsing,
If you just want to see which classes are occupying the most memory in a live JVM,you can do:jmap -permstat pidI don't think you can dump the contents of PERM space.Hope this helps,TriOn Mar 03, 2014, at 11:41 AM, KNitin nitin.t...@gmail.com wrote:Is there a way to dump the contents of permgen and
Hi
I have very large index for a few collections and when they are being
queried, i see the Old gen space close to 100% Usage all the time. The
system becomes extremely slow due to GC activity right after that and it
gets into this cycle very often
I have given solr close to 30G of heap in a 65
An LRU cache will always fill up the old generation. Old objects are ejected,
and those are usually in the old generation.
Increasing the heap size will not eliminate this. It will make major, stop the
world collections longer.
Increase the new generation size until the rate of old gen
Thanks, Walter
Hit rate on the document caches is close to 70-80% and the filter caches
are a 100% hit (since most of our queries filter on the same fields but
have a different q parameter). Query result cache is not of great
importance to me since the hit rate their is almost negligible.
Does
Actually, I haven't ever seen a PermGen with 2.8 GB.
So you must have a very special use case with SOLR.
For my little index with 60 million docs and 170GB index size I gave
PermGen 82 MB and it is only using 50.6 MB for a single VM.
Permanent Generation (PermGen) is completely separate from the
New gen should be big enough to handle all allocations that have a lifetime of
a single request, considering that you'll have multiple concurrent requests. If
new gen is routinely overflowed, you can put short-lived objects in the old gen.
Yes, you need to go to CMS.
I have usually seen the
