This content has been marked as final. Show 7 replies
Does anybody have any info on how to trace this issue? Logs? Crash reports? Console tricks?
I'm using windows 7 and sql developer 3.1.07 with jdk1.6.0_34
Since it appears to be a Java OutOfMemoryException, you probably do not need to worry about tracing or debugging. If you wish to confirm an OutOfMemoryException, just
You might see if adding an AddVMOption -Xmx<size> line to your sqldeveloper.conf file with a size greater than 640M helps. Otherwise, you could try tuning the Java VM's garbage collection algorithm as in this post:
//Example for Windows 1. Open a command line console. Adjust the properties so the console buffer size is at least 500 lines. 2. CD to your installation bin directory ( ...\sqldeveloper\sqldeveloper\bin). 3. set ORACLE_HOME=%CD% (This is optional - if you want to ensure use of the jdbc driver that ships with SQL Developer) 4. Launch sqldeveloper.exe (not sqldeveloperW.exe) so any debug messages appear in the console 5. Run your test case and when it hangs, do a Ctrl-Break from the console to get a full thread dump (This is optional)
Re: Memory Leak or Bad Java Garbage Collector
SQL Developer Team
The memory usage of SQL Developer seems ridiculous when compared to TOAD and PL/SQL Developer memory usage. Why in the world does SQL Developer consume 800MB when another developer tool like PL/SQL Developer consumes up to 50MB after performing the same queries and running the same amount of time? Is it due to Java garbage collection (or the lack there of)? PL/SQL Developer will unallocate memory over time where as SQL Developer does not appear to do so. It wouldn't be so bad except for the unresponsiveness that appears to correspond with the large memory usage. So, seriously, why?
I'm not really sure about PL/SQL Developer but, since it only runs on Windows and started off back in 1997, I assume it is a C++ based product. There is no C++ garbage collector -- the programmer is completely responsible for memory allocation and de-allocation -- so it may not be too surprising it uses less memory than a similar Java application (except SQL Developer has other areas of functionality: DBA, migration from 3rd party databases, data modeler, etc).
Java memory consumption has been a sore-point for years, but the impact has been reduced in many ways:
1. Better automatic garbage collection (see the other post above). Especially with Java 7.
2. Ever cheaper and abundant real memory.
3. 32-bit OS versions are less common now, 64-bit OS versions are more common.
4. Dynamic component model techniques. Component code is loaded into memory (with potential for unloading) as needed, not at start-up.
A future release of SQL Developer will probably take advantage of (4), so things will only get better.
Edited by: Gary Graham on Nov 28, 2012 3:01 PM
@Gary, thank you for the reply. I am going to try to run with the console running from now on so I can hope to get an idea what is happening. I wonder about this being an out of memory exception though - the spinning thread is very busy at 20% of my processor so if an exception did occur, something is not handling that exception well at all.
I'm also going to try the garbage collection tweaks.
I totally agree with b_levitt on this problem.
SQL Developer is a very good free tool (and keeps on going better faster than the concurrence) but the SQL Developer Team really need to do something about memory footprint.
When i start SQL Dev (with some plugins disabled), the heap size (visible with Jvisualvm from the JDK) is 35 Mo.
Then i do some work, open some connections and some worksheets (not so much, maybe less than 10 connections and 10 worksheets)
I close them all (connections and worksheets) and the used heap is still around 300 Mo and is unable to go back to its original size !!
I like Java's portability and ease of development but it really needs too much memory for what it really does !
Please do something about this at SQL Developer Team because otherwise this product has really become a strong stuff.
About PL/SQL Developer, i found it more ergonomic and in fact it consumes very few memory (it's built with delphi as far as i know about it).
But i experienced some problems with PL Dev (conflict with Windows explorer) that i never had with SQL Developer so i don't miss it that much.