Josh, You've mentioned a couple of times that you've got PermGen set to 512M but then you say you're running with -XX:MaxPermSize=64M. These two statements are contradictory so are you *sure* that you're running with 512M of PermGen? Assuming your on a *nix box can you provide `ps` output proving this?
Thanks, Greg On Feb 28, 2014, at 5:22 PM, Furkan KAMACI <furkankam...@gmail.com> wrote: > Hi; > > You can also check here: > http://stackoverflow.com/questions/3717937/cmspermgensweepingenabled-vs-cmsclassunloadingenabled > > Thanks; > Furkan KAMACI > > > 2014-02-26 22:35 GMT+02:00 Josh <jwda...@gmail.com>: > >> Thanks Timothy, >> >> I gave these a try and -XX:+CMSPermGenSweepingEnabled seemed to cause the >> error to happen more quickly. With this option on it didn't seemed to do >> any intermittent garbage collecting that delayed the issue in with it off. >> I was already using a max of 512MB, and I can reproduce it with it set this >> high or even higher. Right now because of how we have this implemented just >> increasing it to something high just delays the problem :/ >> >> Anything else you could suggest I would really appreciate. >> >> >> On Wed, Feb 26, 2014 at 3:19 PM, Tim Potter <tim.pot...@lucidworks.com >>> wrote: >> >>> Hi Josh, >>> >>> Try adding: -XX:+CMSPermGenSweepingEnabled as I think for some VM >>> versions, permgen collection was disabled by default. >>> >>> Also, I use: -XX:MaxPermSize=512m -XX:PermSize=256m with Solr, so 64M may >>> be too small. >>> >>> >>> Timothy Potter >>> Sr. Software Engineer, LucidWorks >>> www.lucidworks.com >>> >>> ________________________________________ >>> From: Josh <jwda...@gmail.com> >>> Sent: Wednesday, February 26, 2014 12:27 PM >>> To: solr-user@lucene.apache.org >>> Subject: Solr Permgen Exceptions when creating/removing cores >>> >>> We are using the Bitnami version of Solr 4.6.0-1 on a 64bit windows >>> installation with 64bit Java 1.7U51 and we are seeing consistent issues >>> with PermGen exceptions. We have the permgen configured to be 512MB. >>> Bitnami ships with a 32bit version of Java for windows and we are >> replacing >>> it with a 64bit version. >>> >>> Passed in Java Options: >>> >>> -XX:MaxPermSize=64M >>> -Xms3072M >>> -Xmx6144M >>> -XX:+UseParNewGC >>> -XX:+UseConcMarkSweepGC >>> -XX:CMSInitiatingOccupancyFraction=75 >>> -XX:+CMSClassUnloadingEnabled >>> -XX:NewRatio=3 >>> >>> -XX:MaxTenuringThreshold=8 >>> >>> This is our use case: >>> >>> We have what we call a database core which remains fairly static and >>> contains the imported contents of a table from SQL server. We then have >>> user cores which contain the record ids of results from a text search >>> outside of Solr. We then query for the data we want from the database >> core >>> and limit the results to the content of the user core. This allows us to >>> combine facet data from Solr with the search results from another engine. >>> We are creating the user cores on demand and removing them when the user >>> logs out. >>> >>> Our issue is the constant creation and removal of user cores combined >> with >>> the constant importing seems to push us over our PermGen limit. The user >>> cores are removed at the end of every session and as a test I made an >>> application that would loop creating the user core, import a set of data >> to >>> it, query the database core using it as a limiter and then remove the >> user >>> core. My expectation was in this scenario that all the permgen associated >>> with that user cores would be freed upon it's unload and allow permgen to >>> reclaim that memory during a garbage collection. This was not the case, >> it >>> would constantly go up until the application would exhaust the memory. >>> >>> I also investigated whether the there was a connection between the two >>> cores left behind because I was joining them together in a query but even >>> unloading the database core after unloading all the user cores won't >>> prevent the limit from being hit or any memory to be garbage collected >> from >>> Solr. >>> >>> Is this a known issue with creating and unloading a large number of >> cores? >>> Could it be configuration based for the core? Is there something other >> than >>> unloading that needs to happen to free the references? >>> >>> Thanks >>> >>> Notes: I've tried using tools to determine if it's a leak within Solr >> such >>> as Plumbr and my activities turned up nothing. >>> >>
