Open https://issues.apache.org/jira/browse/DERBY-5387 and attached the Netbeans project for the utility along with two reports from Eclipse MemoryAnalyzer to for the suspected leak.
-----Original Message----- From: Rick Hillegas [mailto:[email protected]] Sent: Wednesday, August 17, 2011 2:57 PM To: [email protected] Subject: Re: Question on unloading in an embedded environment On 8/17/11 11:03 AM, Bergquist, Brett wrote: > I have a report generated by MemoryAnalyzer (Eclipse) tool. The report is > stored as a zip file that contains the HTML and images. Can I attach this to > an email? Hi Brett, If it's big, I would recommend attaching it to a JIRA issue. Thanks, -Rick > I have attached a JPG of some of the report here. > > > > -----Original Message----- > From: Bergquist, Brett [mailto:[email protected]] > Sent: Wednesday, August 17, 2011 11:16 AM > To: [email protected] > Subject: RE: Question on unloading in an embedded environment > > So this is running on Solaris 10 Java 1.6.0_22 with "-d64 -Xmx8129m > -XX:+HeapDumpOnOutOfMemory" Unfortunately the heap dump is so large it take > 32Gb for jhat to load it and then forever for look at anything. I am running > the app again with a smaller heap to get the problem to occur quicker and > with a smaller heap dump to be able to get a allocation traceback. > > -----Original Message----- > From: Bergquist, Brett [mailto:[email protected]] > Sent: Wednesday, August 17, 2011 10:49 AM > To: [email protected] > Subject: RE: Question on unloading in an embedded environment > > This was run with 8gb of heap available. The system is a Oracle M3000 with > 32Gb of real ram. It did not run out of swap while running, so it hit the > heap max. > > Why would the sorter be called when doing a SYSCS_IMPORT_TABLE? That is all > this application is doing. It exports a table from one database with > SYSCS_EXPORT_TABLE and imports into the other database with > SYSCS_IMPORT_TABLE. No queries or other statements are being used. > > -----Original Message----- > From: Bryan Pendleton [mailto:[email protected]] > Sent: Wednesday, August 17, 2011 9:40 AM > To: [email protected] > Subject: Re: Question on unloading in an embedded environment > >> Instance Counts for All Classes (excluding platform) >> >> 38006784 instances of class org.apache.derby.impl.store.access.sort.Node > One possibility is that the sorter is confused about how much memory > is available. > > The sorter is very clever, and tries to figure out whether it can perform > the sort in-memory, or whether it has to switch to an external (disk-based) > sort, using temporary files to hold the partially-sorted data. > > If the sorter is confused about how much memory is available (i.e., thinks > there is more memory available than there actually is), then it might > drive the system out of memory. > > This would certainly be a bug, but not a leak exactly, rather a flaw > in the internal-vs-external sort analysis code. > > thanks, > > bryan > > P.S. I'm still wondering if your memory issues are actually external to > Derby; that is, if you've configured your JVM with memory sizes that exceed > the memory available in the underlying operating system. That would cause > Derby to attempt to allocate data structures that the JVM was willing to > allow, but which the underlying OS refused to provide. > > > > > >
