Hello,
I’m using wM8.0 since these days it was working fine, after installing EDI(eStandards) during IS startup noticed the below error
[ISS.0026.0002E] Failure while loading service service.reports:service1: Java heap space
[ISS.0026.0002E] Failure while loading service ..:*** : GC overhead limit exceeded
Tried modifying the setenv.bat file as
set JAVA_MAX_PERM_SIZE=512M from 256M still I see this error during start up… suggest me your views.
Rgds,
Sam.
Try increasing the overall heap size, not just the permgen.
Now I set all
set JAVA_MIN_MEM=512M
set JAVA_MAX_MEM=512M
set JAVA_MAX_PERM_SIZE=512M
still am getting the error “java.lang.OutOfMemoryError: GC overhead limit exceeded”. Views please.
Setting the permsize to equal the heap size is not good.
Also, I think you may have assumed that this is a permgen issue. It may not be.
Can you share your JVM startup command-line? And JVM version?
You’ll want to do some research on JVM memory settings. Blindly trying things can lead to frustration.
You might want to put things back to the way they were. Then simply bump the min and max heap to 1GB or higher.
Hi Reamon,
Am using JAVA_DIR=D:\webMethodsd8\jvm\win160\jre
Regarding “JVM startup command line” hope you mean the below when we start up the IS.
Aug 26, 2011 2:59:40 PM com.webMethods.sc.config.ConfigurationLogger log
INFO: Out-of-band file changes will be monitored every ‘60000’ milliseconds
java.lang.OutOfMemoryError: GC overhead limit exceeded
java.lang.OutOfMemoryError: GC overhead limit exceeded
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: GC overhead limit exceeded
java.lang.OutOfMemoryError: GC overhead limit exceeded
java.lang.OutOfMemoryError: GC overhead limit exceeded
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: GC overhead limit exceeded
java.lang.OutOfMemoryError: GC overhead limit exceeded
java.lang.OutOfMemoryError: GC overhead limit exceeded
java.lang.OutOfMemoryError: GC overhead limit exceeded
java.lang.OutOfMemoryError: GC overhead limit exceeded
java.lang.OutOfMemoryError: GC overhead limit exceeded
java.lang.OutOfMemoryError: GC overhead limit exceeded
java.lang.OutOfMemoryError: GC overhead limit exceeded
java.lang.NullPointerException
at com.wm.data.ValuesEmulator.get(ValuesEmulator.java:20)
at com.wm.pkg.art.ns.ConnectionDataNode.setNodePropertiesFromIData(Conne
ctionDataNode.java:402)
at com.wm.pkg.art.ns.ARTNSNode.setValues(ARTNSNode.java:105)
at com.wm.pkg.art.ns.ConnectionDataNodeFactory.createFromNodeDef(Connect
ionDataNodeFactory.java:39)
at com.wm.app.b2b.server.PackageManager.createNode(PackageManager.java:2
183)
at com.wm.app.b2b.server.PackageManager.getNode(PackageManager.java:1055
)
at com.wm.app.b2b.server.PackageManager.getFileSystemNodes(PackageManage
r.java:1034)
at com.wm.app.b2b.server.PackageManager.loadServices(PackageManager.java
:686)
at com.wm.app.b2b.server.PackageManager.processPackageManifest(PackageMa
nager.java:639)
at com.wm.app.b2b.server.PackageManager.loadPackage(PackageManager.java:
463)
at com.wm.app.b2b.server.PackageManager.loadPackage(PackageManager.java:
348)
at com.wm.app.b2b.server.PackageManager.loadPackages(PackageManager.java
:309)
at com.wm.app.b2b.server.PackageManager.init(PackageManager.java:226)
at com.wm.app.b2b.server.Server.run(Server.java:400)
java.lang.OutOfMemoryError: GC overhead limit exceeded
java.lang.OutOfMemoryError: GC overhead limit exceeded
java.lang.OutOfMemoryError: GC overhead limit exceeded
I mean what are the arguments being passed to the JVM when the JVM is started? I don’t mean the console/log output of the JVM.
Hi Reamon,
Am not sure how to check this? what are all the parameters passed to JVM. Could you please tell me how to verify, so I can pass this information.
Rgds,
Sam.
The server.bat or server.sh script builds up the JVM command-line arguments. You can either determine the arguments by reviewing that file or you may be able to see the command-line in the console, depending on how you start IS.
Hi Reamon,
I enabled the echo and found while selecting the server.bat file.
I.E. the arguemnts to the JVM
D:\webMethodsd8_3\IntegrationServer>“D:\webMethodsd8_3\jvm\win160\jre\bin\java.e
xe” -Xms512M -Xmx512M -XX:MaxPermSize=512M -server -DWM_HOME=“D:\webMethodsd8_3
IntegrationServer..” “-Dcom.webMethods.sc.auditing.Use80TableFormat=true” “-Ds
un.lang.ClassLoader.allowArraySyntax=true” -classpath ;“D:\webMethodsd8_3\jvm\wi
n160\jre\lib\rt.jar;D:\webMethodsd8_3\jvm\win160\jre\lib\i18n.jar”;“D:\webMethod
sd8_3\IntegrationServer\lib\wm-isproxy.jar”;“D:\webMethodsd8_3\IntegrationServer
..\common\lib\wm-converters.jar”;“D:\webMethodsd8_3\IntegrationServer”\config\C
aching; com.wm.app.server.Main “D:\webMethodsd8_3\IntegrationServer”\bin\ini.cnf
-pcp -acp -ecp C:\Program Files\IBM\WebSphere MQ\Java\lib\providerutil.jar;C:
\Program Files\IBM\WebSphere MQ\Java\lib\com.ibm.mqjms.jar;C:\Program Files\IBM
WebSphere MQ\Java\lib\ldap.jar;C:\Program Files\IBM\WebSphere MQ\Java\lib\jta.ja
r;C:\Program Files\IBM\WebSphere MQ\Java\lib\jndi.jar;C:\Program Files\IBM\WebSp
here MQ\Java\lib\jms.jar;C:\Program Files\IBM\WebSphere MQ\Java\lib\connector.ja
r;C:\Program Files\IBM\WebSphere MQ\Java\lib\fscontext.jar;C:\Program Files\IBM
WebSphere MQ\Java\lib\com.ibm.mq.jar
Sep 7, 2011 12:52:34 PM com.webMethods.sc.config.ConfigurationLogger log
INFO: Out-of-band file changes will be monitored every ‘60000’ milliseconds
If am not correct with your expectaion. Please tell me will try to get more information again.
Regds,
Sam.
That’s it.
-Xms512M -Xmx512M -XX:MaxPermSize=512M
Those are the parameters of interest. As mentioned before, setting the MaxPermSize to be the same as the max heap is likely not a good idea. Research the web for the meaning and usage of these parameters.
Hi Reamon,
Sorry for the delay response.
I have modified the memory settings as below
set JAVA_MIN_MEM=256M
set JAVA_MAX_MEM=512M
set JAVA_MAX_PERM_SIZE=128M
Now I got the similar error
D:\webMethodsd8_3\IntegrationServer>title webMethods Integration Server
D:\webMethodsd8_3\IntegrationServer>“D:\webMethodsd8_3\jvm\win160\jre\bin\java.e
xe” -Xms256M -Xmx512M -XX:MaxPermSize=128M -server -DWM_HOME=“D:\webMethodsd8_3
IntegrationServer..” “-Dcom.webMethods.sc.auditing.Use80TableFormat=true” “-Ds
un.lang.ClassLoader.allowArraySyntax=true” -classpath ;“D:\webMethodsd8_3\jvm\wi
n160\jre\lib\rt.jar;D:\webMethodsd8_3\jvm\win160\jre\lib\i18n.jar”;“D:\webMethod
sd8_3\IntegrationServer\lib\wm-isproxy.jar”;“D:\webMethodsd8_3\IntegrationServer
..\common\lib\wm-converters.jar”;“D:\webMethodsd8_3\IntegrationServer”\config\C
aching; com.wm.app.server.Main “D:\webMethodsd8_3\IntegrationServer”\bin\ini.cnf
-pcp -acp -ecp C:\Program Files\IBM\WebSphere MQ\Java\lib\providerutil.jar;C:
\Program Files\IBM\WebSphere MQ\Java\lib\com.ibm.mqjms.jar;C:\Program Files\IBM
WebSphere MQ\Java\lib\ldap.jar;C:\Program Files\IBM\WebSphere MQ\Java\lib\jta.ja
r;C:\Program Files\IBM\WebSphere MQ\Java\lib\jndi.jar;C:\Program Files\IBM\WebSp
here MQ\Java\lib\jms.jar;C:\Program Files\IBM\WebSphere MQ\Java\lib\connector.ja
r;C:\Program Files\IBM\WebSphere MQ\Java\lib\fscontext.jar;C:\Program Files\IBM
WebSphere MQ\Java\lib\com.ibm.mq.jar
Sep 15, 2011 12:16:45 PM com.webMethods.sc.config.ConfigurationLogger log
INFO: Out-of-band file changes will be monitored every ‘60000’ milliseconds
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap spaceSep 15, 2011 12:52:48 PM com.webmetho
ds.sc.config.ConfigurationLogger log
WARNING: Caught unexpected exception in FileMonitorTask.run(); message: ‘Java he
ap space’
2011.09.15 13:06:13 MQJMS1023E rollback failed
java.lang.OutOfMemoryError: Java heap space
log4j:ERROR error while servicing the queue
java.lang.OutOfMemoryError: Java heap space
Your views pls.
Rgds,
Sam.
Why not try some bigger number?
1024M
1024M
256M
seems you are using MQ and it require more memory to load.
I agree with Tong. The error indicates the JVM is running out of heap space so 512M is not enough. Bump to 1024M or higher.
Hi,
keeping same values for min and max heaps will not give a good result as GC may not function correctly
“Setting -Xms and -Xmx to the same value increases predictability by removing the most important sizing decision from the virtual machine. However, the virtual machine is then unable to compensate if you make a poor choice”
try to keep increasing the memory heap settings untill it boots up.
When you do the performance testing, then you can tune up these params depending on the output result…
/skola
Responding to the issue though the chain is closed so that someone gets benefited from it in future.
This is a small write up I drafted from some of the documents of SAG webMethods:
Garbage Collection
JVMs use Garbage Collection (GC) as a mechanism to reclaim unused memory. The garbage collection
process is managed entirely by the JVM.
Garbage collection typically interrupts execution of all threads except the garbage collection helper
threads. Therefore, frequent garbage collection can impact the performance of the Integration Server
significantly. One simple way to lengthen the time between garbage collections is to increase the Java
heap size. Note that this will also potentially lengthen the duration of each garbage collection pause,
since the JVM will have to reclaim more memory.
To learn more about the garbage collection where your Integration Server is running, start the JVM with
the “-verbose:gc” switch. This switch tells the JVM to log information relating to garbage collection.
The logs contain information relating to frequency of garbage collection, length of time spent for each
garbage collection, amount of memory reclaimed during each garbage collection, and so forth. For more
information about the “-verbose:gc” switch, consult JVM documentation for the specific JVM in use.
Most JVM vendors provide a number of options that you can use to fine-tune the garbage collection
process. Discussing different garbage collection options offered by different JVM vendors for different
versions is beyond the scope of this document.
Eliminate unnecessary audit logging.
Make sure the Integration Server’s “watt.server.auditLog” parameter is set to “perSvc” and
not to “brief” or “verbose”. Example:
watt.server.auditLog=perSvc
Heap Settings and Memory
The amount of memory available to the Integration Server is determined by the size of the maximum
heap you allocate to the JVM. The heap is the memory area in which the Java Virtual Machine (JVM)
creates and stores objects. Because the heap is the only portion of memory that the Integration Server
uses for data storage, the size of the heap (not the amount of memory installed on the machine)
ultimately determines how many documents the Integration Server can actually process at one time.
Heaps that are too small
A heap that is too small will produce out-of-memory errors. A small heap may also cause sluggish
performance due to frequent pauses for garbage collection (reclamation of memory that is no
longer in use).
Heaps that are too large
Performance will also degrade significantly if the machine does not have enough physical memory
to expand the heap to its configured maximum size and must then page portions of the heap to
virtual storage (disk).
To determine how much of the heap your Integration Server uses, start the server and load only those
packages that you expect to load under normal operating conditions. Immediately after the server loads,
use the Integration Server Administrator to examine the Available Memory value on the “Settings >
Resources” page. The “Available Memory” value will indicate how much of the heap is available for
processing your documents. You can monitor this value as your solution executes to track its memory
usage.
From ©2011 Software AG webMethods Advanced Troubleshooting Guide Page 18
By default, the Integration Server is configured to allocate an initial heap size of 128MB, and configured
to expand to a maximum heap size of 256MB. You can change the size of the heap memory in the
Integration Server startup file:
° Windows: server.bat ( now setenv.bat, 8.x onwards)
° Unix/Linux: server.sh
To change the size of the heap, set the following Java parameters in the start-up file for the Integration
Server:
° JAVA_MIN_MEM=
° JAVA_MAX_MEM=
A common performance-tuning measure is to make the initial heap size (JAVA_MIN_MEM) equal to the
maximum heap size (JAVA_MAX_MEM). Doing this prevents heap expansion and contraction, and can
produce performance gains in some situations.
Some operating systems limit the amount of memory that a single process can use. For example,
Windows 32-bit machine does not allow a process to use more than 2 GB of memory. So, even if you equipped a
Windows 32-bit machine with 4 GB of memory, the Integration Server will never use more than 2 GB of it.
Some early versions of the JVM also restrict the maximum size of the heap. When tuning memory to
improve performance, you need to be aware of any limitations that your existing operating system and/or
JVM may impose. You may find that you need to switch operating systems and/or JVMs to achieve the
heap size you need.
Also, before you provide the Max Perm Gen memory, run jvisualvm.exe which will enable you to know how much of Perm Gen memory you actually need, use a good buffer and then assign the values. It helps to substantially bring down the Integration server Performance.