I have seen couple of threads on garbage collector but did find what i need
We are using wM 7.1.1.0, java 1.5.0_12 and noticing lot of memory spikes. So i created a garbage collector service (scheduled it for 60 sec) and enabled (watt.server.cache.gcMins=60). I also noticed lot of improper coding which also could lead to memory spikes. Other than modifing the code is there any thing else i can do from IS side to reduce memory spikes ? \
Also i am not good at coding in java. I read couple of forms and created GC java service with just one line [System.gc();] and no inputs or outputs, did i do it the right way ?
Dave,
If you read through the forums then you probably saw that it is not recommended to use the System.gc() call.
It’s quite normal for a JVM to have memory spikes. The gc will returned the memory after it runs which it will do on its on. Memory spikes are only an issue if you actually run out of memory. In that case you have a couple of potential issues such as you haven’t sized the jvm correctly for the number/size of transactions you have or you have code that is leaking memory which the gc is not recovering.
If you are looking at the little graph on the Admin page, i wouldn’t stare at that to much unless like I said you are actually running out of memory.
Which is exactly what the internal GC does on it’s own when it needs to. Calling System.gc() does not guarantee that it will run, it is a suggestion as far as the JVM goes. This leads back to the original question which is “Are you running out of memory or are you just watching the little memory graph?”
If you are not running out of memory then the best advice is to leave it alone, garbage collection does have a performance overhead esp. the larger your jvm footprint gets. If you are running out of memory calling System.gc() is not going to fix that. At best it might delay it but then you will have avoiding the task of figuring out why you are running out of memory in the first place.
GC can be a bit confusing but ultimately its best if you leave the internals up to the JVM. If the objects are ready to be collected then the GC will get them when it needs to, no need to try and force it.
webMethods (or the jvm) doesn’t garbage collect ‘when it needs to’ at least for v6.5. It tends to get up to 80-90% usage and can sit there degrading performance until it decides to kick it in, often too late with an out of memory error. I’ve seen this especially with lower memory allocations such as 2GB, whereas larger allocations can work better.
Garbage collection is not controlled by webMethods. It is underlying jvm that controls it.
You have flexibility modify settings to use appropriate GC algorithms or even the frequencies (like if it free memory goes below certain value, call GC). These java fine tuning should be done with proper understanding of the Java Garbage Collection. Check JVM providers site for Garbage Collection details in that JVM.
Jay’s comments are right on. JVM controls the deal. Out of Memory errors however are almost always caused by an incorrectly sized and partioned webMethods IS instance. Understanding what you are processing and what the concurrency is, will go along way in getting your instances straight. If you are consistently running out of memory, garabage collection is probably not the first place to look. While yes there are things you can do to tune garabage collection, the real culprit is usually in the design of the instance and the code within it, I’d say about 99.999 of the time. :proud: