Skip to main content
Version: 76.0.0

Resource Considerations

This document describes resource considerations and limitations to be taken into account when provisioning and operating a9s Search Service Instances.

The resource requirements of a Service Instance depend on the Template selected for its Service Plan. Each Template defines the topology (number of nodes) and the set of colocated processes. Templates that provide logging require a higher-memory VM type and more ephemeral disk than Templates without logging.

The Platform Operator must define matching vm_type and persistent_disk_type entries in the BOSH Cloud Config and reference them from the Service Plan configuration. For guidance on Service Plans and Templates, see Service Plans and Available Templates.

For guidance on Service Plans and Templates, see Service Plans and Available Templates.

Template Requirements

The resource requirements of a Service Instance depend on the Template selected for its Service Plan. The small, medium, and large labels used for VM type and persistent disk type in the tables below refer to the example Cloud Config entries defined in Update the Cloud Config.

Templates that provide logging require a higher-memory VM type than Templates without logging.

Logging Templates and RAM

Templates that provide logging reserve at least 512 MB of RAM for the logging process, in addition to the memory required by the data service process itself. Provisioning 512 MB of additional headroom above this minimum is recommended, to comfortably absorb the logging overhead.

The following table lists resource requirements per VM, as well as totals across all nodes of a Service Instance.

Template nameNodesvCPUsLoggingSSLMin. RAMMin. Persistent DiskMin. Ephemeral DiskExample VM TypeExample Persistent Disk Type
search2-single-ssl14YesYes8 GB20 GB5 GBlargelarge
search2-single-no-logging-ssl12NoYes4 GB20 GB5 GBsmalllarge
search2-cluster-ssl34YesYes8 GB20 GB5 GBlargelarge
† Includes the RAM reserved for the logging process. See the note above.
Heavier Process Load Requires More RAM

a9s Search runs a greater number of memory-intensive processes than most other Data Services, in particular a JVM-based OpenSearch process with a substantial heap allocation. While the strict minimum for a single-node Template without logging is 4 GB, a VM type with at least 8 GB of RAM is strongly recommended for any Search Template, and required for any Template with logging enabled.

Disk Sizing for OpenSearch

The recommended minimum disk type is a safe minimum; production deployments must plan capacity based on expected log volume and desired retention period.

In particular, OpenSearch stores all index data on persistent disk, and JVM heap dumps on out-of-memory events can consume several additional gigabytes. Even a modest volume of index data can quickly exceed 4 GB.

Reserved Memory

OpenSearch runs in a JVM. a9s Search configures the maximum and minimum heap size (-Xms and -Xmx) with 46% of total memory. Memory is also used for other essential operations, so it is normal for an OpenSearch process to report higher memory usage than this. The remaining available memory is shared between other internal OpenSearch processes, side processes, and the OS.

a9s Search does not limit the amount of memory that can be locked. When OpenSearch starts, the heap size is locked from total memory, making it unavailable for other processes.

File Descriptors

OpenSearch opens a large number of files during normal operation. a9s Search configures Service Instances with a maximum of 65536 open files (ulimit -n 65536). This limit is relevant when the cluster is configured to open a large number of files simultaneously.

If the OpenSearch process exhausts its file descriptors, data loss may occur.

Number of Threads

OpenSearch uses a thread pool for multiple operations. a9s Search configures the maximum number of processes for OpenSearch as 4096 (ulimit -u 4096).