We are using wM 8.2 SP1 products suite. IS , Broker , TN , MWS , JDBC & E1 JDE adapters. The IS memory settings are as follows:
JAVA_MIN_MEM=1484M
JAVA_MAX_MEM = 1100M
Max Threads = 500
We can see that the Thread usage and memory shoots up frequently. The machine has 2GB RAM and same swap space. We have applied only 8.2 SP1 core fix1 and a Deployer fix. The E1 JDE adapter consumes a lot of memory but we cannot exclude it as it is needed in our integrations.
Can somebody provide some tweaks for memory management.
The IS slowdown isn’t acceptable as testing is hindered and we have to take some downtime to get the IS up in shape. Do we need to increase the RAM from 2 GB to a higher value and then increase the threads to 1000.
I haven’t reported this to SAG but trying out some solution myself before approaching them.
Hi Shueb,
Your webMethods installation is hosted in Windows or Unix?
And, if Windows, is it installed as Application or Service?
I want to check/suggest few things…
As RMG said, maintain the balanced min/max eg., 1484M…
From your IS Admin page, you can see the Maximum Memory value being displayed… Can you check if that reflects what you have set in setenv.bat file? Divide that value by 1024, which should give you the value specified in JAVA_MAX_MEM in setenv.bat file.
The reason I am asking you about the Operating System is, there is one issue if it is Windows and IS has been installed as Service… After changing the memory value in setenv.bat file, you have to unregister and register the Windows service to get it reflected…
I just checked out the options that you suggested and below are my findings. We are using RHEL 2.6 version.
The maximum memory on the IS available is not the same as set in the setenv.sh file.
We have set JAVA_MIN = 1280M and JAVA_MAX=1536M. The IS displays a memory commitment usage of 1485M , a whole 52 MB less then for what it is configured(Is there a memory leak issue ?). I had set the MIN and MAX memory to be same earlier but didn’t help my cause much with the threads set at 500.
Is there something that can be boosted on the hardware front like RAM capacity and then we increase the threads to a higher value with JAVA MIN & MAX being set the same.
The difference in RAM memory will be there as internally to store some metadata, it might need space. I generally check this once to see if there is drastic difference. For example, during installation by default only 512 MB is allocated…
As the OS is RHEL, the possibility of un-registering/registering service is not required. That can also be eliminated.
watt.server.cache.gcMins property can be set to perform garbage collection.
You really dont have to worry about thread usage as there might be more threads required to be run internally for different operations. In case if you still want to know about details of threads, you might have to take thread dumps and analyze it further.
Yes if possible increase the RAM…another last option.
But what is your transactional load as it sounds you are in testing phase…About threads increase as Senthil mentioned above analyze the thread dumps if time permits:
This may indicate memory isn’t the issue. When setting different min and max values, the heap size will change, growing as needed. So either the JVM didn’t need the 52MB or couldn’t get the right size of contiguous memory from the OS. If it couldn’t grow the heap you’d see out of memory exceptions in the logs.
Have the logs indicated that the thread pool is a constraint?
What leads you to conclude that memory is constraining an increase in the pool size?
Adding more memory to the JVM may help but it may not–you kind of need to determine the contraint that is slowing things down. Perhaps it isn’t memory or system threads. Maybe it is adapter connection pool sizes. What is the IS doing when the slowdown is observed?
If you want to tweak memory configuration, search the web for JVM memory tuning tips.