Heap size check
|
- Checks to see if the JVM initial heap size is equal to the maximum heap size. If the initial heap size is less than the maximum heap size, the system may pause while the JVM heap resized.
- If bootstrap.memory_lock is enabled, the JVM will lock the initial heap size on startup. If initial heap is locked but is not the same size as max heap, not all of the JVM heap will be locked in memory.
|
Configure heap size via jvm.options configuration file (default location: config/jvm.options).
|
| File descriptor check (Linux and macOS only) |
- Elasticsearch requires all file descriptors to be defined.
- This requirement is only applicable to Linux and macOS; the JVM for Windows uses an API that is only limited by available resources. For Unix, everything can be a file, and therefore Linux requires descriptors.
|
Configure file descriptors to increase the limit on the number of open files descriptors for the user running Elasticsearch to 65,536 or higher.
|
| Memory lock check |
- JVM checks every page in the heap when doing a major garbage collection, even if the pages are swapped out to disk.
|
To disable page swapping, enable mlockall (Unix) or VirtualLock (Windows) by adding the following line to the elasticsearch.yml file:
bootstrap.memory_lock: true
|
| Maximum number of threads check is too low (Linux only) |
- Elasticsearch executes requests by breaking them down into stages and distributing them to different thread pool executors. To ensure Elasticsearch has the ability to create the threads it needs to perform optimally, it requires access to create at least 2048 threads.
- Different users can have different limits. Use ulimit -u to see how many threads the current user can access.
- For more information, visit the Elasticsearch documentation on Max Number of Threads.
|
Configure the nproc setting via limits.conf (default location: /etc/security/limits.conf) - both soft and hard settings
Set ulimit -u 4096 as root before starting Elasticsearch, or by set nproc to 4096 in /etc/security/limits.conf.
|
| Maximum size virtual memory check (Linux only) |
- Elasticsearch uses mmap to map parts of an index into the Elasticsearch address space in order to keep certain index data in memory instead of the JVM heap. This check ensures that Elasticsearch has the unlimited address space it needs in order to use mmap effectively.
- For more information, visit the Elasticsearch documenation on Virtual Memory.
|
As root, run this command:
sysctl -w vm.max_map_count=262144
|
| Maximum map count check (Linux only) |
- To use mmap effectively, Elasticsearch needs access to create memory-mapped areas (in addition to unlimited address space). This check makes sure that the kernel allows a process to have at least 262,144 memory-mapped areas.
|
Configure vm.max_map_count to be at least 262144 via sysctl
|
| Client JVM check |
- This check makes sure that Elasticsearch is not running through the client JVM.
|
Start Elasticsearch with the server VM (configured by default to server VM).
|
| Use serial collector check |
- This check verifies that the serial collector is not run with Elasticsearch. (The serial collector is best suited for single logical CPU machines or small heaps.)
- By default, the JVM configuration that is shipped with Elasticsearch configures Elasticsearch to use the CMS collector, not the serial collector.
|
Do not start Elasticsearch with the serial collector.
- Configure this setting either through the default JVM configurations, or explicitly with command:
-XX:+UseSerialGC
- jvm.options has a section for GC configuration
|
| System call filter check |
- Elasticsearch installs various system call filters depending on the operating system. System call filters prevent the ability to execute system calls related to forking and provide a security mechanism against arbitrary code execution attacks on Elasticsearch.
- The system call filter ensures that if system call filters are enabled, then they must have been successfully installed.
|
Fix any logged configuration errors on your system that prevented system call filters from installing.
|
| OnError and OnOutOfMemory checks |
- These checks prevent Elasticsearch from starting if both the system call filters and the OnError/OnOutOfMemoryError settings are enabled.
- If the JVM encounters a fatal error (OnError) or out of memory error (OnOutOfMemoryError), the OnError and OnOutOfMemory options enable executing of arbitrary commands. By default, Elasticsearch has system call filters enabled and therefore prevents the execution of arbitrary commands. System call filters and OnError/OnOutOfMemoryError settings are not compatible.
|
Do not enable OnError or OnOutOfMemoryError
- The alternative ExitOnOutOfMemoryError flag requires an upgrade to Java 8u92, which will allow seccomp enabled but not support arbitrary forking.
|
| G1GC check |
- This check will detect early versions of HotSpot JVM. Early versions of HotSpot JVM shipped with JDK 8 have known issues that lead to index corruption when the G1GC collector is enabled.
|
Likely requires an upgrade to the HotSpot JVM (not explicitly stated by the documentation)
|
