Appboard/old/memory configuration: Difference between revisions
imported>Mike.berman (edits in conjunction with runtime options updates) |
imported>Jason.nicholls |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{DISPLAYTITLE:Memory Configuration}} | |||
[[Category:AppBoard old]] | |||
This page details some settings that the AppBoard system administrator can modify to allocate the proper amount of server memory to AppBoard. | This page details some settings that the AppBoard system administrator can modify to allocate the proper amount of server memory to AppBoard. | ||
| Line 8: | Line 10: | ||
The heap size is the amount of Java object storage memory the Java Virtual Machine (JVM) is allowed to allocate. By default enPortal / AppBoard size the maximum heap size (-Xmx) option to work on a system with 2GB minimum physical RAM. Please refer to the [[ | The heap size is the amount of Java object storage memory the Java Virtual Machine (JVM) is allowed to allocate. By default enPortal / AppBoard size the maximum heap size (-Xmx) option to work on a system with 2GB minimum physical RAM. Please refer to the [[appboard/old/runtime_options|Runtime Options]] page for the current default settings and where to make changes to these values. | ||
== Tuning JAVA_MEMORY_MAX (-Xmx) == | == Tuning JAVA_MEMORY_MAX (-Xmx) == | ||
| Line 24: | Line 25: | ||
== Monitoring Garbage Collection == | == 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 | To enable GC logging use the <tt>JAVA_GC_LOGGING</tt> runtime option which will generate a <tt>gc.log</tt> 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 [https://github.com/chewiebug/GCViewer GCViewer], or Edge Support may be able to provide assistance by sending us the <tt>gc.log</tt> for analysis. | |||
Latest revision as of 11:28, 17 July 2014
This page details some settings that the AppBoard system administrator can modify to allocate the proper amount of server memory to AppBoard.
Memory Tuning
The heap size is the amount of Java object storage memory the Java Virtual Machine (JVM) is allowed to allocate. By default enPortal / AppBoard size the maximum heap size (-Xmx) option to work on a system with 2GB minimum physical RAM. Please refer to the Runtime Options page for the current default settings and where to make changes to these values.
Tuning JAVA_MEMORY_MAX (-Xmx)
For a server dedicated to running enPortal / AppBoard allocate as much available physical memory as possible. It's important to avoid allocating too much 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.
Tuning JAVA_PERM_SIZE_MAX (-XX:MaxPermSize)
Memory reserved for permanent generation is in addition to the -Xmx value configured 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.
