Save Memory by Suspending Applications
Many projects require a significant amount of resources, due to the memory footprint of each running application. To free CPU and memory resources, it is possible to automatically suspend applications that have not been accessed in a specified period of time.
Another advantage of automatic suspension is that users can restart applications that are configured to automatically suspend when they need them. Users can restart applications not only if they are automatically suspended, but also in any of these statuses: not running, sleeping, killed, unknown, failed, stopped.
The automatically suspending application or its index engine can be started from the Axcelerate 5 Navigation page.
The period of idle time is a pod-wide setting, i.e., it is the same for all projects that depend on the same master service. The default period of idle time is one hour. An Administrator can configure all applications or individual applications to suspend automatically.
Applications and index engines that are automatically suspended, are shown with Not running status in CORE Administration. Exception: Axcelerate Review & Analysis applications are set to status Sleeping.
Note: Autostart and automatic suspension have been designed to work mutually exclusive. Please carefully check if using both is working as expected for your specific use case. In this case the software has to be used as is. Perceived inconsistencies cannot be supported.

Depending on project configuration, there may be some jobs that are run on a regular basis. In Axcelerate 5 matters, these may be, e.g.:
- Scheduled workflow searches
- Scheduled batching jobs
- Automatic universe updates
- Pre-conversion rule jobs
- Scheduled Predictive Coding iterations
- Business Intelligence updates
In other applications, these may be, e.g., scheduled data loading and SmartTagging jobs.
Scheduled jobs do not prevent a project from suspending. For example, the pre-conversion rule job is scheduled to run every five minutes by default. If it runs, and there is no user activity in the front-end or backend during the configured idle time, the application and index engines are suspended after the job is finished.
Scheduled training or tagging jobs are checked when a user or administrator restarts. If they are overdue, they are run within the first 30 minutes after restart. The system distributes starting times for outstanding jobs, to avoid that all jobs are started at the same time.

Any scripts that periodically connect with engines can prevent index engines from automatic suspension.
Workarounds would be to either configure a shorter timeout for automatic suspension, or to choose a longer polling interval for the scripts.