a9s Elasticsearch Resources Considerations
This document describes concerns and limitations to be considered when allocating resources for your a9s Elasticsearch plans.
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.
Elasticsearch runs in a JVM, a9s Elasticsearch
configures the maximum and minimum heap size (
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.
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
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).
Elasticsearch stores indices on
directory, a9s Elasticsearch configures the maximum size of the indices store to
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.