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 each of the k processes in the process list, review the command path to identify the corresponding engine. Several cleanup activities may be required depending on which engines are experiencing high memory usage.
Important:
Proceed with caution when performing any cleanup activities described below. Ensure that any objects or versions are truly no longer needed before removing them. Contact Appian Technical Support if you have questions or encounter any issues during the process.
A restart of the environment is required after cleanup operations to release freed memory and obtain accurate current memory usage.
Memory usage for the execution engines is tied to the total number of process instances in the environment, including:
Running processes
Completed processes
Inactive or stale processes
Unarchived historical processes
All of these remain loaded in execution-engine memory until they are archived or deleted.
Review and clean up process instances by archiving or deleting those that are no longer needed.
Use the Appian Health Check report specifically the Sizing section to identify:
Process models that generate large volumes of instances
Processes with unusually large memory footprints
Areas where process cleanup will have the greatest impact
Execution-engine memory is also heavily affected by the size of process variables (PVs). Appian allocates memory based on the values of PVs even for completed processes that have not yet been archived.
Best Practices:
Avoid storing large strings (e.g., Base64-encoded data, large JSON/XML payloads) in PVs or node inputs.
Store large content in a document, database table, or external storage service instead.
Keep PVs small and structured where possible to minimize memory retention.
The analytics engines maintain aggregated data for process instances, so their memory usage is typically correlated with the execution engines.
Perform cleanup on execution-engine processes first (archive/delete).
Review the Health Check report for analytics-related findings (e.g., oversized analytics caches or unusually large process volumes).
Perform an Analytics Reset.
This is a key step in releasing stale analytics data and rebuilding the analytics indexes.
An analytics reset typically reduces PA engine memory significantly once underlying process data has been cleaned up.
If memory usage remains high after cleanup and an analytics reset, contact Appian Technical Support for deeper analysis or specialized cleanup operations.
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: November 2025