MemoryOutOfError in jvm native heap
hi,
i am getting MemoryOutOfError at JVM native heap.
anybody tell me why this is coming ?
thanks
Rams
You need be more specific about your phenomenon.
For example:
OS Info
JVM Info
JVM Options
Full Error Message
GC Dump
There are many possible reasons for OOEM in native heap.
Thread stack size, JNI library, virtual memory space(somtimes by too big java heap size), file/socket open count, ...
Even highly-specialized expert might not be able to tell which one is the main reason without more detailed information.
Anyway, JVM forum might be more appropriate place for your question.
Similar Messages
-
How to find out what is using the native heap of a process running a JVM?
Hello,
I am not sure where to post this question so I am starting here.
I am troubleshooting a Java application using some native calls (32 bits Java running on Solaris 10). The size of the process (as reported by prstat) is slowly increasing day after day.
The size of the 'Java heap' is fixed at the start (-Xms and -Xmx are set to the same value on the command line when launching the Java app) and the GC is workling fine. No memory complaints from the Java side of the application.
It is the size of the 'native' heap (as reported by 'pmap') that is increasing:
root@mas01 # pmap 5382
5382:/apps/java/bin/java -server -Xms207M -Xmx207M -XX:MaxNewSize=24M -XX:N
00010000 64K r-x-- /apps/jdk1.5.0_19/bin/java
0002E000 16K rwx-- /apps/jdk1.5.0_19/bin/java
00032000 3896K rwx-- [ heap ]
00400000 389120K rwx-- [ heap ]
18000000 2784K rwx-- [ heap ]
DCAF4000 48K rw--R [ stack tid=169 ]
DCBF6000 40K rw--R [ stack tid=161 ]
DCCF8000 32K rw--R [ stack tid=160 ]
My first reaction was to search for a memory leak. Found a minor leak in the JVM with the ::findleak function (called within the mdb debugger). Upgraded to a later release of Java 5 (Java 1.5.0_19) where the leak is fixed but the heap is still increasing.
Many parts of the process allocate memory in the native heap. The JVM itself, the native calls made to a C++ library part of our Java application and maybe also some 3rd party software.
I would like to know what is the best way to find out what is consuming more and more memory in the native heap. I started looking a DTraces but I am new to this. I also thought maybe the Solaris Perftools might be of use but I never used them. Before plunging into a tool more or less blindly, I am asking for advices on how to tackle this issue. Can someone recommend a tool/method to see what is allocated in the heap?
Regards,
Stéphan
Edited by: StephanDupont on Sep 22, 2009 8:47 AMAfter googling a lot I managed to run my application with libumem, generated a core file and succeeded to find some leak with mdb even if ::findleak reported nothing.
Does anyone knows if the ::findleak (you need libumem and mdb) is supposed to find leak in the native part of the memory and a Java application using the JNI interface?
Regards,
Stéphan -
OutOfMemoryError in native heap ?
hi,
we are getting OutOfMemoryError in native heap.
till now we are not getting why this is happening.
my application is running on solaris 8 and jvm is 1.4.2,
i am not seeing any profiling tool to find this issue for this environment.
anybody used any profiling tool for solaris 8 and jvm 1.4.2
plz suggest me.
that will help to sort out my problem.
thanks
ramsWhat's the exact message you are seeing?
Try the tips in the Trouble-Shooting Guide:-
http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/toc.html
in particular this section:-
http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/memleaks.html -
Native heap exaustion under Linux 2.6.x
All,
We have an application that extensively uses Runtime.exec() in a multi-threaded
environment. Under both JRockit 1.4.2_8 and 1.4.2_10 x86 we observe steady growth
of resident and virtual memory occupied by JVM, as reported by top, that eventually
leads to the death of JVM.
Java heap behaves normally. The application that is repeatedly executed by Runtime.exec()
doesn't leak. That was confirmed by running it in a bash cycle.
I am wondering if this is a known problem and if there is a fix or a workaround
for this issue. If not, what are the ways to track down the problem?
Thanks.
SlavaCalling deleteOnExit() on a File adds that file to a list of files that the JVM should delete once it exits. Files are never
removed from this list. Thus, if you keep adding files to the list (by calling deleteOnExit()) you will run out of memory
eventually.That may be what the JVM code does. Here is what the documentation says:
================================================================
deleteOnExit
public void deleteOnExit()
Requests that the file or directory denoted by this abstract pathname be deleted when the
virtual machine terminates. Deletion will be attempted only for normal termination of the virtual
machine, as defined by the Java Language Specification.
Once deletion has been requested, it is not possible to cancel the request. This method
should therefore be used with care.
Note: this method should not be used for file-locking, as the resulting protocol cannot
be made to work reliably. The FileLock facility should be used instead.
Throws:
SecurityException - If a security manager exists and its SecurityManager.checkDelete(java.lang.String)
method denies delete access to the file
Since:
1.2
See Also:
delete()"
================================================================
As you can see, there is nothing in here that would alert that either there is
a list that may cause *native heap* overflow nor that actual deletions of the
file don't remove a file from the list. For all practical reasons it is a bug that
was lurking there since 2001:
http://bugs.sun.com/bugdatabase/view_bug.do;:YfiG?bug_id=4513817
Other JVM vendors such as IBM have taken care about this problem (see #97403):
http://www-1.ibm.com/support/docview.wss?uid=swg21221304
It would be nice if you guys looked at this issue.
Apart from that I am very pleased with JRockIt speed and improved stability - good
job!
Regards,
Slava Imeshev -
JVMDG315: JVM Requesting Heap dump file
Hi expert,
Using 10.2.04 Db with 11.5.10.2 on AIX 64 bit.
While running audit report which generate pdf format output gone in error....
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
..............................JVMDG318: Heap dump file written to /d04_testdbx/appltop/testcomn/admin/log/TEST_tajorn3/heapdump7545250.1301289300.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to /d04_testdbx/appltop/testcomn/admin/log/TEST_tajorn3/javacore7545250.1301289344.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
JVMST109: Insufficient space in Javaheap to satisfy allocation request
Exception in thread "main" java.lang.OutOfMemoryError
at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java(Compiled Code))
at java.io.OutputStream.write(OutputStream.java(Compiled Code))
at oracle.apps.xdo.common.log.LogOutputStream.write(LogOutputStream.java(Compiled Code))
at oracle.apps.xdo.generator.pdf.PDFStream.output(PDFStream.java(Compiled Code))
at oracle.apps.xdo.generator.pdf.PDFGenerator$ObjectManager.write(PDFGenerator.java(Compiled Code))
at oracle.apps.xdo.generator.pdf.PDFGenerator$ObjectManager.writeWritable(PDFGenerator.java(Inlined Compiled Code))
at oracle.apps.xdo.generator.pdf.PDFGenerator.closePage(PDFGenerator.java(Compiled Code))
at oracle.apps.xdo.generator.pdf.PDFGenerator.newPage(PDFGenerator.java(Compiled Code))
at oracle.apps.xdo.generator.ProxyGenerator.genNewPageWithSize(ProxyGenerator.java(Compiled Code))
at oracle.apps.xdo.generator.ProxyGenerator.processCommand(ProxyGenerator.java(Compiled Code))
at oracle.apps.xdo.generator.ProxyGenerator.processCommandsFromDataStream(ProxyGenerator.java(Compiled Code))
at oracle.apps.xdo.generator.ProxyGenerator.close(ProxyGenerator.java:1230)
at oracle.apps.xdo.template.fo.FOProcessingEngine.process(FOProcessingEngine.java:336)
at oracle.apps.xdo.template.FOProcessor.generate(FOProcessor.java:1043)
at oracle.apps.xdo.oa.schema.server.TemplateHelper.runProcessTemplate(TemplateHelper.java:5888)
at oracle.apps.xdo.oa.schema.server.TemplateHelper.processTemplate(TemplateHelper.java:3593)
at oracle.apps.pay.pdfgen.server.PayPDFGen.processForm(PayPDFGen.java:243)
at oracle.apps.pay.pdfgen.server.PayPDFGen.runProgram(PayPDFGen.java:795)
at oracle.apps.fnd.cp.request.Run.main(Run.java:161)
oracle.apps.pay.pdfgen.server.PayPDFGen
Program exited with status 1
No any error in db alert ...
Pleaes suggest where is prob..
Thanks in ADVHello,
* JVMST109: Insufficient space in Javaheap to satisfy allocation request
Exception in thread "main" java.lang.OutOfMemoryError
This is your problem. There is no enough memory. Change Java heap settings
Regards,
Shomoos
Edited by: shomoos.aldujaily on Mar 29, 2011 12:39 AM -
Advanced: JVM native methods
Please note: this topic has nothing to do with JNI or reflection.
In the java.lang.Throwable class there is:
private native StackTraceElement getStackTraceElement(int index);
The simplest solution to Java Bug 6349551 is to change this method from private to public. I'm prepared to contribute this change to Mustang.
However, I'm looking for peer input first as I can't find a lot of information about JVM native methods.
My question is: Are there good reasons to avoid directly exposing JVM native methods? I'm most interested in this specific case, but would also like to learn more about the issues in general.
Also, my bug posting includes an alternative approach which wraps getStackTraceElement() instead. Is that a better approach, and if so, why?See my comment in bug database.
-
Sudden increase in native heap memory
Hi all,
we are using JRockit 26.4 and currently configured with 1800MB heap on windows 2003 with /3GB switch.
We noticed that after the weblogic server is started the total memory (java heap + native memory) lingers around 2550 MB... (We monitored this using perfmon -> virtual bytes of java process)
after couple of days run, the native memory suddenly increased by 300 MB, taking the total virtual bytes to 2850 MB.
Do we know what could be the reason for such a sudden increase?
Thanks,
- Pritam.I don't believe this is documented anywhere unfortunately, and it might vary depending on the exact JRockit release. But the key thing to watch out for is growth, regardless of which component it is. If you see that, post a question here and we'll find someone to tell you what the issue is...
That said, here's an example printout and some guesses from my side.
[JRockit] memtrace is collecting data...
[JRockit] *** 0th memory utilization report
(all numbers are in kbytes)
Total mapped ;;;;;;; 860976
; Total in-use ;;;;;; 89816
;; executable ;;;;; 4400
;;; java code ;;;; 384; 8.7%
;;;; used ;;; 236; 61.6%
;; shared modules (exec+ro+rw) ;;;;; 8496
;; guards ;;;;; 180
;; readonly ;;;;; 3052
;; rw-memory ;;;;; 78132
;;; Java-heap ;;;; 65536; 83.9%
;;; Stacks ;;;; 1976; 2.5%
;;; Native-memory ;;;; 10619; 13.6%
;;;; java-heap-overhead ;;; 2056
;;;; codegen memory ;;; 576
;;;; classes ;;; 2048; 19.3%
;;;;; method bytecode ;; 219
;;;;; method structs ;; 277 (#5929)
;;;;; constantpool ;; 788
;;;;; classblock ;; 69
;;;;; class ;; 143 (#443)
;;;;; other classdata ;; 338
;;;;; overhead ;; 91
;;;; threads ;;; 6; 0.1%
;;;; malloc:ed memory ;;; 1445; 13.6%
;;;;; codeinfo ;; 60
;;;;; codeinfotrees ;; 24
;;;;; exceptiontables ;; 5
;;;;; metainfo/livemaptable ;; 243
;;;;; codeblock structs ;; 0
;;;;; constants ;; 0
;;;;; livemap global tables ;; 135
;;;;; callprof cache ;; 0
;;;;; paraminfo ;; 30 (#506)
;;;;; strings ;; 426 (#8402)
;;;;; strings(jstring) ;; 0
;;;;; typegraph ;; 27
;;;;; interface implementor list ;; 5
;;;;; thread contexts ;; 8
;;;;; jar/zip memory ;; 497
;;;;; native handle memory ;; 5
;;;; unaccounted for memory ;;; 4493; 42.3%;3.11
---------------------!!!Total mapped means mapped virtual memory, eg the largest size the JVM can be expected to grow to. This is typically on the same order of magnitude as the Java heap size (Xmx).
Total in-use is the actual memory in use, this is the current "memory footprint" of your process.
executable refers to JIT compiled code, I believe.
Java-heap is the heap (duh).
Stacks should be the thread stacks (where local variables are stored).
classes is native memory used to store bytecode etc. If this grows, it may be because you are generating classes dynamically and they are not getting cleaned up because there are still live instances. Or maybe you're running with -Xnoclassgc.
threads can grow if you start a lot of threads and don't let them die.
Stuff under malloc:ed memory is mainly misc JVM metadata.
unaccounted for memory is...everything else. The most common leak involving unaccounted-for is native byte buffers (DirectByteBuffer).
-- Henrik -
DPS 6.x jvm memory heap size?
I am setting up directory proxy server 6.3 and have the java setting for memory heap size in my notes from testing last year. Is it important to set this? Is the argument as stated ok? And is 500 ok? Doubt anything has changed since last year, but want to be sure. Thanks.
dpadm set-flags /opt/dps jvm-args="-Xmx500M -Xms500M -XX:NewRatio=1"crosspost
-
JVM Java heap space Error || even with -Xms- and -Xmx commands
hi all, i got a problem by allocating a very great boolean array.
first of all, here is my testcode:
public static void main(String[] args) {
boolean[] testfield = new boolean[70000000];
while(true){
//NOP
}as you see, i try to allocate an array with 70.000.000 boolean values - as 1 boolean may be represented as at least one physical bit we calculate the total amount of needed RAM-Space:
70.000.000 bit / 8 = 8750000 byte
8.750.000 byte = 8.75 MByte
My System ist WinVista Ultimate 64-bit running on a Quadcore T2200 with 2GB-DDR3 RAM
Looking in my Vista Ressourcemanager shows, that eclipse.exe reserves about 1.023 Mbyte....
As IDE I use eclipse
my eclipse.ini looks as follows:
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256M
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms512m
-Xmx1024m
-XX:PermSize=512mby using following VMCommand "-XX:+PrintGCDetails" and running the above code the output displays:
[GC [DefNew: 180K->63K(960K), 0.0008311 secs][Tenured: 43K->107K(4096K), 0.0060371 secs] 180K->107K(5056K), 0.0069249 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
[Full GC [Tenured: 107K->105K(60544K), 0.0044835 secs] 107K->105K(61504K), [Perm : 17K->16K(12288K)], 0.0045553 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at termain.main(termain.java:15)
Heap
def new generation total 4544K, used 163K [0x246a0000, 0x24b80000, 0x24b80000)
eden space 4096K, 4% used [0x246a0000, 0x246c8fe0, 0x24aa0000)
from space 448K, 0% used [0x24aa0000, 0x24aa0000, 0x24b10000)
to space 448K, 0% used [0x24b10000, 0x24b10000, 0x24b80000)
tenured generation total 60544K, used 105K [0x24b80000, 0x286a0000, 0x286a0000)
the space 60544K, 0% used [0x24b80000, 0x24b9a420, 0x24b9a600, 0x286a0000)
compacting perm gen total 12288K, used 16K [0x286a0000, 0x292a0000, 0x2c6a0000)
the space 12288K, 0% used [0x286a0000, 0x286a41c0, 0x286a4200, 0x292a0000)
ro space 8192K, 62% used [0x2c6a0000, 0x2cba2ba0, 0x2cba2c00, 0x2cea0000)
rw space 12288K, 52% used [0x2cea0000, 0x2d4e88e0, 0x2d4e8a00, 0x2daa0000)so can anyone tell me please, how i manage to allocate bigger arrays? or where at least is the problem?
Originally i was thinking like that way: Integer.MAXVALUE = (2^32)-1
=> biggest index an array can have
=> biggest allocation possible with ints weights (((2^32)-^1)/8)/1000*1000 = (round) 537 MByte < 2GByte => everything fine .... but it seems like not :-(
When i try to allocate 60.0000.000 it works fine....but that is far not enough :-&
thank you very much for your helping answers!The Sun Java virtual machine stores booleans as bytes, not bits, so for an array of 70 million booleans you need 70 million bytes, plus 8 bytes for the object header, and 4 bytes for the array length.
I suspect that your eclipse.ini controls the JVM running the Eclipse IDE, not the JVM running your application. Note that in the -XX:+PrintGCDetails output at the end, it shows you running out of memory with 4MB of young generation and 60MB of old generation. That's the default configuration, as if you hadn't specified -Xms and -Xmx.
The array of 60 million booleans only requires 60 million bytes (plus overhead), which fits in the default old generation.
I think you need to put the -Xms and -Xmx in the same place you put the -XX:+PrintGCDetails, since that does seem to display information about the JVM running your application, not the JVM running Eclipse. -
JVM OutOfMemory Heap Suddenly Rises
Hi,
Can anyone help me step by step to solve the Out Of Memory Issue we are facing in our application.
After the restart the JVM runs perfectly fine for first 2 days ,the heap stablizes at 50%,but from 3rd day onward it starts shooting up and by 4th day it goes OOM.Earlier it was stable for 4 days and then 5th day it goes OOM and now it has become worse.
I am wondering if its really a memory leak in my applicaiton or the following possibilities
-fragmentation
-cache overflow
-inefficient garbage collection
Also i have noticed that the rate of full GC increases sharply after 2 days .I would be glad if someone could guide me step by step to find the root cause and solve the problem as i belive most of you here are the experts.
Our application run on websphere 6 ,max heap 1g ,min heap 1g,default garbage collection.
Thanks,
DammieeNewAlso i forgot to mention we have 8jvms on two servers..
If i take one snapshot for 3 days using jstat this is wat i see ...
Day1 heap 51.87% FullGC 94
Day2 heap 51.37% FullGC 265
Day3 heap 94.34 FullGC 1758 (See the increase in heap ..)
I am not an expert in this matter so my questions will be basic and plain.Please tolerate with me.Thanks!! -
I would like to be able to see what happened to the JVM's heap following a
performance test.
I'm really only interested in amount of heap used (ideally for each area of
the heap - in 1.3 onwards). If I could get this figure regularly (say every
5 seconds) I would be able to plot and see from the graph whether I have too
little or too much heap.
Is verbosegc the best way to do this i.e. just get the figures either side
of a gc? Or is there a better way? I don't want a GUI tool as the runs can
take hours and I want to be able to sleep! Just something that outputs to a
file.
Thanks in advance for all advice
Ed"Ed Barrett" <[email protected]> wrote:
I would like to be able to see what happened to the JVM's heap following
a
performance test.
I'm really only interested in amount of heap used (ideally for each area
of
the heap - in 1.3 onwards). If I could get this figure regularly (say
every
5 seconds) I would be able to plot and see from the graph whether I have
too
little or too much heap.
Is verbosegc the best way to do this i.e. just get the figures either
side
of a gc? Or is there a better way? I don't want a GUI tool as the runs
can
take hours and I want to be able to sleep! Just something that outputs
to a
file.
Thanks in advance for all advice
Ed
Verbosegc is a good option. Here is how you can do it. Set the heap size to one
of your lower settings. Turn on verbosegc. See how frequently you collect GC.
If you never do it then you do not use a high amount of memory. If the GC is too
frequent then your heap size is small. -
What would make a JVM memory size 1.9GB ?
This is on Solaris 2.6, JDK 1.2.2_05a, JDK1.2.2_07, possibly JDK 1.3 (it crashed).
WLS 5.1, SP8. With inline_instrs_jit=0.
This is the [heap] segment shown by /usr/proc/bin/pmap. This is native heap, it is
NOT the Java Heap.
I know it could be the Type 2 db drivers - but I doubt it.
With JDK1.3 we set -XX:MaxPermSize=128m - it crashes after an hour.
One part of the application creates its own threads for some parallel processing.
Is this a known
problem with the JVMs?
Any help is much appreciated.
Mike ReicheWhat is the 'Break difference' that the debug JVM shows? Is that the Java Heap? Or
is memory in the C Heap that is wasted by fragmentation?
============== C Heap Report ========================
mmap space 300515328
Committed space 95690752
Allocated space 34049316
Break difference 66060288
Breakdown by type:
ClassSpace 15252128
JITCompiledStackMaps 5277188
StackMap 1892672
Dependency 1856760
utf8_space 1854838
untagged 1783520
basicBlocksState 1664992
utf8_table 1055903
Class 811520
JITPrestub 610480
NearClass 531360
CardObjectTable 386048
JavaStack 257024
CheckingDone 200367
SummaryCardTable 193024
name_loader_cache_entry 65976
ScratchRecord 65548
basic_block_t 50896
IntfMethodTable 48960
stringTableOverflowRecord 46480
BitVectorElem 32768
ObjectMap 30724
ClassName 28407
Clinit 18752
Table_mem 18628
LoaderConstraintsTableEntry 11668
JITInlineByteCode 1928
LoaderConstraintsTableLoaderEntry 520
stateVecBuf 237
=====================================================
Total GC time: 2987981 ms
- Mike
"[email protected]" Mike wrote:
>
>
Aslo - GC[1] are taking way long (Debug JVM) - I'm used to seeing them taking
500
ms with the regular JVM. With -ms32m -m256m - I wanted GC[1] to run often
because
that has helped with other memory problems in the past - it doesn't work
so hot here.
GC[1] in 5514 ms: (38Mb, 0% free) -> (38Mb, 69% free)
GC[1] in 6300 ms: (38Mb, 0% free) -> (38Mb, 65% free)
GC[1] in 7130 ms: (38Mb, 0% free) -> (38Mb, 64% free)
GC[1] in 6158 ms: (38Mb, 2% free) -> (38Mb, 62% free)
GC[1] in 6171 ms: (38Mb, 0% free) -> (38Mb, 65% free)
GC[1] in 6885 ms: (38Mb, 0% free) -> (38Mb, 64% free)
GC[1] in 7403 ms: (38Mb, 0% free) -> (38Mb, 61% free)
GC[1] in 689101:25:49 PM PST {218} - Evaluation is: true
GC[1] in 6545 ms: (38Mb, 1% free) -> (38Mb, 61% free)
GC[1] in 7459 ms: (38Mb, 0% free) -> (38Mb, 62% free)
GC[1] in 6861 ms: (38Mb, 2% free) -> (38Mb, 58% free)
GC[1] in 6090 ms: (38Mb, 0% free) -> (38Mb, 56% free)
GC[1] in 6413 ms: (38Mb, 0% free) -> (38Mb, 60% free)
GC[1] in 8230 ms: (38Mb, 1% free) -> (38Mb, 58% free)
GC[1] in 7649 ms: (38Mb, 0% free) -> (38Mb, 54% free)
GC[1] in 7912 ms: (38Mb, 0% free) -> (38Mb, 55% free)
GC[1] in 7696 ms: (38Mb, 1% free) -> (38Mb, 57% free)
GC[1] in 6543 ms: (38Mb, 1% free) -> (38Mb, 60% free)
GC[1] in 7036 ms: (38Mb, 1% free) -> (38Mb, 59% free)
GC[1] in 7483 ms: (38Mb, 0% free) -> (38Mb, 56% free)
GC[1] in 5132 ms: (38Mb, 1% free) -> (38Mb, 59% free)
GC[1] in 8186 ms: (38Mb, 0% free) -> (38Mb, 53% free)
GC[1] in 5691 ms: (38Mb, 0% free) -> (38Mb, 58% free)
GC[1]01:35:49 PM PST {575} - Evaluation is: true
GC[1] in 8176 ms: (38Mb, 0% free) -> (38Mb, 46% free)
GC[1] in 8463 ms: (38Mb, 0% free) -> (38Mb, 47% free)
GC[1] in 7342 ms: (38Mb, 0% free) -> (42Mb, 41% free)
GC[1] in 6920 ms: (42Mb, 0% free) -> (49Mb, 41% free)
GC[1] in 8610 ms: (49Mb, 1% free) -> (60Mb, 40% free)
GC[1] in 9581 ms: (60Mb, 1% free) -> (60Mb, 50% free)
GC[1] in 10514 ms: (60Mb, 0% free) -> (60Mb, 59% free)
GC[1] in 9865 ms: (60Mb, 0% free) -> (60Mb, 60% free)
GC[1] in 11323 ms: (60Mb, 0% free) -> (60Mb, 57% free)
GC[1] in 18768 ms: (60Mb, 0% free) -> (60Mb, 60% free)
GC[1] in 11147 ms: (60Mb, 0% free) -> (60Mb, 55% free)
GC[1] in 7293 ms: (60Mb, 0% free) -> (60Mb, 42% free)
GC[1] in 9372 ms: (60Mb, 0% free) -> (60Mb, 53% free)
GC[1] in 8814 ms: (60Mb, 0% free) -> (60Mb, 55% free)
GC[1] in 9695 ms: (60Mb, 1% free) -> (60Mb, 54% free)
GC[1] in 7309 ms: (60Mb, 0% free) -> (60Mb, 53% free)
GC[1] in 8713 ms: (60Mb, 0% free) -> (60Mb, 54% free)
GC[1] in 11955 ms: (60Mb, 0% free) -> (60Mb, 55% free)
GC[1] in 12685 ms: (60Mb, 1% free) -> (60Mb, 55% free)
GC[1] in 18906 ms: (60Mb, 0% free) -> (60Mb, 58% free)
GC[1] in 13333 ms: (60Mb, 0% free) -> (60Mb, 51% free)
"[email protected]" <[email protected]> wrote:
Rob -
Thanks for your attention -
We create lots of threads - up to five threads for each DB hit (i didn't
design it).
The multi-threading will be disabled/removed and tested later on today.
Both 'top'
and pstack show around 85 threads.
I've read articles on the bea newsgroups about WL hanging on to threadreferences
so that the threads could not be GC'ed, but it sounded more like a customer's
impression
of what might be going on than something from BEA engineering.
Right now we are running with the 1.2.2_05a 'Debug' JVM with -verbose:gc
-verbose:gc
-verbose:gc
JVMARGS=verbose_c_heap,inline_instrs_jit=0
Unfortunately, some of the code being tested is now broken and not being
excercised
today. I will keep you posted.
- Mike
Rob Woollen <[email protected]> wrote:
How many threads are you creating?
Each thread uses some memory (stack etc.), but 1.9GB would be a lot of
thread creation.
-- Rob
Mike Reiche wrote:
This is on Solaris 2.6, JDK 1.2.2_05a, JDK1.2.2_07, possibly JDK 1.3
(it
crashed).
WLS 5.1, SP8. With inline_instrs_jit=0.
This is the [heap] segment shown by /usr/proc/bin/pmap. This is nativeheap, it is
NOT the Java Heap.
I know it could be the Type 2 db drivers - but I doubt it.
With JDK1.3 we set -XX:MaxPermSize=128m - it crashes after an hour.
One part of the application creates its own threads for some parallelprocessing.
Is this a known
problem with the JVMs?
Any help is much appreciated.
Mike Reiche--
Coming Soon: Building J2EE Applications & BEA WebLogic Server
by Michael Girdley, Rob Woollen, and Sandra Emerson
http://learnweblogic.com -
Hi,
I am investigating a problem where we experience continual growth of our JVM process. The overall process size and native heap size of the JVM process continually grow at the same rate. I am monitoring these using the commands 'ps - o pid,vsz,rss' and 'pmap -x' respectively. The increases are in multiples of 8Kb.
I have checked our java application using Optimizeit and it is not leaking memory. I have also monitored the size of the VM java heap using the '-verbose:gc' garbage collection debugging option. Garbage collection appears normal and the VM heap size remains below that specified by the '-Xmx' option.
It appears that the memory growth is occurring in native code of the JVM process but I am at a loss on how to determine what is causing this. Can anyone advise me what may be causing this JVM process growth or ways in which I may be able to find this out?
I am using JRE 1.4.2 SE (1.4.2_08_b03) on Solaris 8. Within the JVM we are running our web app in Tomcat 4.1.
The shared libraries loaded by the JVM (as shown by pldd) are:
/usr/lib/libthread.so.1
/usr/lib/libdl.so.1
/usr/lib/libc.so.1
/usr/platform/sun4u/lib/libc_psr.so.1
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/client/libjvm.so
/usr/lib/libCrun.so.1
/usr/lib/libsocket.so.1
/usr/lib/libnsl.so.1
/usr/lib/libm.so.1
/usr/lib/libsched.so.1
/usr/lib/libmp.so.2
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/native_threads/libhpi.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libverify.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libjava.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libzip.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libjdwp.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libdt_socket.so
/usr/lib/nss_files.so.1
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libnet.so
/vob/ntg-thirdparty/tibco/rv-7.1/sol28/lib/libtibrvj.so
/vob/ntg-thirdparty/tibco/rv-7.1/sol28/lib/libtibrvcmq.so
/vob/ntg-thirdparty/tibco/rv-7.1/sol28/lib/libtibrvcm.so
/vob/ntg-thirdparty/tibco/rv-7.1/sol28/lib/libtibrvft.so
/vob/ntg-thirdparty/tibco/rv-7.1/sol28/lib/libtibrv.so
/usr/lib/libpthread.so.1
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libnio.so
/usr/lib/librt.so.1
/usr/lib/libaio.so.1
/usr/lib/libsendfile.so.1
/vob/ntg/dev/resources/lib/sol8gcc/libjavaperljni.so
/vob/ntg/dev/thirdparty/perl-5.8.0-gcc-thread/lib/libperl.so
/usr/lib/libw.so.1
/vob/ntg/dev/resources/lib/sol8gcc/libstdc++.so.2.10.0
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libioser12.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libawt.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libmlib_image.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/headless/libmawt.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libcmm.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libfontmanager.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libdcpr.so
/vob/ntg-thirdparty/java/j2sdk1.4.2_08/jre/lib/sparc/libjpeg.so
Any Help is much appreciated.Hi
If u can, use 1.4.2_10 (latest as of now). There is a bug 6250517, fixed in _09. Not sure if u r making any calls to NetworkInterface.getNetworkInterfaces.
Also noticed that you are using tibco. How about putting -Xcheck:jni and see if it picks up anything.
Unfortunately Solaris 8 didnt have libumem for tracking memory allocation. If u have any Solaris 9/10 boxes, you can use libumem to track it down.
http://access1.sun.com/techarticles/libumem.html -
hi all
ebs:11.5.10.2
db:9i
AIX 5 64-bit
we have 5 target process and 4 actual process
all the actual process are struck and one one is active
and log file of one process out 3 struck is (other 2 logs are same)
[6/20/11 9:12:44 PM] [15905:RT2458306] Starting XML Publisher post-processing action.
[6/20/11 9:12:44 PM] [15905:RT2458306]
Template code: XXXXXXXXXXXXX
Template app: WSH
Language: en
Territory: 00
Output type: PDF
java.lang.OutOfMemoryError
at oracle.ias.cache.DefaultCacheLogger.flushRecords(Unknown Source)
at oracle.ias.cache.DefaultCacheLogger.flushBuffer(Unknown Source)
at oracle.ias.cache.DefaultCacheLogger.flush(Unknown Source)
at oracle.ias.cache.CacheCleaner.run(Unknown Source)
java.lang.OutOfMemoryError
at oracle.apps.fnd.cp.opp.OPPRequestThreadManager.checkThreads(OPPRequestThreadManager.java(Compiled Code))
java.lang.OutOfMemoryError
at oracle.jdbc.driver.LRUStatementCache.addToImplicitCache(LRUStatementCache.java(Compiled Code))
at oracle.jdbc.driver.OracleConnection.cacheImplicitStatement(OracleConnection.java(Inlined Compiled Code))
at oracle.jdbc.driver.OraclePreparedStatement.privateClose(OraclePreparedStatement.java(Compiled Code))
at oracle.jdbc.driver.OraclePreparedStatement.close(OraclePreparedStatement.java(Compiled Code))
at oracle.jdbc.driver.OracleCallableStatement.close(OracleCallableStatement.java(Compiled Code))
at oracle.apps.fnd.cp.opp.OPPAQMonitor.waitForMessage(OPPAQMonitor.java(Compiled Code))
at oracle.apps.fnd.cp.opp.OPPAQMonitor.run(OPPAQMonitor.java(Compiled Code))
at java.lang.Thread.run(Thread.java:570)
java.lang.OutOfMemoryError
java.lang.OutOfMemoryError
java.lang.OutOfMemoryError
at oracle.apps.fnd.common.Pool.createObject(Pool.java(Compiled Code))
at oracle.apps.fnd.common.Pool.createAvailableObject(Pool.java(Compiled Code))
at oracle.apps.fnd.common.Pool.resize(Pool.java(Compiled Code))
at oracle.apps.fnd.common.Pool.run(Pool.java(Compiled Code))
at java.lang.Thread.run(Thread.java:570)
Exception: java.lang.OutOfMemoryError
java.lang.OutOfMemoryError
at oracle.ias.cache.group.Sender.run(Unknown Source)
java.lang.OutOfMemoryError
at oracle.jdbc.dbaccess.DBDataSetImpl._allocItemsAndBuffers(DBDataSetImpl.java(Compiled Code))
at oracle.jdbc.dbaccess.DBDataSetImpl._allocDataAndItems(DBDataSetImpl.java(Inlined Compiled Code))
at oracle.jdbc.dbaccess.DBDataSetImpl.setType(DBDataSetImpl.java(Compiled Code))
at oracle.jdbc.dbaccess.DBDataSetImpl.setType(DBDataSetImpl.java(Compiled Code))
at oracle.jdbc.driver.OracleCallableStatement.registerOutParameterBytes(OracleCallableStatement.java(Compiled Code))
at oracle.jdbc.driver.OracleCallableStatement.registerOutParameter(OracleCallableStatement.java(Inlined Compiled Code))
at oracle.jdbc.driver.OracleCallableStatement.registerOutParameter(OracleCallableStatement.java(Compiled Code))
at oracle.apps.fnd.cp.gsm.GenCartComm.getQueueMessage(GenCartComm.java:186)
at oracle.apps.fnd.cp.gsf.GSMStateMonitor.waitForNextEvent(GSMStateMonitor.java:95)
at oracle.apps.fnd.cp.gsf.GSMServiceController.mainLoop(GSMServiceController.java:236)
at oracle.apps.fnd.cp.gsf.BaseServiceController.run(BaseServiceController.java:71)
at java.lang.Thread.run(Thread.java:570)
[6/20/11 9:59:51 PM] [UNEXPECTED] [15905:RT2458306] java.lang.reflect.InvocationTargetException
Caused by: java.lang.OutOfMemoryError
at oracle.xdo.parser.v2.XPathDescendantAxis.getNodeList(XPathAxis.java(Compiled Code))
at oracle.xdo.parser.v2.XPathStep.evaluate(XPathStep.java(Compiled Code))
at oracle.xdo.parser.v2.PathExpr.evaluate(XSLNodeSetExpr.java(Compiled Code))
at oracle.xdo.parser.v2.XSLForEach.processAction(XSLForEach.java(Compiled Code))
at oracle.xdo.parser.v2.XSLNode.processChildren(XSLNode.java(Compiled Code))
at oracle.xdo.parser.v2.XSLResultElement.processAction(XSLResultElement.java(Compiled Code))
at oracle.xdo.parser.v2.XSLNode.processChildren(XSLNode.java(Compiled Code))
at oracle.xdo.parser.v2.XSLTemplate.processAction(XSLTemplate.java:191)
at oracle.xdo.parser.v2.XSLStylesheet.execute(XSLStylesheet.java:508)
at oracle.xdo.parser.v2.XSLStylesheet.execute(XSLStylesheet.java:485)
at oracle.xdo.parser.v2.XSLProcessor.processXSL(XSLProcessor.java:264)
at oracle.xdo.parser.v2.XSLProcessor.processXSL(XSLProcessor.java:150)
at oracle.xdo.parser.v2.XSLProcessor.processXSL(XSLProcessor.java:187)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java(Compiled Code))
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java(Compiled Code))
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code))
at java.lang.reflect.Method.invoke(Method.java(Compiled Code))
at oracle.apps.xdo.common.xml.XSLT10gR1.invokeProcessXSL(XSLT10gR1.java(Compiled Code))
at oracle.apps.xdo.common.xml.XSLT10gR1.transform(XSLT10gR1.java(Compiled Code))
at oracle.apps.xdo.common.xml.XSLT10gR1.transform(XSLT10gR1.java:233)
at oracle.apps.xdo.common.xml.XSLTWrapper.transform(XSLTWrapper.java:177)
at oracle.apps.xdo.template.fo.util.FOUtility.generateFO(FOUtility.java:1044)
at oracle.apps.xdo.template.fo.util.FOUtility.generateFO(FOUtility.java:997)
at oracle.apps.xdo.template.fo.util.FOUtility.generateFO(FOUtility.java:212)
at oracle.apps.xdo.template.FOProcessor.createFO(FOProcessor.java:1657)
at oracle.apps.xdo.template.FOProcessor.generate(FOProcessor.java:967)
at oracle.apps.xdo.oa.schema.server.TemplateHelper.runProcessTemplate(TemplateHelper.java:5888)
at oracle.apps.xdo.oa.schema.server.TemplateHelper.processTemplate(TemplateHelper.java:3438)
at oracle.apps.xdo.oa.schema.server.TemplateHelper.processTemplate(TemplateHelper.java:3527)
at oracle.apps.fnd.cp.opp.XMLPublisherProcessor.process(XMLPublisherProcessor.java:247)
at oracle.apps.fnd.cp.opp.OPPRequestThread.run(OPPRequestThread.java:157)
[6/20/11 9:59:51 PM] [15905:RT2458306] Completed post-processing actions for request 2458306.
java.lang.OutOfMemoryError
at java.io.ObjectOutputStream$HandleTable.growSpine(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream$HandleTable.assign(ObjectOutputStream.java(Inlined Compiled Code))
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java(Compiled Code))
at java.util.Vector.writeObject(Vector.java(Inlined Compiled Code))
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code))
at java.lang.reflect.Method.invoke(Method.java(Compiled Code))
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java(Compiled Code))
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java(Inlined Compiled Code))
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java(Compiled Code))
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java(Compiled Code))
at oracle.ias.cache.group.StreamHandler.write(Unknown Source)
at oracle.ias.cache.group.EndPoint.write(Unknown Source)
at oracle.ias.cache.group.Transport.syncMulticast(Unknown Source)
at oracle.ias.cache.group.Transport.multicast(Unknown Source)
at oracle.ias.cache.group.Transport.multicast(Unknown Source)
at oracle.ias.cache.group.Monitor.ping(Unknown Source)
at oracle.ias.cache.group.Monitor.run(Unknown Source)
DG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308591323.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308591369.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
JVMST109: Insufficient space in Javaheap to satisfy allocation request
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308591404.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308591451.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
JVMST109: Insufficient space in Javaheap to satisfy allocation request
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308591486.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308591533.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
JVMST109: Insufficient space in Javaheap to satisfy allocation request
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308591569.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308591614.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
JVMST109: Insufficient space in Javaheap to satisfy allocation request
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308591652.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308591700.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
JVMST109: Insufficient space in Javaheap to satisfy allocation request
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308591734.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308591780.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
JVMST109: Insufficient space in Javaheap to satisfy allocation request
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308591815.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308591861.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
JVMST109: Insufficient space in Javaheap to satisfy allocation request
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308591900.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308591946.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
JVMST109: Insufficient space in Javaheap to satisfy allocation request
JVMXE003
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308591981.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308592027.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
JVMST109: Insufficient space in Javaheap to satisfy allocation request
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308592061.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308592109.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
JVMST109: Insufficient space in Javaheap to satisfy allocation request
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308592143.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308592189.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
JVMST109: Insufficient space in Javaheap to satisfy allocation request
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308592224.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308592270.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
JVMST109: Insufficient space in Javaheap to satisfy allocation request
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308592305.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308592351.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
JVMST109: Insufficient space in Javaheap to satisfy allocation request
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308592385.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308592433.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
JVMST109: Insufficient space in Javaheap to satisfy allocation request
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308592467.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308592513.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
JVMST109: Insufficient space in Javaheap to satisfy allocation request
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308592547.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308592593.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
JVMST109: Insufficient space in Javaheap to satisfy allocation request
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308592628.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/javacore1511652.1308592674.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
JVMST109: Insufficient space in Javaheap to satisfy allocation request
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
...........................................JVMDG318: Heap dump file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxxx/heapdump1511652.1308592708.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to /prod/oracle/prodcomn/admin/log/PROD_xxxxx/javacore1511652.1308592755.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
JVMST109: Insufficient space in Javaheap to satisfy allocation request
JVMXE003
JVMST109: Insufficient space in Javaheap to satisfy allocation request
how to get through this error?
Thankz
ApPsMaStiPlease see these MOS docs.
XML Publisher Report Issues [ID 862644.1]
Output Post Processor (OPP) Log Contains Error "java.lang.OutOfMemoryError: Java heap space" Error [ID 1268217.1]
Output Post Processor (OPP) Log Contains Error "java.lang.OutOfMemoryError" [ID 1266368.1]
OPP Service Log for the 'Create Accounting' process shows 'java.lang.OutOfMemoryError: Java heap space ' Error [ID 1129283.1]
Retro-Notifications Report (Enhanced) - PDF Errors With 'java.lang.OutOfMemoryError' [ID 557898.1]
Costing Summary Rep Errors with Jvmst109: Insufficient Space In Javaheap [ID 391131.1]
Thanks,
Hussein -
JVM Memory = Heap + Non-Heap
I have configured JVM Memory as 1.5 GB. (OS is Windows) Perm Gen as 74 MB. In between i get "unable to create native threads" issue. I understand that a process in Windows can use a maximum memory of 2 GB.
1. Is the NATIVE MEMORY space part of Non-Heap? Or is it the remaining of (2GB - (HEAP+NON_HEAP)) ?
2. Is there a way to get the NATIVE MEMORY SPACE used by the java instance?I doubt the answers to any of those matter to your problem.
If you have the heap maxed out and you are getting that error then you are probably just creating too many threads.
If you are doing that on purpose then you need to redesign.
If you are doing it accidently then you need to find the bug that keeps the threads active and fix it.
Maybe you are looking for
-
Why is this RSS Feed not working?
Here is the code I used on the RSS Parser file. Yet when I open the flash viewer no changes have been made from the original example I pulled this from. Sorry, the code is listed twice. The second version is when I used "attach code" and I can't seem
-
Transfer purchases from iPhone
I execute this command but the tracks are still listed as unable to locate. Help please:)
-
Web Sharing Won't Start Up.
I was using My Powerbook successfully to develop websites using php and apache but suddenly when I upgraded to 10.4.6 web sharing in the system preferences just hangs when it is selected. I get a message saying it is starting up but it never gets as
-
RSR_OLAP_BADI not able to get it working
Hi all I have been trying to impliment the above badi but it does not seem to execute any of the code. Please advise if the following will work, I need to define a virtual characteristic to be populated with 'Full' / 'Partial' based on comparing two
-
Has anybody with positive experience Safari on VISTA?
Can someone with experience tell me if Safari is better than the Windows Internet Explorer-7 on VISTA. My Apple software keek prompting me to install Safari 3.1 on my windows vista. In another forum, on opinion was that safari VISTA has a risk of una