Elasticsearch 参考指南（引导检查）

引导检查

总的来说，我们有很多用户因为没有配置重要的设置而遇到意外问题的经验，在以前版本的Elasticsearch中，这些设置的错误配置被记录为警告，可以理解的是，用户有时会错过这些日志消息，为了确保这些设置得到应有的关注，Elasticsearch在启动时进行引导检查。

这些引导检查各种Elasticsearch和系统设置，并将它们与Elasticsearch操作安全的值进行比较，如果Elasticsearch处于开发模式，任何失败的引导检查都会在Elasticsearch日志中显示警告，如果Elasticsearch处于生产模式，任何引导检查失败都会导致Elasticsearch拒绝启动。

有一些引导检查总是强制执行，以防止Elasticsearch在不兼容的设置下运行，这些检查是单独记录的。

开发与生产模式

默认情况下，Elasticsearch绑定到回环地址，用于HTTP和transport（内部）通信，这对于下载和把玩Elasticsearch以及日常开发来说是很好的，但对于生产系统则毫无用处。要加入集群，Elasticsearch节点必须通过transport通信到达。要通过非回环地址加入集群，节点必须将transport绑定到非回环地址，而不是使用单节点发现。因此，如果一个Elasticsearch节点不能通过非回环地址与另一台机器形成集群，我们将其考虑为处于开发模式，如果它可以通过非回环地址加入集群，则处于生产模式。

注意，HTTP和transport可以通过http.host和transport.host单独配置，这对于将单个节点配置为可以通过HTTP访问的节点，以便在不触发生产模式的情况下进行测试非常有用。

单节点发现

我们认识到，有些用户需要将transport绑定到外部接口，以测试他们对transport客户端的使用，对于这种情况，我们提供发现single-node类型（通过将discovery.type设置为single-node来配置），在这种情况下，节点将选择自己为主节点，而不会与任何其他节点加入集群。

强制执行引导检查

如果你在生产环境中运行单个节点，有可能会避开引导检查（通过不绑定到外部接口的transport，或者绑定到外部接口并将发现类型设置为single-node）。对于这种情况，你可以通过将系统属性es.enforce.bootstrap.checks设置为true以强制执行引导检查（在设置JVM选项中设置这个，或通过添加-Des.enforce.bootstrap.checks=true到环境变量ES_JAVA_OPTS）。如果你在这种情况下，我们强烈建议你这样做，此系统属性可用于强制执行引导检查，独立于节点配置。

堆大小检查

如果JVM启动时初始堆大小和最大堆大小不相等，那么在系统使用期间JVM堆大小调整时很容易暂停，为了避免这些调整大小的暂停，最好以初始堆大小等于最大堆大小启动JVM。此外，如果启用了bootstrap.memory_lock，JVM将在启动时锁定堆的初始大小。如果初始堆大小不等于最大堆大小，那么在调整大小之后，不会将所有JVM堆锁定在内存中，要通过堆大小检查，必须配置堆大小。

文件描述符检查

文件描述符是用于跟踪打开的“文件”的Unix构造，但是在Unix中，一切都是文件。例如，“文件”可以是物理文件、虚拟文件（例如/proc/loadavg）或网络socket。Elasticsearch需要大量的文件描述符（例如，每个碎片由多个片段和其他文件组成，以及与其他节点的连接等）。这个引导检查是在OS X和Linux上执行的，要通过文件描述符检查，你可能需要配置文件描述符。

内存锁定检查

当JVM执行主要的垃圾收集时，它会触及堆的每个页面，如果这些页面中的任何一个被交换到磁盘上，它们就必须被交换回内存中，这会导致很多磁盘超负荷，而Elasticsearch更愿意使用这些磁盘来服务请求。有几种方法可以配置系统来禁止交换，一种方法是请求JVM通过mlockall（Unix）或虚拟锁（Windows）在内存中锁定堆，这是通过Elasticsearch设置bootstrap.memory_lock完成的。但是，在某些情况下，这个设置可以被Elasticsearch通过，但Elasticsearch无法锁定堆（例如，如果elasticsearch用户没有memlock unlimited）。内存检查验证，如果bootstrap.memory_lock设置已启用，则JVM能够成功锁定堆。要通过内存锁检查，你可能需要配置bootstrap.memory_lock。

最大线程数检查

Elasticsearch通过将请求分解为多个阶段并将这些阶段分配给不同的线程池执行器来执行请求，对于Elasticsearch中的各种任务，有不同的线程池执行器，因此，Elasticsearch需要能够创建许多线程。最大线程数检查确保Elasticsearch进程有权在正常使用时创建足够的线程，此检查仅在Linux上执行。如果你在Linux上，为了通过最大线程数检查，你必须配置你的系统，使Elasticsearch进程能够创建至少4096个线程。这可以通过/etc/security/limits.conf使用nproc设置完成（注意，你可能还需要增加对于root用户的限制）。

最大文件大小检查

作为单个碎片的组件的片段文件和作为translog组件的translog生成文件可能会变大（超过多个gb），在允许Elasticsearch进程创建的文件的最大大小有限的系统中，这可能导致写失败，因此，这里最安全的选项是，最大文件大小是无限的，这就是最大文件大小引导检查所执行的。要通过最大文件检查，你必须配置系统，使Elasticsearch进程能够写入无限大小的文件，这可以通过/etc/security/limits.conf使用fsize设置为unlimited实现（注意，你可能还需要增加对于root用户的限制）。

最大虚拟内存大小检查

Elasticsearch和Lucene使用mmap以极大的效果将索引的部分映射到Elasticsearch地址空间，这使某些索引数据远离JVM堆，但在内存中用于高速访问。要使其有效，Elasticsearch应该有无限的地址空间，最大的虚拟内存检查强制使Elasticsearch进程具有无限的地址空间，并且只在Linux上执行。要通过最大大小的虚拟内存检查，你必须配置你的系统，使Elasticsearch进程能够拥有无限的地址空间，这可以通过/etc/security/limits.conf使用as设置为unlimited完成（注意，你可能还需要增加对于root用户的限制）。

最大map计数检查

继续前面的内容，要有效地使用mmap, Elasticsearch还需要创建许多内存映射区域，最大映射计数检查检测内核允许进程至少有262,144个内存映射区域，并且仅在Linux上执行。要通过最大映射计数检查，你必须通过sysctl配置vm.max_map_count将为至少262144。

客户端JVM检查

OpenJDK派生JVM提供了两种不同的JVM：客户端JVM和服务器JVM。这些JVM使用不同的编译器从Java字节码生成可执行的机器码，客户端JVM为启动时间和内存占用调优，而服务器JVM为性能最大化调优。这两个VM之间的性能差异可能很大，客户端JVM检查确保Elasticsearch不在客户端JVM中运行，要通过客户端JVM检查，必须使用服务器VM启动Elasticsearch，在现代系统和操作系统中，服务器VM是默认的。

使用串行收集器检查

针对不同工作负载的OpenJDK派生JVM有各种垃圾收集器，串行收集器特别适合于单个逻辑CPU机器或非常小的堆，它们都不适合运行Elasticsearch。使用串行收集器与Elasticsearch一起会对性能造成极大的破坏，串行收集器检查确保Elasticsearch没有配置为与串行收集器一起运行。要通过串行收集器检查，你不能启动Elasticsearch与串行收集器一起（无论是你使用的JVM的默认值，还是用-XX:+UseSerialGC显式地指定它）。注意，与Elasticsearch一起附带的默认JVM配置配置使Elasticsearch能够使用CMS收集器。

系统调用过滤器检查

Elasticsearch根据操作系统（如Linux上的seccomp）安装各种类型的系统调用过滤器，安装这些系统调用过滤器是为了防止执行与分叉相关的系统调用，作为在Elasticsearch上针对任意代码执行攻击的防御机制，系统调用过滤器检查确保如果启用了系统调用过滤器，那么就成功安装了它们。要通过系统调用过滤器检查，你必须修复系统上阻止系统调用过滤器安装的任何配置错误（检查日志），或者通过将bootstrap.system_call_filter设置为false，在你自己的风险下禁用系统调用过滤器。

OnError和OnOutOfMemoryError检查

如果JVM遇到致命错误（OnError）或OutOfMemoryError （OnOutOfMemoryError），JVM选项OnError和OnOutOfMemoryError允许执行任意命令。但是，默认情况下，启用了Elasticsearch系统调用过滤器（seccomp），这些过滤器防止分叉，因此，使用OnError或OnOutOfMemoryError和系统调用过滤器是不兼容的。如果使用了这些JVM选项中的任何一个，并且启用了系统调用过滤器，OnError和OnOutOfMemoryError检查阻止了Elasticsearch启动。这个检查总是强制执行的，要通过此检查，请不要启用OnError或OnOutOfMemoryError。相反，升级到Java 8u92并使用JVM标志ExitOnOutOfMemoryError，虽然它不具备OnError和OnOutOfMemoryError的全部功能，但启用了seccomp的情况下不支持任意分叉。

早期访问检查

OpenJDK项目提供了即将发布的版本的早期访问快照，这些版本不适合生产，早期访问检查检测这些早期访问快照，要通过这个检查，你必须在JVM的发布版本上启动Elasticsearch。

G1GC检查

众所周知，JDK 8附带的HotSpot JVM的早期版本在启用G1GC收集器时存在可能导致索引损坏的问题，受影响的版本是那些比JDK 8u40附带的HotSpot版本更早的版本，G1GC检查检测HotSpot JVM的这些早期版本。

所有权限检查

所有权限检查确保引导期间使用的安全策略不授予Elasticsearch java.security.AllPermission，在授予所有权限的情况下运行等同于禁用安全管理器。

---

上一篇：重要的系统配置

下一篇：启动Elasticsearch