I reset the statement cache size to 100 statements and set the MaxPermGen size to 256m and reran the test querying the View which uses the table function. Now when I run it, the loaded classes increase along with the PermGen, and then the loaded classes are unloaded and PermGen comes back down when it collects! This is good!
So now I need to figure out what the MaxPermGen size needs to be for a larger statement cache. -----Original Message----- From: Bergquist, Brett [mailto:[email protected]] Sent: Wednesday, November 21, 2012 8:40 AM To: [email protected] Subject: RE: Have Derby Network Server having an out of memory (PermGen) Yes, the statement cache size has been increased to 50K statements so that might be an issue. Maybe the PermGen space will need to be increased because of that. The documentation is not clear which type of heap that the statement cache would affect, however. As a test, I am going to lower my statement cache size to 100 statements and see what happens. Thanks for the idea! Some more info however. It is definitely related to the View/table function mechanism (explained in my second email). I just did a little more testing and found that if I change the query to use the table function directly instead of using the View that is created that uses the table function, then the loaded classes reported by VisualVM stays stable. Any thoughts on why querying on a View that is created that uses the table function might be generating and holding onto classes whereas using the same query with the View name replaced by the table function name does not have this problem? I much appreciate the feedback and thoughts. Brett -----Original Message----- From: Knut Anders Hatlen [mailto:[email protected]] Sent: Wednesday, November 21, 2012 8:28 AM To: [email protected] Subject: Re: Have Derby Network Server having an out of memory (PermGen) "Bergquist, Brett" <[email protected]> writes: > I have a customer that is periodically having a problem and unknown to > me, they have been accessing the Derby database using a query such as > in the following and have been repeatedly experienced a server issue. > I finally figured out it was an OutOfMemory error (PermGen). So I just > wrote a little application that performs the same query over and over > against a copy of the database and the Derby Network Server. In just a > few hours, the Derby Network Server gave up the ghost with a > OutOfMemory(PermGen) error. > > This is running against Derby 10.8.2.2. There is no other access to > the database from any other process during this test. > > Note that the query returns no data as there are no records in the > database that satisfy the query. Also, note that the table NPAResults > is actually a View that looks like: > [...] > > Each time I run this sample, after a few hours, the OutOfMemory > occurs. Any ideas on this will be greatly appreciated. Hi Brett, I don't see anything obvious that should cause problems in the code you posted. I tried to run it myself, but it didn't seem to cause any leak in my environment. Of course, I didn't run the exact same code, since I don't know exactly what your table function does. (And I ran it with -XX:MaxPermSize=16M since I didn't want to wait for hours to see the result...) If you manage to come up with a full repro that others could run, it might be easier to see what's going on. By the way, have you changed the statement cache size, or are you running with default size? I'm asking because the size of the statement cache will affect how soon generated classes can be garbage collected. -- Knut Anders
