Progress AdminServer, NameServer, AppServer broker, WebSpeed broker, Sonic Adapter java processes consume more memory after upgrading to 10.1C or higher

por | 23 junio, 2011
ID: P153007
Title: «Progress AdminServer, NameServer, AppServer broker, WebSpeed broker, Sonic Adapter java processes consume more memory after upgrading to 10.1C or higher»
Created: 09/21/2009 Last Modified: 04/13/2010
Status: Verified

Symptoms:

 

  • Progress AdminServer, NameServer, AppServer broker, WebSpeed broker, Sonic Adapter java processes consume more memory after upgrading to 10.1C or higher
  • Progress Java processes consume more memory starting from 10.1C
  • JVM 1.5 consumes a lot more memory than JVM 1.4
Facts:  

  • All Supported Operating Systems
  • OpenEdge 10.x
Cause:  

  • Research and testing by Progress has shown that a large increase in memory usage comes with the advent of using JVM 1.5 with OpenEdge version 10.1C. The significant change with this 1.5 release of Java is that the default version of the JVM changed from ‘-client’ to ‘-server’ (on serverclass machines). The server JVM is tuned for runtime performance, using additional memory to achieve this goal.NOTE: For J2SE 5.0, the definition of a server-class machine is one with at least 2 CPUs and at least 2GB of physical memory.One of the most significant differences between the client JVM and the server JVM is in the choice of garbage collectors. The client JVM uses the serial garbage collector by default, while the server JVM uses the parallel garbage collector by default (on serverclass machines). The primary difference between the two is that the serial garbage collector uses a single thread to perform garbage collection, whereas the parallel collector uses multiple threads, up to the number of CPU’s on the system. However, because of its parallel design, the parallel garbage collector requires additional memory.

    On machines that are not server-class machines, the default values for the JVM, garbage collector, and heap sizes are:

    · the client JVM
    · the serial garbage collector
    · Initial heap size of 4MB
    · Maximum heap size of 64MB

    On a server-class machine, the JVM is always the server JVM unless you explicitly specify the –client command line option to request the client JVM. On a server-class machine running the server JVM, the default garbage collector is the parallel collector. Otherwise, the default is the serial collector.

    On a server-class machine running either JVM (client or server) with the parallel garbage collector, the default initial and maximum heap sizes are:

    · Initial heap size of 1/64th of the physical memory, up to 1GB. Note that the minimum initial heap size is 32MB, since a server-class machine is defined to have at least 2GB of memory and 1/64th of 2GB is 32MB.
    · Maximum heap size of 1/4th of the physical memory, up to 1GB.

    Using the -client virtual machine (vm) in Java 1.5 provides a significant reduction in memory requirements. However, the -client vm is not available for the 64-bit version of Java 1.5. It is possible to configure the 64-bit -server JVM to use the serial garbage collector, using the -XX:+UseSerialGC option. In our test environment, this provided a significant decrease in the memory requirements of the -server JVM in this environment. As an example, comparing the OpenEdge 10.1C NameServer running on the 64-bit -server JVM, the memory size decreased from 374 MB to 121 MB (approximately 65%) by employing the -XX:+UseSerialGC option; impact on the RSS was markedly less dramatic.

    It should be noted that the serial garbage collector may run more slowly than the parallel collector. This may possibly manifest itself in longer garbage collector (GC) pause times. A pause occurs in the application (i.e. all threads are stopped) when the GC must run; the length of the pause depends on how much garbage must be collected, and how quickly the GC runs. For low volume processes (e.g. the AdminServer without OpenEdge Management), using the serial GC is probably satisfactory. It may also be okay for a lightly used NameServer. For the AppServer however, successfully using the serial GC would probably depend on the application. It may be okay for state-aware/state-reset applications that don’t connect/disconnect for each request. However, in stateless or statefree operating modes, using the serial GC might negatively impact application performance.

Fixes:
Every Progress installation site is different in terms of size, load, and performance requirements.  Therefore Progress is unable to provide specific recommendations on what would best suit your environment. 

Adding the Java maximum heap size parameter -Xmx1024m has been known to reduce the amount of memory consumed by the JVM in some environments while still maintaining the parallel garbage collector.  As always, your mileage may vary.

If you need to set or adjust any of the above mentioned Java parameters then you will need to ensure that you test them within your environment to determine suitability and stability.

For the AdminServer, NameServer, AppServer brokers, NameServer brokers, Sonic Adapters, java parameters can be set within the $DLC/properties/AdminServerPlugins.properties file.  You will need to search for the [PluginPolicy.Progress] section and modify the jvmargs parameter as shown in the example below:

[PluginPolicy.Progress]
pluginclasspath=!{value-of:classpath}
classpath=/progress/dlc101c/jre/i18n.jar,/progress/dlc101c/jdk/lib/tools.jar,
/progress/dlc101c/java/progress.jar,/progress/dlc101c/java/ext/mgmt_client.jar
jvmargs=-Xmx1024m

Notes:
References to Written Documentation: 

http://java.sun.com/j2se/reference/whitepapers/memorymanagement_whitepaper.pdf
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html
http://java.sun.com/j2se/1.5.0/docs/guide/vm/server-class.html