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:bpendleton.de...@gmail.com] Sent: Wednesday, August 17, 2011 9:40 AM To: derby-dev@db.apache.org 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.
