Appboard/2.5/admin/memory configuration - Revision history

imported>Jason.nicholls: /* JAVA_MEMORY_MAX (-Xmx) */

2014-07-10T09:02:40Z

JAVA_MEMORY_MAX (-Xmx)

← Older revision		Revision as of 09:02, 10 July 2014
Line 16:		Line 16:
	=== <tt>JAVA_MEMORY_MAX</tt> (-Xmx) ===		=== <tt>JAVA_MEMORY_MAX</tt> (-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 <tt>JAVA_PERM_SIZE_MAX</tt> setting too.		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 <tt>JAVA_PERM_SIZE_MAX</tt> 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.		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.

imported>Jason.nicholls at 09:00, 10 July 2014

2014-07-10T09:00:28Z

← Older revision		Revision as of 09:00, 10 July 2014
Line 2:		Line 2:
	[[Category:AppBoard 2.5]]		[[Category:AppBoard 2.5]]

			== 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.		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.
Line 18:		Line 19:

	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.		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.


	=== <tt>JAVA_MEMORY_INIT</tt> (-Xms) ===		=== <tt>JAVA_MEMORY_INIT</tt> (-Xms) ===
Line 25:		Line 25:

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


	=== <tt>JAVA_PERM_SIZE_MAX</tt> (-XX:MaxPermSize) ===		=== <tt>JAVA_PERM_SIZE_MAX</tt> (-XX:MaxPermSize) ===

imported>Jason.nicholls: /* = JAVA_PERM_SIZE_MAX (-XX:MaxPermSize) */

2014-07-10T08:57:49Z

= JAVA_PERM_SIZE_MAX (-XX:MaxPermSize)

← Older revision		Revision as of 08:57, 10 July 2014
Line 27:		Line 27:


	=== <tt>JAVA_PERM_SIZE_MAX</tt> (-XX:MaxPermSize) ==		=== <tt>JAVA_PERM_SIZE_MAX</tt> (-XX:MaxPermSize) ===

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

imported>Jason.nicholls at 08:57, 10 July 2014

2014-07-10T08:57:01Z

← Older revision		Revision as of 08:57, 10 July 2014
Line 4:		Line 4:

	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.		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.


	{{Tip\|Read over the [[appboard/2.5/admin/performance_and_sizing\|Performance Tuning & Sizing]] page for a broader look at overall performance considerations.}}		{{Tip\|Read over the [[appboard/2.5/admin/performance_and_sizing\|Performance Tuning & Sizing]] page for a broader look at overall performance considerations.}}

			== Memory Runtime Options ==

			Refer to the [[appboard/2.5/admin/runtime_options\|Runtime Options]] page for all runtime options, including memory options and the default configuration values. The important options are documented below with additional information:


			=== <tt>JAVA_MEMORY_MAX</tt> (-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 <tt>JAVA_PERM_SIZE_MAX</tt> setting too.

	~~== Memory Tuning ==~~		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.

	~~{{Tip\|If your system is experiencing lag or performance issues, or you see the error message "Out of heap space", you may want to allocate additional memory to the Java Virtual Machine.}}~~

	~~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\|Runtime Options]] page for the current default settings and where to make changes to these values.~~		=== <tt>JAVA_MEMORY_INIT</tt> (-Xms) ===

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

	~~== Tuning JAVA_MEMORY_MAX (-Xmx) ==~~		For production environments with dedicated resources this should be set to match the max value.

	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 <tt>JAVA_PERM_SIZE_MAX</tt> 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.		=== <tt>JAVA_PERM_SIZE_MAX</tt> (-XX:MaxPermSize) ==

	~~== Tuning 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 ~~<tt>-Xmx</tt>~~ value ~~configured~~ above. If there are <tt>java.lang.OutOfMemoryError:		Memory reserved for permanent generation is in addition to the max value above. If there are <tt>java.lang.OutOfMemoryError:
	PermGen space</tt> errors in the logs then it is necessary to increase this value.		PermGen space</tt> errors in the logs then it is necessary to increase this value.

	== 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.		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.

imported>Jason.nicholls at 08:46, 10 July 2014

2014-07-10T08:46:42Z

← Older revision		Revision as of 08:46, 10 July 2014
Line 2:		Line 2:
	[[Category:AppBoard 2.5]]		[[Category:AppBoard 2.5]]

	~~Before modifying the Java memory settings it is recommended to read over the general~~
	~~[[appboard/2.5/admin/performance_and_sizing\|Performance Tuning & Sizing]] page.~~

	~~{{Note\|~~AppBoard ~~ships with~~ a default ~~memory configuration~~ to run on systems ~~with 2GB of RAM~~. This ~~is likely to~~ be ~~''insufficient'' for~~ production systems so make ~~sure to configure production systems appropriately~~.}}		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.

			{{Tip\|Read over the [[appboard/2.5/admin/performance_and_sizing\|Performance Tuning & Sizing]] page for a broader look at overall performance considerations.}}

imported>Jason.nicholls at 08:40, 10 July 2014

2014-07-10T08:40:19Z

← Older revision		Revision as of 08:40, 10 July 2014
Line 1:		Line 1:
	{{DISPLAYTITLE:Memory Configuration}}		{{DISPLAYTITLE:Memory Configuration}}
	[[Category:AppBoard 2.5]]		[[Category:AppBoard 2.5]]
	~~This page details some~~ settings ~~that~~ the AppBoard ~~system administrator can modify~~ to ~~allocate the proper amount~~ of ~~server memory~~ to ~~AppBoard~~.
			Before modifying the Java memory settings it is recommended to read over the general
			[[appboard/2.5/admin/performance_and_sizing\|Performance Tuning & Sizing]] page.

			{{Note\|AppBoard ships with a default memory configuration to run on systems with 2GB of RAM. This is likely to be ''insufficient'' for production systems so make sure to configure production systems appropriately.}}

imported>Jason.nicholls: Created page with '{{DISPLAYTITLE:Memory Configuration}} Category:AppBoard 2.5 This page details some settings that the AppBoard system administrator can modify to allocate the proper amount of…'

2014-07-10T08:20:48Z

Created page with '{{DISPLAYTITLE:Memory Configuration}} Category:AppBoard 2.5 This page details some settings that the AppBoard system administrator can modify to allocate the proper amount of…'

New page

{{DISPLAYTITLE:Memory Configuration}}
[[Category:AppBoard 2.5]]
This page details some settings that the AppBoard system administrator can modify to allocate the proper amount of server memory to AppBoard.

== Memory Tuning ==

{{Tip|If your system is experiencing lag or performance issues, or you see the error message "Out of heap space", you may want to allocate additional memory to the Java Virtual Machine.}}

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|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 <tt>JAVA_PERM_SIZE_MAX</tt> 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 <tt>-Xmx</tt> value configured above. If there are <tt>java.lang.OutOfMemoryError:
PermGen space</tt> 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 <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.