早期版本的Elasticsearch将配置错误打印在 WARNING 日志中，容易被忽视。后来，Elasticsearch引入了引导检查（Bootstrap Check）。

引导检查将确保Elasticsearch和系统设置对Elasticsearch来说是安全的。如果在开发模式，检查失败会打印在 WARNING 日志中；生产模式中，检查失败会终止Elasticsearch启动进程。

堆大小

如果堆的初始size和最大size不同，那么JVM就会暂停来 resize。因此，两者最好是相同的。

如果启用bootstrap.memory_lock，JVM会在启动时锁定堆的初始size。如果堆的初始size和最大size不同，resize 之后JVM的堆就不会锁定。

默认情况下，Elasticsearch使用2 GB的堆。使用Xms（堆最小size）和Xmx（堆最大size）。设置堆大小的原则有：

• Xms和Xmx相同。

• 堆越大，Elasticsearch可用来缓存的空间就越多。但堆太大会引发GC暂停。

• Xmx不宜超过物理RAM的50%，确保内核文件系统缓存可以使用剩余的RAM。

• Xmx不宜超过JVM compressed object pointers 。

  ​

文件描述符

Elasticsearch在多处用到了文件描述符（如，每个分片有多个segment组成）。如果文件描述符不够用了，Elasticsearch有可能丢失数据。因此必须使用ulimit打开限制。

内存锁定

为了避免内存和磁盘之间的swap，bootstrap.memory_lock可以锁定堆内存（基于mlockall）。

即便打开了bootstrap.memory_lock，Elasticsearch仍有可能无法锁定堆。

线程个数限制

Elasticsearch在接收一个请求之后，会将其分解为stage，然后将各个stage分发给不同的线程池executor。

线程的个数限制就确保Elasticsearch能够创建足够的线程来处理请求。

修改/etc/security/limits.conf中的nproc即可调整该限制。

虚拟内存最大size

Elasticsearch使用mmap将索引转换为地址空间，这时候索引数据从JVM heap中取出，但仍然驻留在内存中。这就需要确保Elasticsearch可以使用无限的地址空间：修改/etc/security/limits.conf中是as为unlimited。

最大的映射条数

为了高效使用mmap，Elasticsearch需要创建许多内存映射区域。最大的映射条数可以通过sysctl修改vm.max_map_count为至少 262144。

客户端JVM

OpenJDK家族的JVM提供了两个不同的JVM：客户端JVM和服务端JVM。两者采用不同的编译器。客户端JVM优化了启动时间、内存footprint，而服务端JVM最大化了性能。

客户端JVM检查，确保Elasticsearch不是运行在客户端JVM中。

现代操作系统中，默认的都是服务端JVM。

串行GC

串行GC适用于单个CPU、或者极小的heap，当然也就不适合Elasticsearch。

系统调用过滤

Elasticsearch安装了很多系统调用过滤器，用来滤掉一些对Elasticsearch有害的fork调用。

OnError 和 OnOutOfMemoryError

JVM的选项OnError 和 OnOutOfMemoryError让JVM在遇到上述error 的时候执行一段命令。

这个check与系统调用过滤不兼容。

G1GC

早期版本的HotSpot JVM在G1GC开启的情况下会触发索引崩溃，影响了JDK 8u40之前的版本。

G1GC检查就是剔除早期版本的HotSpot JVM。