ES6.0.0官方参考指南翻译~安装ES~启动检查
引导检查/启动检查
总的来说，对于用户遭遇意外问题的原因，我们有相当丰富的经验，绝大部分原因都是因为没有配置重要设置而引起的.在之前的Elasticsearch版本中，某些错误配置会记录为警告.因此，在这种情况下，用户会错过一些日志消息.为确保这些设置得到用户的关注，Elasticsearch在启动时引入了引导检查(bootstrap checks).
这些引导检查会检查各种Elasticsearch设置和系统设置，并将这些设置值与安全操作Elasticsearch的值进行比较.如果Elasticsearch运行于开发模式，那么所有检查为失败的设置在Elasticsearch日志中都会记录为警告(在这种情况下，Elasticsearch仍能启动).如果Elasticsearch运行于生产模式，那么所有检查为失败的设置都将导致Elasticsearch无法启动.
为防止使用不兼容的设置来运行Elasticsearch，有些引导检查是强制性的.这些检查会在文档中单独记录.
开发vs生产模式
缺省情况下，Elasticsearch会将HTTP和 transport (internal)通信绑定环回地址(loopback addresses). 但这种模式只适用于日常开发，对于生产系统毫无用处. 要加入集群， Elasticsearch节点之间必须通过transport进行通信.要通过非环回地址加入集群，节点必须将transport绑定到非环回地址上，且不使用单节点发现. 因此，如果Elasticsearch节点无法通过非环回地址与另一台机器形成集群，则我们认为它处于开发模式，反之则处于生产模式。
请注意，HTTP和 transport可分别通过http.host和transport.host来配置; 这样就可在不触发生产模式的情况下，使用HTTP来对单个节点进行测试。
单节点发现
我们意识到有些用户为了测试transport client会将transport绑定到外部接口. 针对这种情况，我们提供了single-node发现类型(可设置discovery.type为single-node来配置); 在这种情况下，节点会选择自身作为master，并且也不会与其它节点组成集群.
强制引导检查
当生产中只运行一个节点时可避开引导检查(即不将transport绑定到外部接口，或者绑定到外部端口时设置发现类型为single-node). 对于这种情况，你可以设置系统属性es.enforce.bootstrap.checks：true来强制引导检查(可通过JVM选项设置，或在ES_JAVA_OPTS环境变量中增加-Des.enforce.bootstrap.checks=true选项来设置).
如果您面对的是这种情况，我们强烈建议您做这些设置.该系统属性可强制执行单节点的引导检查。
Heap大小检查
如果以不同大小的初始和最大堆来启动JVM，那么在系统使用期间调整JVM堆的大小时，它可能会暂停。要避免调整暂停，最好以相同大小的初始堆和最大堆来启动JVM.
此外，如果启用了bootstrap.memory_lock，则JVM将在启动时锁定堆的初始大小.
如果初始堆大小不等于最大堆大小，则调整后会出现并非所有JVM堆都锁定在内存中的情况。
要通过heap大小检查，你必须配置heap size.
文件描述符检查
文件描述符是跟踪文件的Unix构造.在Unix中，所有东西都是文件. 例如，"files"可以是物理文件，虚拟文件(例如, /proc/loadavg),或网络套接字. Elasticsearch需要大量文件描述符(例如,每个分片都由多个段和其它文件加上其它节点的连接所构成). 该引导检查在OS X和Linux上是强制执行的.要通过文件描述符检查，你必须配置文件描述符.
内存锁定检查
当JVM执行主垃圾回收时，它会接触heap的每个页面.如果这些页面中的任意页面被交换到了磁盘，那么必须将它们交换回内存。但这会造成大量的磁盘颠簸，Elasticsearch更愿意使用它来处理请求。 有多种配置方法来禁用交换. 一种方法是通过mlockall(Unix)或虚拟锁(Windows)请求JVM将堆锁定在内存中， 这可以设置bootstrap.memory_lock来完成. 但有时会出现虽然向Elasticsearch传递了该设置，但Elasticsearch仍然无法锁定堆的情况(例如，elasticsearch用户没有memlock unlimited)。
内存锁定检查会验证是否启用了bootstrap.memory_lock设置，以便JVM能成功锁定堆。 要通过内存锁定检查，你必须配置mlockall.
最大线程数检查
Elasticsearch通过将请求拆分为多个阶段，并将这些阶段交给不同的thread pool executors来执行请求. 针对Elasticsearch中的各种任务，Elasticsearch提供了不同thread pool executors. 因此，Elasticsearch需具备创建大量线程的能力. 最大线程数检查可确保Elasticsearch进程在正常使用情况下有权创建足够的线程. 此检查仅在Linux上强制执行.如果你使用的是Linux系统，要通过最大线程数检查，则必须配置系统，以允许Elasticsearch进程有足够能力创建至少2048个线程. 这可以修改/etc/security/limits.conf中的nproc设置来完成（请注意，可能还必须增加root用户的限制）。
最大虚拟内存检查
Elasticsearch和Lucene使用mmap来将索引的某些部分映射到Elasticsearch地址空间.这样可将某些索引数据从JVM堆中移除，但仍能通过内存快速访问. 为保证有效，Elasticsearch应该具有无限的地址空间. 最大大小的虚拟内存检查会强制Elasticsearch进程具有无限地址空间(仅在Linux系统上强制检查)。 要通过最大大小的虚拟内存检查，必须配置系统以允许Elasticsearch进程具有无限的地址空间。 这可以通过在/etc/security/limits.conf中将as(address space limit)设置为unlimited来完成(请注意，您可能还必须增加root用户的限制）.
最大文件大小检查
作为各个分片组成部分的分段文件和作为translog组成部分的translog可以增长得很大(超过几个G）。在文件最大大小有限的系统上，这可能会导致ES写入失败。因此，最安全的策略是让文件具有无限大小，这也是最大文件大小引导检查所要检查的内容。要通过最大文件检查，你必须配置你的系统，以便Elasticsearch进程有足够的能力来写入无限大小的文件.这可以通过在/etc/security/limits.conf中将fsize设为unlimited来完成(请注意，您可能还必须增加root用户的限制）。
最大映射计数检查
紧接上面的最大虚拟内存检查，为了能效地使用mmap，Elasticsearch还必须具备创建许多内存映射(memory-mapped)区域的能力. 最大映射计数检查会检查内核是否允许进程至少具有262,144个内存映射区域(仅在Linux系统上强制检查).
要通过最大映射计数检查，你必须通过sysctl来配置vm.max_map_count，且值必须大于等于262144.
客户端JVM检查
派生于OpenJDK的JVM提供了两种不同JVM:client JVM 和server JVM. 这些JVM会使用不同的编译器来将Java字节码生成可执行机器码. client JVM针对启动时和内存足迹做了调整，而server JVM则针对最大性能做了调整。这两个VM之间的性能可能会差异很大. client JVM检查可确保Elasticsearch未运行在client JVM中.要通过client JVM检查，你必须使用server VM来启动Elasticsearch.
在现代系统和操作系统上，server VM是默认设置。 此外，默认情况下Elasticsearch配置会强制使用server VM。
串行收集器检查
针对不同工作负载，派生于OpenJDK的JVM提供了多种垃圾回收器.尤其是串行收集器(serial collector)，它只适合单逻辑CPU机器或非常小的堆，不适合运行Elasticsearch。
在Elasticsearch中使用串行收集器会对性能造成破坏性影响。串行收集器检查可确保Elasticsearch未配置为与串行收集器一起运行。要通过串行收集器检查，你不能以串行收集器来启动Elasticsearach(无论是使用JVM的默认值还是使用-XX:+UseSerialGC明确指定都不行).
请注意，Elasticsearch附带的默认JVM配置会让Elasticsearch使用CMS收集器。
系统调用过滤器检查
Elasticsearch会针对不同操作系统安装各种风格的系统调用过滤器(例如Linux上的seccomp）。
安装系统调用过滤器是为了阻止那些执行与forking相关的系统调用 ，从而阻止对Elasticsearch代码的攻击。系统调用过滤器检查能确保在启用了系统调用过滤器的情况下能成功进行安装. 要通过系统调用过滤器检查，您必须修复系统上的配置错误(即：无法安装系统调用过滤器的配置错误，可检查日志来确认错误原因），或者通过将bootstrap.system_call_filter设置为false来禁用系统调用过滤器。
OnError和OnOutOfMemoryError检查
如果JVM遇到致命错误（OnError）或OutOfMemoryError（OnOutOfMemoryError），则可以使用JVM选项OnError和OnOutOfMemoryError执行任意命令。但是，默认情况下，启用ElasticSearch系统调用过滤器（seccomp），这些过滤器会阻止forking。因此，使用OnError或OnOutOfMemoryError和系统调用过滤器是不兼容的。如果使用这些JVM选项中的任何一个并启用了系统调用过滤器，则OnError和OnOutOfMemoryError检查会阻止Elasticsearch启动。该检查是强制执行的。要通过此检查，请不要启用OnError也不要启用OnOutOfMemoryError; 相反，可升级到Java 8u92，并使用JVM标志ExitOnOutOfMemoryError.虽然它不包含OnError和OnOutOfMemoryError的全部功能，但启用seccomp时将不支持任意forking。
Early-access检查
OpenJDK项目提供即将发布的early-access快照版本，但这些版本不适合生产。early-access检查会检测这些early-access快照。 要通过此检查，您必须在JVM的发布版本上启动Elasticsearch。
G1GC检查
JDK 8 早期附带的HotSpot JVM会在启用G1GC收集器时破坏索引.JDK 8u40之前的版本会引发这类问题。 G1GC检查会检查这些HotSpot JVM早期版本。