This article details root causes as well as corrective actions to be taken in situations where an Appian environment is experiencing higher than normal memory usage. In addition, some strategies to optimize and control memory usage in Appian environments are also listed.
Using the Task Manager (Windows) or the top command (Unix) and making sure that the command path is enabled, review the currently active OS processes sorted by individual memory usage and identify one or more processes consuming the most memory. In Appian environments specifically, the top memory consumers are usually those that are listed below:
top
An increase in memory usage for the java process of the application server can indicate a potential memory leak. Review the system.csv file to analyze the heap used vs. heap available for an increasing trend. A heap dump is also helpful to detect a leak as well as its root cause. Steps to collect a heap dump can be found in KB-1176.
java
Apart from the heap space, a leak may also occur in the metaspace region. Typically this happens due to excessive class loading or a large number of static imports from custom plug-ins. Use jmap -histo <JAVA_PROCESS_ID> and jmap -clstats <JAVA_PROCESS_ID> to get information on class loader statistics to determine if this is the case.
jmap -histo <JAVA_PROCESS_ID>
jmap -clstats <JAVA_PROCESS_ID>
Note: Running jmap -clstats <JAVA_PROCESS_ID> should be performed during off-peak business hours during a scheduled outage. Running this command locks the class loader in the application server and renders it unresponsive while the command is executing.
If there are no memory leaks then the increase may be due to legitimate activity on the environment.
An increase in search server memory usage can be caused due to excessively large frequency of rule executions within the environment. This may be alleviated either partially or completely by recreating the search indices. Steps on how to do this can be found in the action section of KB-1082. If there is no significant reduction then this increase may be legitimate. In such cases, consider re-sizing the search server.
For k processes in the process list, review the command path to identify the corresponding engine. There are a number of cleanup activities to be done depending on which engines are experiencing high memory usage.
Note: Proceed with caution when exercising any of the cleanup activities described. Ensure that any objects/versions are in fact no longer needed or used before removing them. Reach out to Appian Technical Support for any questions or issues at any stage.
A restart of the environment is required after cleanup operations to release the freed up memory and obtain the current memory usage accurately.
Processes with adb pe in the command path correspond to the execution engines. A cleanup (archiving or deleting) of processes in the environment is the best way to reduce memory usage for these engines. Use the sizing section of the health check report to identify Appian processes that have the highest resource consumption.
As a best practice, avoid saving long strings (such as base64 encoded strings) as process variables or node inputs. These long strings consume execution engine memory. Instead, consider saving the strings to a database or call a web service and save the strings as documents.
Processes of type adb pa are the analytics engines. In most cases, analytics size is linked to execution engines so this is typically addressed by following the above steps for execution engines followed by an Analytics reset.
If the high memory usage persists, contact Appian Technical Support for assistance.
The design engine is the process of type adb pd. A high memory on this engine indicates a large number of design objects such as data types or process models and their versions. A cleanup of these objects is the best way to bring down the memory usage for this engine.
While data types and process models need to be cleaned up manually, process model versions can be deleted in bulk using the Process Model Utilities shared component. In general, the recommendation is not to have more than 100 versions per process model.
Note: Process model versions should only be deleted in non-production environments where processes are seldom or never unarchived. If you attempt to unarchive a process for a version of a process model that doesn't exist in this engine and if there are no running instances of that process model for that specific version, then you will be unable to successfully unarchive that process.
For the collaboration engine adb dc, the cleanup needs to be done for content objects (e.g., rules or constants) and their versions. More information on the possible causes can be found in KB-1226.
In addition to a manual cleanup, Appian Technical Support may be able to assist with identifying and removing objects and/or versions in bulk.
It is also rare for these two processes adb n and adb s to use an excessively large amount of memory, however this can happen when there are a large number of alerts in the environment for one or more users. Should this be the case, contact Appian Technical Support to coordinate the necessary actions to bring the size of these engines down.
It is unusual for collaboration statistics adb stat to consume a large amount of memory but this can happen due to a large frequency of document downloads. To coordinate the necessary cleanup operations to reduce the memory usage for this engine, contact Appian Technical Support.
For any other another Appian process(es) consuming an unusually large amount of RAM, contact Appian Technical Support for assistance.
Some strategies to proactively control memory usage of Appian environments are listed below:
If you went through all the steps in this KB article but the system is still running high on memory, feel free to add additional memory to the system.
This article applies to all versions of Appian.
Last Reviewed: May 2018