2.5 引导检查

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

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

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

发展模式与生产模式:
默认情况下，Elasticsearch绑定到用于HTTP和传输（内部）通信的环回地址。这对于下载和使用Elasticsearch以及日常开发很好，但对于生产系统来说没用。
要加入群集，必须通过传输通信访问Elasticsearch节点。要通过非回送地址加入群集，节点必须将传输绑定到非回送地址，而不是使用单节点发现。
因此，如果Elasticsearch节点无法通过非回送地址与另一台机器形成群集，并且处于生产模式（如果它可以通过非回送地址加入群集），那么我们认为Elasticsearch节点处于开发模式。

请注意，HTTP和传输可以通过http.host和transport.host独立配置;
这对于配置单个节点可通过HTTP进行测试而不触发生产模式很有用。

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

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

2.5.1 堆大小检查

如果JVM以初始和最大堆大小不等的方式启动，则在系统使用过程中调整JVM堆的大小时，容易导致暂停。
为了避免这些调整大小暂停，最好使用初始堆大小等于最大堆大小来启动JVM。此外，如果启用bootstrap.memory_lock，则JVM将在启动时锁定堆的初始大小。
如果初始堆大小不等于最大堆大小，那么在调整大小后，将不会出现所有JVM堆都锁定在内存中的情况。
要通过堆大小检查，您必须配置堆大小。

2.5.2 文件描述符检查

文件描述符是用于跟踪打开的“文件”的Unix结构。
但是在Unix中，一切都是文件。例如，“文件”可以是物理文件，虚拟文件（例如/ proc / loadavg）或网络套接字。
Elasticsearch需要大量的文件描述符（例如，每个分片由多个段和其他文件组成，加上到其他节点的连接等）。
此引导程序检查在OS X和Linux上实施。
要通过文件描述符检查，您可能必须配置文件描述符。

2.5.3 内存锁 检查

当JVM执行主要垃圾收集时，它会触及堆的每一页。
如果这些页面中的任何一个被换出到磁盘上，它们将不得不被换回到存储器中。
这会导致大量磁盘抖动，Elasticsearch更愿意用它来处理请求。
有几种方法可以配置系统禁止交换。
一种方法是通过请求JVM通过mlockall（Unix）或虚拟锁（Windows）将内存锁定在内存中。
这是通过Elasticsearch设置bootstrap.memory_lock完成的。
但是，有些情况下可以将此设置传递给Elasticsearch，但Elasticsearch无法锁定堆（例如，如果elasticsearch用户不具有memlock unlimited）。
内存锁定检查验证如果启用了bootstrap.memory_lock设置，则JVM已成功锁定堆。
要传递内存锁定检查，您可能必须配置bootstrap.memory_lock。

2.5.4 最大线程数检查

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

2.5.5 最大大小的虚拟内存检查

Elasticsearch和Lucene使用mmap很好地将索引的一部分映射到Elasticsearch地址空间。
这可以将某些索引数据保留在JVM堆中，但可以在内存中快速访问。
为了有效，Elasticsearch应该有无限的地址空间。
最大大小的虚拟内存检查强制Elasticsearch进程具有无限的地址空间，并且仅在Linux上执行。
要通过最大容量的虚拟内存检查，您必须配置您的系统以允许Elasticsearch进程拥有无限制的地址空间。
这可以通过/etc/security/limits.conf使用as设置为unlimited来完成（请注意，您可能还必须增加root用户的限制）。

2.5.6 最大文件大小检查查

作为单独分片组件的分段文件和作为转换日志组件的translog生成的分段文件可能会变大（超过几GB）。
在可以由Elasticsearch进程创建的文件的最大大小有限的系统上，这可能会导致写入失败。
因此，这里最安全的选项是最大文件大小是无限的，这是最大文件大小引导程序检查执行的内容。
要通过最大文件检查，您必须配置您的系统以允许Elasticsearch进程能够写入无限大小的文件。
这可以通过/etc/security/limits.conf使用fsize设置为unlimited来完成（请注意，您可能还必须增加root用户的限制）。

2.5.7 最大地图数量检查(Maximum map count check)

继续前面的观点，为了有效地使用mmap，Elasticsearch还需要能够创建许多内存映射区域。
最大映射计数检查检查内核是否允许进程拥有至少262,144个内存映射区域，并且仅在Linux上实施。
要通过最大映射计数检查，您必须通过sysctl配置vm.max_map_count至少为262144。

2.5.8 客户端JVM检查

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

2.5.9 使用串行收集器检查

针对不同工作负载的OpenJDK衍生JVM有各种垃圾收集器。
串行收集器尤其适用于单逻辑CPU机器或极小的堆，这两种都不适合运行Elasticsearch。
对Elasticsearch使用串行收集器可能会对性能造成破坏性影响。
串行收集器检查可确保Elasticsearch未配置为与串行收集器一起运行。
要传递串行收集器检查，您不得使用串行收集器启动Elasticsearch（无论是使用JVM的默认值，还是使用-XX：+ UseSerialGC明确指定它）。
请注意，Elasticsearch附带的默认JVM配置将Elasticsearch配置为使用CMS收集器。

2.5.10 系统调用过滤器检查

Elasticsearch根据操作系统安装各种风格的系统调用过滤器（例如，Linux上的seccomp）。
安装这些系统调用筛选器是为了防止执行与分叉有关的系统调用作为针对Elasticsearch上的任意代码执行攻击的防御机制的能力系统调用筛选器检查可确保如果系统调用筛选器已启用，则它们已成功安装。
要通过系统调用过滤器检查，您必须修复系统中阻止系统调用过滤器安装（检查日志）的任何配置错误，或者由您自担风险，通过将bootstrap.system_call_filter设置为false来禁用系统调用筛选器。

2.5.11 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时将不支持任意分叉。

2.5.12 早期访问检查

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

2.5.13 G1GC检查

已知JDK 8附带的HotSpot JVM的早期版本在启用G1GC收集器时会导致索引损坏。
受影响的版本是早于JDK 8u40附带的HotSpot版本的版本。
G1GC检查可检测到HotSpot JVM的这些早期版本。

2.5.14 所有权限检查

全部权限检查可确保引导过程中使用的安全策略不会将java.security.AllPermission授予Elasticsearch。以授予的所有权限运行相当于禁用安全管理器。