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