Virtual Memory Problem! The application is running low on virtual memory.
a
anonymous
started a topic
about 16 years ago
[This topic is migrated from our old forums. The original author name has been removed]
I'm using version 6.0.15 with Java 6.1.0_07 against Sybase ASE 12.5. I am executing a stored procedure with SET SHOWPLAN ON. This resulted in the execution taking several minutes and the end result was an OutOfMemory error.
I decided to modify the dbvis.vmoptions and modify the amount of memory the application is given. It was initially set as -Xmx256m so I modified it to be -Xmx512m and received the same OutOfMemory error. As a last effort I modified it to be -Xmx1024m. I was hopeful as it ran for a longer duration but the end result was the same.
Sadly, I had to revert to DBArtisan to get my showplan. It takes several minutes to complete but it does complete, and it performs this with far less memory consumption, never exceeding 200m.
Below is the stack trace from the popup window.
----------------
Virtual Memory Problem! The application is running low on virtual memory.
Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at sun.java2d.SunGraphics2D.getClipBounds(Unknown Source)
at javax.swing.JComponent.paint(Unknown Source)
at javax.swing.JComponent.paintChildren(Unknown Source)
at javax.swing.JComponent.paint(Unknown Source)
at javax.swing.JComponent.paintChildren(Unknown Source)
at javax.swing.JComponent.paint(Unknown Source)
at javax.swing.JComponent.paintChildren(Unknown Source)
at javax.swing.JComponent.paint(Unknown Source)
at javax.swing.JComponent.paintChildren(Unknown Source)
at javax.swing.JComponent.paint(Unknown Source)
at javax.swing.JComponent.paintChildren(Unknown Source)
at javax.swing.JSplitPane.paintChildren(Unknown Source)
at javax.swing.JComponent.paint(Unknown Source)
at javax.swing.JComponent.paintChildren(Unknown Source)
at javax.swing.JComponent.paint(Unknown Source)
at javax.swing.JComponent.paintChildren(Unknown Source)
at javax.swing.JComponent.paint(Unknown Source)
at javax.swing.JComponent.paintChildren(Unknown Source)
at javax.swing.JComponent.paint(Unknown Source)
at javax.swing.JComponent.paintChildren(Unknown Source)
at javax.swing.JComponent.paint(Unknown Source)
at javax.swing.JComponent.paintChildren(Unknown Source)
at javax.swing.JComponent.paint(Unknown Source)
at javax.swing.JComponent.paintChildren(Unknown Source)
at javax.swing.JComponent.paint(Unknown Source)
at javax.swing.JComponent.paintChildren(Unknown Source)
at javax.swing.JComponent.paint(Unknown Source)
at javax.swing.JComponent.paintChildren(Unknown Source)
at javax.swing.JComponent.paint(Unknown Source)
at javax.swing.JComponent.paintChildren(Unknown Source)
at javax.swing.JComponent.paint(Unknown Source)
at javax.swing.JComponent.paintChildren(Unknown Source)
Re: Virtual Memory Problem! The application is running low on virtual memor
Chris,
What JDBC driver and version are you using?
It sounds strange that the memory can be an issue since the showplan is generally not that big. (I suspect the reason for the memory issue is caused by something else).
Best Regards
Roger
a
anonymous
said
about 16 years ago
[This reply is migrated from our old forums. The original author name has been removed]
Re: Virtual Memory Problem! The application is running low on virtual memor
Hi Roger,
I'm using the Sybase JConnect JDBC driver, latest version. However, in answer to your question, yes the show plan is that big. This is the result of executing a stored proc that performs an insert into a given table. Upon investigation I found that the triggers on this table are performing a large number of select statements as well as updates and inserts to other tables and executing other stored procs. If I execute the stored proc without the show plan, DBVis reports that over 12,000 statements were executed and over 446,000 rows were effected. OUCH!!!!!!!!!
We are trying to trace down that fiasco, but in regards to the show plan, when I got it to execute in DB Atrisan, it produced a plan that was over 4M is size with over 63,000 lines.
I saw DBVis error on some runs with an out of memory error pertaining to JDOM, so my guess is because of the size of the show plan, there simply isn't enough memory to allocate.
Thanks for the help....
Roger Bjärevall
said
about 16 years ago
[This reply is migrated from our old forums.]
Re: Virtual Memory Problem! The application is running low on virtual memor
Chris,
You can try exporting the show plan using the @export client side command. This can be used to handle really large result sets.
@export on;
@export set filename="C:\plan.csv" format="CSV";
set showplan on;
Read more in:
[http://www.dbvis.com/products/dbvis/doc/main/doc/ug/sqlCommander/sqlCommander.html#mozTocId448386]
Best Regards
Roger
a
anonymous
said
over 10 years ago
[This reply is migrated from our old forums. The original author name has been removed] [Attachment has been removed.]
Re: Virtual Memory Problem! The application is running low on virtual memor
DbVis Software Support,
I am having the same difficulty. Whenever we attempt to load a large MySQL database file (i.e. > 500 MB ), we receive this same error, which reads: java.lang.OutOfMemoryError: Java heap space. I have attached the error log below. Please advise how we can resolve this error.
--------------
An error occurred while executing the database request for:
Short message:
An error occurred while performing the operation:
java.lang.OutOfMemoryError: Java heap space
Long Message:
java.lang.OutOfMemoryError: Java heap space
Details:
Type: java.util.concurrent.ExecutionException
Stack Trace:
java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError: Java heap space
at java.util.concurrent.FutureTask.report(Unknown Source)
at java.util.concurrent.FutureTask.get(Unknown Source)
at javax.swing.SwingWorker.get(Unknown Source)
at com.onseven.dbvis.J.B.K.?(Z:990)
at com.onseven.dbvis.J.B.K.?(Z:1521)
at com.onseven.dbvis.J.B.K$3.run(Z:3032)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$200(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at com.onseven.dbvis.N.A.a.dispatchEvent(Z:2787)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.WaitDispatchSupport$2.run(Unknown Source)
at java.awt.WaitDispatchSupport$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.WaitDispatchSupport.enter(Unknown Source)
at java.awt.Dialog.show(Unknown Source)
at com.jidesoft.dialog.StandardDialog.show(Unknown Source)
at java.awt.Component.show(Unknown Source)
at java.awt.Component.setVisible(Unknown Source)
at java.awt.Window.setVisible(Unknown Source)
at java.awt.Dialog.setVisible(Unknown Source)
at com.onseven.dbvis.J.B.A.I.?(Z:2996)
at com.onseven.dbvis.f.A.B.?(Z:927)
at com.onseven.dbvis.f.A.B.?(Z:824)
at com.onseven.dbvis.B.C.?(Z:833)
at com.onseven.dbvis.B.B.?(Z:3559)
at com.onseven.dbvis.E.E.?(Z:1902)
at com.onseven.dbvis.B.B.?(Z:663)
at com.onseven.dbvis.E.G.?(Z:3249)
at com.onseven.dbvis.k.A.C.?(Z:3315)
at com.onseven.dbvis.k.A.A.?(Z:3287)
at com.onseven.dbvis.A.?(Z:847)
at com.onseven.dbvis.A.?(Z:2517)
at com.onseven.dbvis.B.?(Z:1938)
at com.onseven.dbvis.DbVisualizerGUI$2.run(Z:1177)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$200(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at com.onseven.dbvis.N.A.a.dispatchEvent(Z:2787)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.lang.OutOfMemoryError: Java heap space
at javax.swing.text.GapContent.allocateArray(Unknown Source)
at javax.swing.text.GapVector.resize(Unknown Source)
at javax.swing.text.GapVector.shiftEnd(Unknown Source)
at javax.swing.text.GapContent.shiftEnd(Unknown Source)
at javax.swing.text.GapVector.open(Unknown Source)
at javax.swing.text.GapVector.replace(Unknown Source)
at javax.swing.text.GapContent.insertString(Unknown Source)
at javax.swing.text.AbstractDocument.handleInsertString(Unknown Source)
at javax.swing.text.AbstractDocument.insertString(Unknown Source)
at javax.swing.text.PlainDocument.insertString(Unknown Source)
at com.onseven.dbvis.f.A.B$C.?(Z:1215)
at com.onseven.dbvis.J.B.A.I.execute(Z:2291)
at com.onseven.dbvis.J.B.Y.?(Z:1386)
at com.onseven.dbvis.J.B.K.?(Z:1374)
at com.onseven.dbvis.J.B.K.doInBackground(Z:1521)
at javax.swing.SwingWorker$1.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at javax.swing.SwingWorker.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
System Information:
Product: DbVisualizer Free 9.1.9
Build: #2154 (2014/06/16 16:42)
Java VM: Java HotSpot(TM) 64-Bit Server VM
Java Version: 1.7.0_60
Java Vendor: Oracle Corporation
OS Name: Windows 8
OS Arch: amd64
OS Version: 6.2
Roger Bjärevall
said
over 10 years ago
[This reply is migrated from our old forums.]
Re: Virtual Memory Problem! The application is running low on virtual memor
Ryan,
Loading a 500MB file into the editor in DbVisualizer would require a lot of RAM allocated to the Java VM. If you are looking to execute the script I suggest you instead check the @run client-side command. It will not load the actual file into DbVisualizer but instead stream the file through DbVisualizer while executing it. It doesn't require much memory to process the script.
Read more in:
http://confluence.dbvis.com/display/UG91/Executing+an+External+Script
Note that @run requires the licensed Pro edition. Sign-up for a testing period in Help->Evaluate Pro Edition.
Regards
Roger
a
anonymous
said
over 10 years ago
[This reply is migrated from our old forums. The original author name has been removed]
Re: Virtual Memory Problem! The application is running low on virtual memor
Roger,
I noticed that the evaluation trial period for DbVisualizer is only for three weeks (until July 15th). We may potentially need to use DbVisualizer for more than three weeks.
Is there (1) any way to load the 500 MB database to DbVisualizer without using the @run client-side command? And (2) is there any way to use the @run client-side command without purchasing the Pro edition of DbVisualizer? If the answer to the second is no then we may need to purchase DbVizualizer. If the answer the first is no, then we may not wish to do so.
Thank you for your assistance.
Sincerely,
Ryan Haecker
Roger Bjärevall
said
over 10 years ago
[This reply is migrated from our old forums.]
Re: Virtual Memory Problem! The application is running low on virtual memor
Ryan,
You said initially you are loading a MySQL "database". Are you referring to a database file rather than a SQL script that I (silently) assumed?
If it is an SQL script with INSERT statements I suggest you look at using the MySQL command line interface as it is optimized to run large MySQL scripts.
The evaluation period is 21 days as it is solely for testing the features in DbVisualizer before purchasing.
Let me know the answer to my first question above.
Regards
Roger
anonymous