"Bergquist, Brett" <[email protected]> writes: > A system running Solaris 10 using Derby 10.5.3 and JDK 1.6.0_05 has > had a OutOfMemory PermGen reported in derby.log a couple of times of > the past few months. This system has been running for over a year now > with no problems but the last few months this has been reported and > the system needed to be restarted. The only changes in the database > access have been a substantial increase in the number of database > records that have been inserted, deleted, and queried upon. There > have been no new derby classes (ie procedures or functions) loaded > into the system. The system runs about 2 weeks of constant access > that last time before this occurred again. > > So any ideas why it would be getting a PermGen error?
When Derby compiles a query, it generates and loads a new Java class for executing the query. The generated classes should be garbage collected when they're no longer in use, so they shouldn't normally fill the PermGen. But there's a cache which holds up to 100 compiled statement, so the PermGen footprint usually grows until the cache has been filled. There could of course be a leak, either in the application or in the Derby code. Running the Java process with -XX:+HeapDumpOnOutOfMemoryError and inspecting the heap dump may give some indications. -- Knut Anders
