Appboard/2.6/admin/memory configuration

Overview

AppBoard is a Java application and therefore only uses as much memory as the Java Runtime Environment is configured to use, regardless of how much actual memory the server has available. By default the AppBoard turnkey installation is configured to only use 2GB of RAM to ensure it can run on a large variety of systems. This default should be changed on production systems to make use of all allocated memory.

Read over the Performance Tuning & Sizing page for a broader look at overall performance considerations.

Memory Runtime Options

Refer to the Runtime Options page for all runtime options, including memory options and the default configuration values. The important options are documented below with additional information:

JAVA_MEMORY_MAX (-Xmx)

For a server dedicated to running AppBoard allocate as much available memory as possible. It's important to avoid allocating all memory however, as this may lead to the OS using swap memory (i.e. disk) further degrading system performance. Factor in memory the OS is using itself, other applications on the system, and the JAVA_PERM_SIZE_MAX setting too.

On 32-bit operating systems there is a theoretical limit of 4GB but in practice it depends. On 32-bit Windows systems the max -Xmx setting that will work is around 1.6GB. On 32-bit Linux systems it's closer to 3GB.

JAVA_MEMORY_INIT (-Xms)

This sets the initial memory allocation requested by the Java runtime environment, which can then grow to the max size.

For production environments with dedicated resources this should be set to match the max value.

JAVA_PERM_SIZE_MAX (-XX:MaxPermSize)

The following applies only for Java 7 as Java 8 uses a different model.

Memory reserved for permanent generation is in addition to the max value above. If there are java.lang.OutOfMemoryError: PermGen space errors in the logs then it is necessary to increase this value.

Monitoring Garbage Collection

Monitoring the JVM garbage collection events can provide insight into how AppBoard is utilizing the memory available to it and help to diagnose performance issues and out of memory issues.

To enable GC logging use the JAVA_GC_LOGGING runtime option which will generate a gc.log log file in the AppBoard logs directory. Enabling GC logging is not resource intensive and does not create a huge log - it is safe for production use. The AppBoard server must be restarted after changing this option.

Analysing the gc.log file produced is possible with a number of tools such as GCViewer, or Edge Support may be able to provide assistance by sending us the gc.log for analysis.