Appboard/old/memory configuration - Revision history

imported>Jason.nicholls: /* Memory Tuning */

2014-07-17T11:28:25Z

Memory Tuning

← Older revision		Revision as of 11:28, 17 July 2014
Line 10:		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 [[~~Runtime_Options~~\|Runtime Options]] page for the current default settings and where to make changes to these values.		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) ==

imported>Jason.nicholls at 05:07, 17 July 2014

2014-07-17T05:07:13Z

← Older revision		Revision as of 05:07, 17 July 2014
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.

imported>Jason.nicholls: moved Memory Configuration to appboard/old/memory configuration

2014-07-17T05:06:11Z

moved Memory Configuration to appboard/old/memory configuration

← Older revision	Revision as of 05:06, 17 July 2014
(No difference)

imported>Jason.nicholls: /* Monitoring Garbage Collection */

2013-10-11T02:28:13Z

Monitoring Garbage Collection

← Older revision		Revision as of 02:28, 11 October 2013
Line 26:		Line 26:
	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.

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

imported>Jason.nicholls: /* Monitoring Garbage Collection */

2013-10-11T02:23:39Z

Monitoring Garbage Collection

← Older revision		Revision as of 02:23, 11 October 2013
Line 24:		Line 24:
	== Monitoring Garbage Collection ==		== Monitoring Garbage Collection ==

	~~If you are experiencing a memory leak, and would like to carefully report on each~~ garbage collection ~~event, you~~ can ~~log this data~~ to ~~a file by using the <tt>-Xloggc:file</tt> Java Option. Each reported event will be preceeded by the time (in seconds) since the first garbage-collection event~~.		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.

	~~Always~~ use a ~~local~~ file ~~system~~ for ~~storage of~~ this ~~file to avoid stalling the JVM due to network latency~~.		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.

	~~To enable~~ the ~~logging you will have to edit the <tt>~~[~~INSTALL_HOME]~~/~~server~~/~~bin~~/~~setenv.bat<~~/~~tt> (~~or ~~<tt>setenv.sh</tt> on Linux/Unix). Normally this file shouldn't~~ be ~~edited however this is temporary and for debugging only.~~		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.

	~~# open~~ the ~~appropriate~~ <tt>~~setenv~~.~~bat~~</tt> ~~or <tt>setenv.sh</tt> file~~
	~~# at the bottom where <tt>JAVA_OPTS</tt> is being set, at the very end of the string add:~~
	~~#: <tt>-Xloggc:''logfile_location~~.~~txt''</tt>~~
	~~# save and restart enPortal / AppBoard~~

imported>Mike.berman: edits in conjunction with runtime options updates

2013-06-16T15:59:10Z

edits in conjunction with runtime options updates

← Older revision		Revision as of 15:59, 16 June 2013
Line 2:		Line 2:


	== ~~Allocating Additional~~ Memory ==		== Memory Tuning ==


	{{Tip\|If your system is experiencing ~~lags~~ 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.}}		{{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. ~~In the case of most JVMs, the~~ default ~~setting of the maximum heap~~ size ~~is 64MB. You can increase~~ the maximum heap size ~~of applications by setting the~~ -Xmx ~~JVM parameter. For example -Xmx1024m allows maximum 1GB (1024MB~~) ~~heap~~ to ~~be allocated for the JVM. It is recommended to specify~~ a ~~considerably lower value than the total amount of~~ physical RAM ~~on the server, so the operating system and other applications will also have enough space~~. ~~Otherwise,~~ the ~~swap memory of~~ the ~~operating system will be used, which can result in high disk activity,~~ and ~~reduced system performance~~.		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.


	~~Perform the following steps to review the memory heap size settings for AppBoard:~~		== Tuning JAVA_MEMORY_MAX (-Xmx) ==
	~~# Go to [AppBoard_Home]/server/bin/setenv.bat~~ (~~or setenv.sh on Unix~~).
	~~# Open the file in a text editor. You will see lines similar to the following:~~
	~~<code>[xml,N]set JAVA_MEMORY_MAX~~=~~1536~~
	~~rem set JAVA_MEMORY_MAX~~=~~2048</code>~~

	~~The limit for 32-bit operating systems is less than the 4096 MB of theoretical address space.~~ For ~~Windows, the real limit is under 1600 MB (due~~ to memory ~~used for non-heap storage and Windows limitation of user space addressable~~ memory to ~~under 2048 MB), which is why~~ the ~~default is 1536 MB~~ (~~512 MB x 3~~). ~~If AppBoard~~ is ~~running~~ on ~~both a 64-bit operating~~ system and ~~a 64-bit Java, it can support a higher~~ setting ~~for the heap size~~. ~~For example, you can increase the memory available to Tomcat from 1536 MB to 2048 MB by activating the second setting, as follows:~~		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.

	~~<code>[xml,N]rem set JAVA_MEMORY_MAX=1536~~		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.
	~~set JAVA_MEMORY_MAX=2048</code>~~

	Depending on the RAM on your AppBoard server, higher values for the maximum heap space will typically provide better performance overall. However, for complete system optimization, the efficiency of your system with regard to data retrieval, caching, querying, etc., must be considered and will often be the limiting factors for performance.		== Tuning JAVA_PERM_SIZE_MAX (-XX:MaxPermSize) ==


	~~{{Note\|You should make any changes to the memory settings in <tt>setenv~~-~~custom.bat</tt>. This will ensure that these setting will be preserved when you upgrade the system.}}~~

			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 Garbage Collection ==
Line 34:		Line 28:
	Always use a local file system for storage of this file to avoid stalling the JVM due to network latency.		Always use a local file system for storage of this file to avoid stalling the JVM due to network latency.

	~~Perform~~ the ~~following steps to enable memory~~ logging ~~for AppBoard to a file:~~		To enable the logging you will have to edit the <tt>[INSTALL_HOME]/server/bin/setenv.bat</tt> (or <tt>setenv.sh</tt> on Linux/Unix). Normally this file shouldn't be edited however this is temporary and for debugging only.
	~~# Go~~ to [~~AppBoard_Home~~]/server/bin/setenv.bat (or setenv.sh on Unix).
	~~# Open the~~ file ~~in a text editor. You will see a line near the bottom of the file similar to the following:~~
	~~#: <code>[xml,N]set JAVA_OPTS=-Xmx%JAVA_MEMORY_MAX%m ... -Dkeystore.pass=%KEYSTORE_PASS%</code>~~
	~~# Add the Xlogcc parameter, such as in the following example:~~
	~~#: <code>[xml,N]set JAVA_OPTS=-Xmx%JAVA_MEMORY_MAX%m~~ .~~.. -Dkeystore.pass=%KEYSTORE_PASS% -Xloggc:c:\GCout.txt</code>~~


	~~{{Note\|Changes to the memory logging settings as described above must be manually preserved on upgrade, since the upgraded system will overwrite~~ the setenv file ~~and revert to~~ the ~~standard~~ JAVA_OPTS ~~settings~~.}}		# open the appropriate <tt>setenv.bat</tt> or <tt>setenv.sh</tt> file
			# at the bottom where <tt>JAVA_OPTS</tt> is being set, at the very end of the string add:
			#: <tt>-Xloggc:''logfile_location.txt''</tt>
			# save and restart enPortal / AppBoard

imported>Mike.berman: add note about upgrades

2012-03-30T19:33:08Z

add note about upgrades

← Older revision		Revision as of 19:33, 30 March 2012
Line 23:		Line 23:

	Depending on the RAM on your AppBoard server, higher values for the maximum heap space will typically provide better performance overall. However, for complete system optimization, the efficiency of your system with regard to data retrieval, caching, querying, etc., must be considered and will often be the limiting factors for performance.		Depending on the RAM on your AppBoard server, higher values for the maximum heap space will typically provide better performance overall. However, for complete system optimization, the efficiency of your system with regard to data retrieval, caching, querying, etc., must be considered and will often be the limiting factors for performance.


			{{Note\|You should make any changes to the memory settings in <tt>setenv-custom.bat</tt>. This will ensure that these setting will be preserved when you upgrade the system.}}


	== Monitoring Garbage Collection ==		== Monitoring Garbage Collection ==
Line 36:		Line 40:
	# Add the Xlogcc parameter, such as in the following example:		# Add the Xlogcc parameter, such as in the following example:
	#: <code>[xml,N]set JAVA_OPTS=-Xmx%JAVA_MEMORY_MAX%m ... -Dkeystore.pass=%KEYSTORE_PASS% -Xloggc:c:\GCout.txt</code>		#: <code>[xml,N]set JAVA_OPTS=-Xmx%JAVA_MEMORY_MAX%m ... -Dkeystore.pass=%KEYSTORE_PASS% -Xloggc:c:\GCout.txt</code>


			{{Note\|Changes to the memory logging settings as described above must be manually preserved on upgrade, since the upgraded system will overwrite the setenv file and revert to the standard JAVA_OPTS settings.}}

imported>Cmace: copied from internalwiki

2012-03-13T20:25:32Z

copied from internalwiki

← Older revision		Revision as of 20:25, 13 March 2012
Line 14:		Line 14:
	# Go to [AppBoard_Home]/server/bin/setenv.bat (or setenv.sh on Unix).		# Go to [AppBoard_Home]/server/bin/setenv.bat (or setenv.sh on Unix).
	# Open the file in a text editor. You will see lines similar to the following:		# Open the file in a text editor. You will see lines similar to the following:
	<code>[xml,N]set ~~JAVA_OPTS~~=~~%JAVA_OPTS% -Xmx1536m -Xms256m~~		<code>[xml,N]set JAVA_MEMORY_MAX=1536
	rem set ~~JAVA_OPTS~~=~~%JAVA_OPTS% -Xmx2048m -Xms256m~~</code>		rem set JAVA_MEMORY_MAX=2048</code>

	The limit for 32-bit operating systems is less than the 4096 MB of theoretical address space. For Windows, the real limit is under 1600 MB (due to memory used for non-heap storage and Windows limitation of user space addressable memory to under 2048 MB), which is why the default is 1536 MB (512 MB x 3). If AppBoard is running on both a 64-bit operating system and a 64-bit Java, it can support a higher setting for the heap size. For example, you can increase the memory available to Tomcat from 1536 MB to 2048 MB by activating the second setting, as follows:		The limit for 32-bit operating systems is less than the 4096 MB of theoretical address space. For Windows, the real limit is under 1600 MB (due to memory used for non-heap storage and Windows limitation of user space addressable memory to under 2048 MB), which is why the default is 1536 MB (512 MB x 3). If AppBoard is running on both a 64-bit operating system and a 64-bit Java, it can support a higher setting for the heap size. For example, you can increase the memory available to Tomcat from 1536 MB to 2048 MB by activating the second setting, as follows:

	<code>[xml,N]rem set ~~JAVA_OPTS~~=~~%JAVA_OPTS% -Xmx1536m -Xms256m~~		<code>[xml,N]rem set JAVA_MEMORY_MAX=1536
	set ~~JAVA_OPTS~~=~~%JAVA_OPTS% -Xmx2048m -Xms256m~~</code>		set JAVA_MEMORY_MAX=2048</code>

	Depending on the RAM on your AppBoard server, higher values for the maximum heap space will typically provide better performance overall. However, for complete system optimization, the efficiency of your system with regard to data retrieval, caching, querying, etc., must be considered and will often be the limiting factors for performance.		Depending on the RAM on your AppBoard server, higher values for the maximum heap space will typically provide better performance overall. However, for complete system optimization, the efficiency of your system with regard to data retrieval, caching, querying, etc., must be considered and will often be the limiting factors for performance.
Line 32:		Line 32:
	Perform the following steps to enable memory logging for AppBoard to a file:		Perform the following steps to enable memory logging for AppBoard to a file:
	# Go to [AppBoard_Home]/server/bin/setenv.bat (or setenv.sh on Unix).		# Go to [AppBoard_Home]/server/bin/setenv.bat (or setenv.sh on Unix).
	# Open the file in a text editor. You will see a line similar to the following:		# Open the file in a text editor. You will see a line near the bottom of the file similar to the following:
	#: <code>[xml,N]set JAVA_OPTS=%~~JAVA_OPTS~~% -~~Xmx2048m -Xms256m~~</code>		#: <code>[xml,N]set JAVA_OPTS=-Xmx%JAVA_MEMORY_MAX%m ... -Dkeystore.pass=%KEYSTORE_PASS%</code>
	# Add the Xlogcc parameter, such as in the following example:		# Add the Xlogcc parameter, such as in the following example:
	#: <code>[xml,N]set JAVA_OPTS=%~~JAVA_OPTS~~% -~~Xmx2048m -Xms256m~~ -Xloggc:c:\GCout.txt</code>		#: <code>[xml,N]set JAVA_OPTS=-Xmx%JAVA_MEMORY_MAX%m ... -Dkeystore.pass=%KEYSTORE_PASS% -Xloggc:c:\GCout.txt</code>

imported>Mike.berman: changes from peer review

2012-03-01T19:47:41Z

changes from peer review

← Older revision		Revision as of 19:47, 1 March 2012
Line 23:		Line 23:

	Depending on the RAM on your AppBoard server, higher values for the maximum heap space will typically provide better performance overall. However, for complete system optimization, the efficiency of your system with regard to data retrieval, caching, querying, etc., must be considered and will often be the limiting factors for performance.		Depending on the RAM on your AppBoard server, higher values for the maximum heap space will typically provide better performance overall. However, for complete system optimization, the efficiency of your system with regard to data retrieval, caching, querying, etc., must be considered and will often be the limiting factors for performance.


	== Monitoring Garbage Collection ==		== Monitoring Garbage Collection ==

imported>Cmace: copied over from internalwiki

2011-08-05T14:29:39Z

copied over from internalwiki

New page

This page details some settings that the AppBoard system administrator can modify to allocate the proper amount of server memory to AppBoard.

== Allocating Additional Memory ==

{{Tip|If your system is experiencing lags 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. In the case of most JVMs, the default setting of the maximum heap size is 64MB. You can increase the maximum heap size of applications by setting the -Xmx JVM parameter. For example -Xmx1024m allows maximum 1GB (1024MB) heap to be allocated for the JVM. It is recommended to specify a considerably lower value than the total amount of physical RAM on the server, so the operating system and other applications will also have enough space. Otherwise, the swap memory of the operating system will be used, which can result in high disk activity, and reduced system performance.

Perform the following steps to review the memory heap size settings for AppBoard:
# Go to [AppBoard_Home]/server/bin/setenv.bat (or setenv.sh on Unix).
# Open the file in a text editor. You will see lines similar to the following:
<code>[xml,N]set JAVA_OPTS=%JAVA_OPTS% -Xmx1536m -Xms256m
rem set JAVA_OPTS=%JAVA_OPTS% -Xmx2048m -Xms256m</code>

The limit for 32-bit operating systems is less than the 4096 MB of theoretical address space. For Windows, the real limit is under 1600 MB (due to memory used for non-heap storage and Windows limitation of user space addressable memory to under 2048 MB), which is why the default is 1536 MB (512 MB x 3). If AppBoard is running on both a 64-bit operating system and a 64-bit Java, it can support a higher setting for the heap size. For example, you can increase the memory available to Tomcat from 1536 MB to 2048 MB by activating the second setting, as follows:

<code>[xml,N]rem set JAVA_OPTS=%JAVA_OPTS% -Xmx1536m -Xms256m
set JAVA_OPTS=%JAVA_OPTS% -Xmx2048m -Xms256m</code>

Depending on the RAM on your AppBoard server, higher values for the maximum heap space will typically provide better performance overall. However, for complete system optimization, the efficiency of your system with regard to data retrieval, caching, querying, etc., must be considered and will often be the limiting factors for performance.

== Monitoring Garbage Collection ==

If you are experiencing a memory leak, and would like to carefully report on each garbage collection event, you can log this data to a file by using the <tt>-Xloggc:file</tt> Java Option. Each reported event will be preceeded by the time (in seconds) since the first garbage-collection event.

Always use a local file system for storage of this file to avoid stalling the JVM due to network latency.

Perform the following steps to enable memory logging for AppBoard to a file:
# Go to [AppBoard_Home]/server/bin/setenv.bat (or setenv.sh on Unix).
# Open the file in a text editor. You will see a line similar to the following:
#: <code>[xml,N]set JAVA_OPTS=%JAVA_OPTS% -Xmx2048m -Xms256m</code>
# Add the Xlogcc parameter, such as in the following example:
#: <code>[xml,N]set JAVA_OPTS=%JAVA_OPTS% -Xmx2048m -Xms256m -Xloggc:c:\GCout.txt</code>