KB-2288 Application Server Heap Memory FAQ

Table of Contents:

Note : There are many Appian components that allocate their own heap memory space. This article only applies to the heap memory allocated to the application server. 

What is heap?

Heap, also known as heap memory, is the portion of hardware memory that is allocated to the Java Virtual Machine that is running the application server. The heap memory is consumed only by the application server and enables it to perform all the actions required to run your Appian environment and interact with all the other Appian components on your environment. 

What is the difference between heap memory and total memory of the application server?

The default amount of heap allocated to an application server in Appian Cloud is 3 GB. The total physical memory used by the application server is always more than the allocated heap memory given to the application server. This is because the application server runs as a Java process which also includes a Java Virtual Machine (JVM). The heap memory exists inside the JVM, and the Java process and JVM also require their own portion of the physical memory to run.

To see more information on the physical memory used by the application server, please see the following Knowledge Base article: KB-1248 How to address high memory usage in self-managed Appian environments.

What is garbage collection?

As the application server runs, it loads runtime objects into the heap memory. Heap memory will become exhausted unless the objects that are no longer needed from the heap memory are removed by a process called Garbage collection.

Garbage collection is a form of automatic heap memory management which frees currently unreferenced objects stored in heap. Garbage collection is accomplished with a set of algorithms which organize, scan, and free unneeded objects from heap memory. Appian uses the G1 Java garbage collector algorithm as of Appian version 20.1. 

When is heap usage a concern?

High heap alone is nothing to be concerned about. If all the required objects to complete an item of work are in the heap memory, the work item will perform identically regardless of how much of the heap memory is utilized. 

High heap utilization, and consequently garbage collection events, are expected behavior and not indicative of any environment performance or configuration issues. Garbage collection can lead to performance issues when it occurs at a high frequency, which often indicates a problematic activity that is either processing too many objects in memory, processing objects that are too large, or both. 

Customers can investigate heap utilization and garbage collection performance by inspecting the system metrics log, which for Appian Cloud customers can be accessed via the system logs page. Appian Cloud customers can conveniently leverage the inbuilt monitoring provided within MyAppian to more easily view their heap utilization and garbage collection performance.

What are some common heap issues?

There are two effects of performance issues with heap memory in an Appian environment:

  1. Slowness across the entire environment
  2. An application server crash and restart

Note: An application server crash on an environment with only one application server node will always result in a complete site outage until the affected application server finishes restarting. 

1. Slowness across the entire environment

Slowness across the entire environment can be caused by the garbage collection process running too often. This occurs when the rate of new objects being introduced into the heap memory is higher than garbage collection can keep up with, or when there are long-lived objects in the heap memory that cannot be removed because they are being referenced by a long-running activity. 

Common causes of this issue include:

  • Large looping, text manipulation or array-based operations
  • Inefficient application design and/or excessive volume of work
  • Undersized heap memory allocation relative to the workload required

2. An application server 'crash' and restart

An application server restart occurs when the application server is unable to load necessary objects into heap memory without exceeding the heap space limit. In this situation an 'OutOfMemoryError' Java Exception may be thrown in the application server log, after which the application server is then forcibly ‘crashed’ and restarted. An application server restart may or may not proceed a period of environment slowness due to garbage collection.

Common causes of an application server restart include:

  • Queries with large result sets
  • Document generation using plugins
  • Very large process variables or inputs
  • Any of the above causes of slowness

How to fix common heap issues?

The behavior of the application server heap memory is directly affected by user and process activity. Therefore, identifying and modifying the problematic activity is the primary solution for remediating performance issues involving heap memory. 

1. Slowness across the entire environment

Slowness can be representative of a high and/or excessively complex volume of work. The main troubleshooting steps are to identify the implicated activity using logs and heap dumps, determine whether the load is expected/required, and action any opportunities for optimization.

Some solutions for remediating slowness related to garbage collection include:

  • Avoid running bulk processes simultaneously
  • Re-designing intensive processes to run gradually over a longer time frame
  • Avoiding logic that operates on and/or iterates large arrays of texts or objects
  • Running intensive process(es) during business off hours where there are fewer concurrent users
  • Re-designing the application causing the excessive volume, starting with the most expensive operations

Slowness can also be representative of a long running process that continuously holds references to an increasing number of objects in the heap memory. The process monitoring view can be used to identify and kill long running processes that are actively causing slowness across the entire environment. The identified processes should then be redesigned to not require continuous object references over an extended time period.

2. An application server 'crash' and restart

Processes that cause application server restarts will usually require a re-design to break the large size or amount of objects manipulated into smaller volumes that the application server heap memory can accommodate. 

Some solutions include:

  • Adding additional filters and/or batching to problematic queries
  • Limiting the size of uploaded documents before they are manipulated
  • Any of the above recommendations to remediate slowness

Will increasing the heap memory allocation help improve performance?

Increasing the allocated heap memory to the application server has the consequence of reducing the remaining available memory for all the other Appian components to run on your environment. This can include, but is not limited to:

  • Appian Engines
  • Search Server
  • Data Server
  • Database
  • RPA

Therefore, increasing the heap memory allocated to the application server should only be considered if there is more than enough memory available on the environment during peak usage. Additionally, increasing the heap memory allocation is not a universal solution to all heap memory performance issues. Some causes of heap memory performance issues will still impact performance regardless of the size of the heap memory.

Some scenarios where increasing the heap memory would be considered can include, but is not limited to:

  • An overwhelming amount of resources being available in the environment
  • Process load 

Recommendations to increase heap memory allocated are discussed on a case by case basis. Appian Support carefully evaluates this option when handling performance-related Support Cases and will recommend an increase if it will improve the performance of your environment. 

What is a heap dump?

A heap dump is a snapshot of the entire contents of heap memory, written to disk as a single file. Heap dumps are analyzed by Appian Support in order to investigate what was being processed by the application server during the time that the heap dump was taken.

The size of the heap dump on disk directly correlates to the magnitude of the heap utilization at the time that the heap dump was taken. Additionally, Appian Support creates more files to aid in analyzing the generated heap dump. As a result, when heap dumps are generated and investigated, there will be an increase in the disk consumption on the environment. 

For Appian Cloud customers, Appian Support can generate heap dumps directly on the Appian Cloud server. 

For Self Managed customers, Appian Support may request for a heap dump from your application server. Please use the following Knowledge Base article for instructions on how to do so: KB-1176 How to generate a Java heap dump

Note: Heap dumps contain sensitive information.

Why does Appian Support need a maintenance window to analyze a heap dump in Appian Cloud?

Heap dumps contain sensitive information that should not be shared or stored in insecure locations. For Appian Cloud customers, heap dumps are analyzed directly on their Appian Cloud site.

The process to analyze heap dumps requires an amount of memory that is proportional to the size of the heap dump that is being analyzed. In cases where Appian Support identifies that the available resources on the site are not enough to safely run the heap analysis, a maintenance window is required to complete the analysis. During the maintenance window, some Appian components are gracefully brought down in order to free memory to run the heap analysis.

Affected Versions

This article applies to all versions of Appian.

Last Reviewed: January 2024

Related
Recommended