a9s Elasticsearch Resources Considerations

This document describes concerns and limitations to be considered when allocating resources for your a9s Elasticsearch plans.

Backup Storage

a9s Elasticsearch uses S3 Repository and Azure Repository for backup and restore. Those are the only backend storage supported for a9s Elasticsearch and currently they do not support SSL with unknown certificate issuers.

Reserved Memory

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

a9s Elasticsearch does not limit the size of memory that can be locked, as soon as Elasticsearch starts, the heap size is locked from the total memory, making it unavailable for other processes.

File Descriptors

Elasticsearch uses a lot of files. It can happen that in a given moment, a vast number of files are open by the Elasticsearch processes. a9s Elasticsearch configures the service instances with a maximum of open files of 65536 (ulimit -n 65536). Bear this in mind in case your usage of the cluster favors opening a vast number of files.

If the Elasticsearch process runs out of file descriptors, data loss might happen.

Number of Threads

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

Indices Store

Elasticsearch stores indices on mmapfs directory, a9s Elasticsearch configures the maximum size of the indices store to 262144 (sysctl -w vm.max_map_count=262144). Note that this configuration applies to memory that is used, but not taking into account for the heap size.