I have been reading the Integration Server Admin manual, Advantage.com, WMUsers.com and the articles I find on Google.com.
I do not see anything that addresses my concern. I am looking for guidance on the Max memory setting in the server.cnf file.
I am running on a Solaris with 6 gig of memory. I have the server.cnf set to 2G. I am wondering where I can find information about how to tune the settings. In addition to tuning, we also just need to be able to run very large volumes of data through our IS as an initial load of data. Normal daily volumes will never be this large and the webMethods packages were not built with the expectation of such large file sizes.
We run webMethods 6.1 Java Version: 1.4.2 (48.0). I’ve read some thread that say “you are only limited by the amount of memory on your machine” other threads lead me to believe there is a limit on size of memory based on the version of Java used.
I imagine there is a point where increasing the memory will actually cause more inefficiency than value.
any comments and suggestions will be most welcome
I believe you are looking for increasing the java memory heap for better performance.
So you have to change the setting located in the IntergrationServer/bin/server.bat or server.sh Edit this file and look for the setting “JAVA_MAX_MEM” and increase upon your disk storage.
Restart the IS is required.
yes changing the heap size is my concern. My question is “how do I know how much to increase the heap size?” Do I use all the available memory on the box? Is there a proportion I should stay within? Is there an upper limit which exceeding will offer no additional performance?
I believe maximum size you can increase upto 2048.ofcourse this depends your box capability.
But i will suggest and set this to <2048 always.This is what peoples decision.
Also please do check this thread link,it will help…
and look into the Wayne Leishman,Mark comments closely…
Not all of webMethods products will run on 1.4.x, but Integration Server will certainly do so.
I would check the JVM version that you are using and then search Sun’s web site for JVM Tuning documentation.
The JVM documentation will provide switches that you can add (at your own risk of course) that will tune or optimize the JVM for your particular use. The documentation should also note memory limitations. I am not aware of any limitations for Solaris. Windows is another matter.
The URL I would start with is: http://java.sun.com
Hope you got the information you needed regarding the limits of Max_Mem for IS/JVM;
Other points to note:
a) if your requirement for more memory comes from initial data loads (and, not daily volumes) you are better off increasing the Mem settings just for the data load (probably, set it to the maximum possible as per jvm you use, as you have 6GB on the box)
Once the initial data load is done, you can reduce it to a value most suitable for your environment.
b) as said, “you are only limited by the amount of memory on your machine” implies that you cant assign 1GB to your IS if your desktop/server has just 768MB.
This doesnt apply the other way around. Since your server has 6GB, you will be limited by jvm restrictions on Max Mem; plus what other apps on that server use.
c) as correctly noted by you, “there is a point where increasing the memory will actually cause more inefficiency than value”; And there is no hard and fast rule, to find that point(threshold)!! As an administrator, try few values and see which values fits the best in your environment.
Hope above clarifies it a bit for you.
The size of the heap for the IS JVM is only one factor affecting performance. This list of other factors is too long to explore fully in a single post, but includes the efficiency of the service doing the work, the size of the IS thread pool, the speed of the resources (disk drives, database servers, networks, off-the-shelf and custom applications) used to perform the work ,etc.
Generally, the larger the heap size, the more time spent in garbage collection (GC) which can lead to long pause times when nothing else is running on the JVM. However, a heap size that is too small leads to more frequent GC activity and potentially to out of memory errors when a thread tries to create objects bigger than the available memory.
In general, I would not set your heap size higher than the amount you need to process average load plus a contingency amount big enough to handle peak loads most of the time. The amount of memory that is right for your portfolio of integration services will vary based on the number of integrations on your server, the size of the documents being processed and the number of requests to process those documents per unit of time.
You can calculate a heap size to use when you begin testing, but you will need to adjust this by conducting well-designed load tests in a disciplined manner. There is no substitute for this performance testing process other than wishful thinking.
Experienced webMethods consultants can help with designing and running these performance test suites as well as analyzing the results to determine what changes, if any, should be made. Internal or external “experts” who dismiss the need for such testing should be tarred and feathered (or at least ignored) .