We have recenlty migrated to a new server and upgraded from 10.1B to 10.2B, and at times have run out of memory.
When comparing the memory size of a appserver/webspeed broker process, I've noticed that the 10.2B processes consume c10 times the amount of memory than those running 10.1B on a different server.
For example 10.2b
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
13225 webspeed 1221M 419M sleep 37 0 0:10:22 0.1% java/280
19192 appserve 1216M 412M sleep 51 0 35:48:47 0.0% java/342
VS 10.1b:
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
12681 appserve 74M 31M sleep 29 10 0:32:43 0.1% java/27
9333 webspeed 73M 26M sleep 29 10 0:33:41 0.1% java/19
I've got a feeling I've missed something glaringly obvious during the installation/configuration of OpenEdge/Appserver & Webspeed brokers, but I haven't spotted it yet. Can anyone point me in the right direction?
Thanks,
Chris
Server: Solaris, SUN T5440, 4 x 1.2 GHz 8-Core CPU,64GB Memory
Current Version Openedge 10.2B
Hello Chris,
The reason for the size difference in the Brokers was the change from the 1.4 JVM to 1.5 JVM. In the 1.5 JVM there were several changes made for better performance of JAVA. These included making the -server value the default (-client was the default in 1.4). The biggest difference between -server and -client is the use of the parallel garbage collection versus the serial garbage collection. The -server and parallel garbage collection require more memory to deliver much better performance in the JVM. Sun JAVA recommends, if running a server application like AppServer and WebSpeed, to let the JVM handle the memory and garbage collection for the best performance. There are parameters you can use to lower the memory foot print, but you may see performance degradation, so precede at your own risk.
So you did not miss any install or configuration settings for 10.2B. If the size of the JVM is a problem you can modify the values in the $DLC/properties files, but be sure to test your application for performance problems and possible memory exceptions in the JVM.
Regards, Roy Ellis
Thanks Roy, this is ver useful.
The jump from 74mb to 1gb ish per broker in memory seems a little excessive (granted I have no real knowledge exactly what the garbage collection is doing yet). Had I upgraded to 10.2B on our current server, the appserver and webspeed brokers (20 of them) would soon have eaten up the available memory (16gb), not forgetting the actual databases which already consume large amounts of memory with -B.
Can the memory be tuned per broker, and if so, where? I could happily lose the performance on the webspeed brokers and leave the appserver brokers as they are.
Thanks,
Chris
The following link/manual has given me a clue.
http://java.sun.com/j2se/1.5.0/docs/guide/vm/gc-ergonomics.html
Will see how we go.
I've switched a few webspeed brokers from parallel to serial garbage collection with the following switch in the properties file:
jvmArgs=-XX:+UseSerialGC
According to Sun the default is "Larger of 1/64th of the machine's physical memory on the machine or some reasonable minimum" - the memory footprint of each broker process now makes sense.
Available memory is back, will see how it goes over the next few days. Longer term the intention is to remove most of the webspeed brokers and use existing appserver/web services to dish out data from the various databases we have.
Thanks,
Chris