The same answer as in another thread: There is a known JVM garbage collection bug that causes this. It has to do with reclaiming Weak references, I think in WeakHashMap. Concurrent garbage collection collides with this bug and the result is that old field cache data is retained after closing the index. The bug is more common with more processors doing GC simultaneously.
The symptom is that when you run a monitor, the memory usage rises to a peak, drops to a floor, rises again in the classic sawtooth pattern. When the GC bug happens, the ceiling becomes the floor, and the sawtooth goes from the new floor to a new ceiling. The two sizes are the same. So, 2G to 5G, over and over, suddenly it is 5G to 8G, over and over. The bug is fixed in recent Java 7 releases. I'm sorry, but I cannot find the bug number. ----- Original Message ----- | From: "Yonik Seeley" <yo...@lucidworks.com> | To: solr-user@lucene.apache.org | Sent: Monday, September 17, 2012 1:37:49 PM | Subject: Re: FilterCache Memory consumption high | | On Mon, Sep 17, 2012 at 3:44 PM, Mike Schultz | <mike.schu...@gmail.com> wrote: | > So I'm figuring 3MB per entry. With CacheSize=512 I expect | > something like | > 1.5GB of RAM, but with the server in steady state after 1/2 hour, | > it is 7GB | > larger than without the cache. | | Heap size and memory use aren't quite the same thing. | Try running jconsole (it comes with every JDK), attaching to the | process, and then make it run multiple garbage collections to see | what | the heap shrinks down to. | | -Yonik | http://lucidworks.com |
