配置elasticsearch(Setup Elasticsearch)
这一章节包含了如何运行和配置elasticsearch的相关信息，包含如下内容：
下载
安装
启动
配置
支持的平台（Supported platforms）
目前支持的操作系统和JVMS对照表可以点击这里查看。elasticsearch会在这些平台进行测试，当然也可能可以在其它没有测试的平台上运行。
java（JVM）Version
elasticsearch是用java构建的，最低需要java8的环境，只支持使用oracle 的java和openJDK。所有的elasticsearch节点和客户端都应该使用相同的JVM版本。
我们推荐安装1.8.0_73或更高的java版本。如果使用不合适的版本，elasticsearch将启动不了。
elasticsearch使用的java版本可以通过JAVA_HOME环境变量配置.
elasticsearch 的默认运行在64位服务端 JVMs。如果你使用32位的客户端JVM，你必须移除jvm.options的
-server选项。如果你正在使用32位的JVM，你需要把进程栈的大小 从-Xss1m调整到-Xss320k。
安装elasticsearch（Installing Elasticsearch）
elasticsearch提供如下的安装包：
zip/tar.gz
zip和tar.gz安装包适合所有的操作系统，也是最简单的一种安装方法。
Install Elasticsearch with .zip or .tar.gz or Install Elasticsearch on Windows
deb
deb 安装包适合Debian，Ubuntu，和其他基于Debian的操作系统。可以从elasticsearch的官网或Debian仓库下载安装包。
Install Elasticsearch with Debian Package
rpm
rpm 安装包适合Red Hat ，Centos，SLES，OPENSuSE和其他基于RPM的系统。RPM安装包可以从elasticsearch官网或者RPM仓库下载
Install Elasticsearch with RPM
docker elasticsearch提供了可以安装在Docker的镜像 ，并且可以在Docker容器中运行。它预先安装了X-Pack ,可以从elastic Docker 仓库下载
Install Elasticsearch with Docker
配置管理工具（Configuration Management Tools）
我们提供了如下的配置管理工具去协助开发。
Puppet
Chef
使用.zip或.tar.gz安装elasticsearch（Install Elasticsearch with .zip or .tar.gz）
elasticsearch 提供了 zip和.tar.gz 安装包，适用于所有的系统，也是安装elasticsearch最简单的一种办法。
最新的稳定版本可以在Download Elasticsearch下载。其他版本可以在 Past Releases page下载。
Elasticsearch要求java8以上的环境。可使用官方的 Oracle distribution 或者开源的distribution：OpenJDK.
下载并安装.zip包（Download and install the .zip package）
elasticsearch v5.0.2 的.zip文档可以用下面的命令下载并安装：
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-5.0.2.zip sha1sum elasticsearch-5.0.2.zip unzip elasticsearch-5.0.2.zip cd elasticsearch-5.0.2/
下载完成后，需要用
sha1sum或者shasum命令生成摘要并和官方发布的SHA对比,防止文件被篡改。es 的家目录是
elasticsearch-5.0.2，下面用$ES_HOME去代替它
下载并安装.tar.gz包（Download and install the .tar.gz package）
elasticsearch v5.0.2 的.tar.gz文档可以用下面的命令下载并安装
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-5.0.2.tar.gz sha1sum elasticsearch-5.0.2.tar.gz tar -xzf elasticsearch-5.0.2.tar.gz cd elasticsearch-5.0.2/
下载完成后，需要用
sha1sum或者shasum命令生成摘要并和官方发布的SHA对比,防止文件被篡改。es 的家目录是
elasticsearch-5.0.2，下面用$ES_HOME去代替它
在命令行中运行elasticsearch(Running Elasticsearch from the command line)
elasticsearch可以用下面的命令启动：
./bin/elasticsearch
elasticsearch默认在前景运行，并且会打印log到stdout 。可以按下 Ctrl-C停止运行。
索引打包到es的scirpt都依赖一个支持数组的bash，并且认为bash程序在/bin/bash。
检查es是否在运行（Checking that Elasticsearch is running）
你可以通过发送一个http请求到localhost:9200，检测elasticsearch是否在运行：
GET / COPY AS CURL=curl -XGET 'localhost:9200/?pretty' VIEW IN CONSOLE= http://localhost:5601/app/kibana#/dev_tools/console?load_from=https://www.elastic.co/guide/en/elasticsearch/reference/current/snippets/zip-targz/1.json
接口应该会返回类似下面的内容：
{
"name" : "Cp8oag6",
"cluster_name" : "elasticsearch",
"cluster_uuid" : "AT69_T_DTp-1qgIJlatQqA",
"version" : {
"number" : "5.0.2",
"build_hash" : "f27399d",
"build_date" : "2016-03-30T09:51:41.449Z",
"build_snapshot" : false,
"lucene_version" : "6.2.1"
},
"tagline" : "You Know, for Search"
}可以在命令行使用-q或--quiet选项，禁止打印日志到stdout
作为守护进程运行（Running as a daemon）
在命令行中指定 -d选项可以使elasticsearch以守护进程的形式运行，指定-p选项可以记录当前进程id到文件中：
./bin/elasticsearch -d -p pid
可以在$ES_HOME/logs目录查看日志。
可以通过执行 kill pid （上面步骤记录在文件中的pid）命令关闭elasticsearch
kill `cat pid`
RPM和Debian安装包提供了 启动脚步去管理elasticsearch进程的启动和停止。
在命令行中配置elasticsearch（Configuring Elasticsearch on the command line）
elasticsearch 默认加载 $ES_HOME/config/elasticsearch.yml 配置文件。在 Configuring Elasticsearch章节会解析这个配置文件格式。
任何设置都可以在配置文件中指定，也可以在命令行中通过-E选项指定：
./bin/elasticsearch -d -Ecluster.name=my_cluster -Enode.name=node_1
通常，任何有关集群的配置（例如：cluster.name) 都应该加到 elasticsearch.yml配置文件中。任何节点的配置例如：node.name,都可以444在命令行中指定
.zip 和 .tar.gz文档的目录层次（Directory layout of .zip and .tar.gz archives）
.zip和.tar.gz安装包包含了elasticsearch全部的文件。所有文件和目录都在$ES_HOME（解压的时候就会创建这个目录）中.
这样做是非常方便的，因为你不需要创建任何目录就可以启动elasticsearch，并且卸载elasticsearch只需要简单的删除$ES_HOME目录。然而，为了防止你以后删除一些重要的数据，建议你改变配置文件，数据，和日志默认目录。
| 目录 | 描述 | 默认路径 | 对于配置文件的键 |
|---|---|---|---|
| home | elasticsearch的家目录 | 解压安装包的目录 | |
| bin | 二进制文件目录，包含启动elasticsearch和用于安装elasticsearch插件(elasticsearch-plugin)的二进制文件 | $ES_HOME/bin | |
| conf | 配置文件目录，包含elasticsearch.yml | $ES_HOME/config | path.conf |
| data | 节点中的索引和分片保存数据的位置。可以同时在多个位置保存 | $ES_HOME/data | path.data |
| logs | 日志文件路径 | $ES_HOME/logs | path.logs |
| plugins | 插件的安装位置，每个插件都会新建一个子目录 | $ES_HOME/plugins | |
| repo | Shared file system repository locations. Can hold multiple locations. A file system repository can be placed in to any subdirectory of any directory specified here. | Not configured | path.repo |
| script | 脚步文件的位置 | $ES_HOME/scripts | path.scripts |
下一步（Next steps）
现在，你已经建立了elasticsearch的测试环境。在你开始使用elasticsearch开发或者发布产品时，你需要进行以下这些配置：
使用debian包安装
使用RPM安装
在windows上安装
在Dcker中安装
配置elasticsearch（Configuring Elasticsearch）
elasticsearch本身就具备了一些比较好的默认配置，并且它只需要很少的配置。使用 Cluster Update Settings API可以动态的修改运行中的elasticsearch配置。
配置文件应该包含特定的节点选项（例如 node.name 和路径），或者用于把节点加入集群的选项（例如，cluster.name 和network.host）。
配置文件位置（Config file location）
elasticsearch有两个配置文件：
elasticsearch=.yml用于配置elasticsearchlog4j2.properties用于配置elasticsearch的日志。
这些文件位于config目录，目录的默认位置是$ES_HOME/config/。通过Debian和RPM安装的配置文件的目录是 /etc/elasticsearch/。
可通过以下的命令修改配置文件的位置：
./bin/elasticsearch -Epath.conf=/path/to/my/config/
配置文件的格式（Config file format）
配置文件使用的格式是YAML。下面例子修改了数据和日志目录：
path: data: /var/lib/elasticsearch logs: /var/log/elasticsearch
配置也可以使用平面化的方式：
path.data: /var/lib/elasticsearch path.logs: /var/log/elasticsearch
环境变量替换（Environment variable subsitution）
在配置文件中，可以通过 ${...} 符号引用环境变量,例如：
node.name: ${HOSTNAME}
network.host: ${ES_NETWORK_HOST}提示输入配置（Prompting for settings）
如果你不想把配置写到配置文件中，你可以在配置的值中输入${prompt.text}或 ${prompt.secret}符号，并且以前景的方式运行elasticsearch。${prompt.secret}不会把你输入的内容显示到终端上（相当于输入密码时的***功能吧），${prompt.text}可以让你在终端上看到你输入的内容，例如：
node:
name: ${prompt.text}当启动elasticsearch的时候，终端会提示你输入配置值：
Enter value for [node.name]:
注意，如果elasticsearch的配置文件使用
${prompt.text}或${prompt.secret}作为配置值并且以后台的形式运行，那么它将启动失败。
设置默认配置（Setting default settings）
可以在命令行中使用default.前缀指定新的默认值。当配置文件没有指定该值的时候就会使用默认值。
例如，如果elasticsearch用以下命令运行：
./bin/elasticsearch -Edefault.node.name=My_Node
如果没有在命令行重写es.node.name或在配置文件中重写node.name，node.name的值将会是My_Node。
日志配置（Logging configuration）
elasticsearch 使用 log4j2来记录日志。日志的配置文件是log4j2.properties。elastisearch 暴露了${sys:es.logs}属性,Log4j 2可以在配置文件引用它动态指定日志文件的位置。在运行的时候，${sys:es.logs}将会被替换成以当前集群名称作为前缀的路径。
例如，如果你的日志目录(path.log)是/var/log/elasticsearch并且 你的集群名字是prodution，那么${sys:es.logs}将会被替换成/var/log/elasticsearch/production。
appender.rolling.type = RollingFile【1】
appender.rolling.name = rolling
appender.rolling.fileName = ${sys:es.logs}.log 【2】
appender.rolling.layout.type = PatternLayout
appender.rolling.layout.pattern = [%d{ISO8601}][%-5p][%-25c] %.10000m%n
appender.rolling.filePattern = ${sys:es.logs}-%d{yyyy-MM-dd}.log【3】
appender.rolling.policies.type = Policies
appender.rolling.policies.time.type = TimeBasedTriggeringPolicy 【4】
appender.rolling.policies.time.interval = 1 【5】
appender.rolling.policies.time.modulate = true 【6】使用
RollingFile文本追加器来保存日志把日志写到
/var/log/elasticsearch/production.log设置日志命名规则
/var/log/elasticsearch/production-yyyy-MM-dd.log使用基于时间的轮换策略
每天轮换一次日志文件
日志轮换是以天作为分界（而不是相隔24小时）
如果在appender.rolling.filePattern中追加.gz或者.zip后缀，那么当日志轮换的时候，旧的日志将会被压缩处理。
可以在elasticsearch的config的不同子目录下使用多个名字是log4j2.properties 的配置文件（加载配置文件的时候会进行合并处理）。这样做可以让插件自定义日志。日志部分包含java包和相应的日志级别。appender部分包含日志的储存位置。在Log4j documentation可以找到关于如何自定义日志和其他appenders的相关信息。
弃用日志（Deprecation logging）
除了常规的日志，elasticsearch允许你记录弃用的特性。也就是说由于elasticsearch的升级，有些旧的特性可能会被弃用，当你的配置文件使用到这些弃用的特性时，就会写日志到弃用日志文件，好让你了解elasticsearch做了哪些改动。 这让你更早地确定你将来是否需要迁移某些功能（因为过期的特性不会马上被移除，但未来还是会移除，你可以在未移除之前，使用新的方案代替被移除的特性）。默认地，弃用日志记录对 WARN 级别开启，在这个级别的所有弃用日志消息都会被输出到弃用日志中。
logger.deprecation.level = warn
使用这个配置将会创建一个轮转策略的弃用日志文件到你的日志目录。你需要定期检查这个文件，特别是在准备更新一个大版本的时候。
默认使用轮换日志保存策略，日志大于1GB后被压缩，最多创建5个日志文件（4个轮换日志，一个在用的日志）。
你可以通过以下命令禁用弃用日志：
logger.deprecation.level = error
重要的elasticsearch配置（Important Elasticsearch configuration）
虽然elasticsearch仅需非常少的配置，但是还是需要手动配置一部分配置，并且在程序上线之前要明确配置好这些值：
path.dataandpath.logscluster.namenode.namebootstrap.memory_locknetwork.hostdiscovery.zen.ping.unicast.hostsdiscovery.zen.minimum_master_nodes
path.data 和 path.logs（path.data and path.logs）
如果你使用.zip或者.tar.gz文档安装，数据和日志存放的目录将会是 $ES_HOME 目录下的data和logs目录。如果这些重要的数据保存到默认的路径，那么当elasticsearch升级的时候就会误删这些数据，这是相当危险的。
在生成环境中，你应该改变日志和数据的存放路径：
path: logs: /var/log/elasticsearch data: /var/data/elasticsearch
RPM和Debian的安装包已经使用了自定义的data和logs路径。
path.data 选项可以同时指定多个路径，所有的路径都会被用来存储数据（但所有属于同一个分片的文件，都会全部保存到同一个数据路径）
path: data: - /mnt/elasticsearch_1 - /mnt/elasticsearch_2 - /mnt/elasticsearch_3
cluster.name
节点仅仅可以同时加入一个集群，默认的集群名是elasticsearch，但你应该使用一个合适的名字描述集群：
cluster.name: logging-prod
确保你不要在不同的开发环境中使用相同的集群名，否则你最终有可能加入错误的集群。
node.name
elastisearch 默认会随机生成7个字母开头的的uuid作为节点id。注意节点id是持久的，即使服务器重启，我们也不需要再次指定或者改变它，同理，节点名称也不需要改变。
推荐指定一个有意义的名字：
node.name: prod-data-2
你也可以使用主机名作为节点名字：
node.name: ${HOSTNAME}bootstrap.memory_lock
禁止JVM从内存切换到硬盘交换空间，对你节点健康极其重要。一种方法是把bootstrap.memory_lock设置为true。
为了使这个配置生效，需要先设置系统级别的配置。查询Enable bootstrap.memory_lock获取更多关于如何正确设置内存锁定的信息。
network.host
elasticsearch默认绑定到环回地址（即，127.0.0.1 和[::1]）。对于只需要在单台服务器运行一个节点的情况已经十分足够了。
事实上，可以使用bin/elasticsearch命令在同一台服务器上启动多个节点。这对测试elastisearch是很方便的。但是在上线环境中不推荐这样做。
为了能和同一个集群中但不在同一个服务器的节点通讯，你的节点需要绑定到非回环地址。虽然这里有很多网络相关的配置，但通常你只需要配置一下network.host
network.host: 192.168.1.10
这个配置也可以使用值_local_,_size_,_global_和修饰器:ip4,:ip6。点击 netword.host的特殊值 获取更详细的信息。
一旦你自定义了network.host的值，elasticsearch就会认为你正在从开发环境切换到线上环境，并且开启一系列的系统功能，用于检测错误和异常。查阅“开发模式 vs 线上模式”章节获取更多信息。
discovery.zen.ping.unicast.hosts（集群所有节点地址）
Elasticsearch不需要任何的网络配置就可以绑定到回环地址和扫描，扫描并尝试连接运行在同一服务器的端口从9300到9305的其他节点。不需要任何配置就可以自动集群。
如果想和其他服务器的节点形成一个集群，你必须提供集群中其它节点的列表。可以通过以下方式指定：
discovery.zen.ping.unicast.hosts:
192.168.1.10:9300
192.168.1.11 【1】
seeds.mydomain.com 【2】
如果没有指定端口，默认使用9300
如果输入的是主机名被解析成多个地址，节点将会尝试连接所有地址（同时只选一个可用的）。
discovery.zen.minimum_master_nodes
为了防止过多的数据丢失，配置discovery.zen.minimum_master_nodes极为重要，因为必须要集群中的每一个候选节点（有可能成为主节点的节点）知道集群的最少候选主节点数是多少，才可以正确的形成集群。
如果没有这个配置，当集群遇到网络错误时，就有可能分离成两个独立的集群（脑裂现象）。这样会导致集群丢失一些节点，从而丢失一部分数据（因为即使后面网络好了，但是已经分成两个集群，分离的节点不会再组成一个集群了）。查阅“避免脑裂章节”获取更多详细信息
为了避免脑裂现象，需要设置master候选节点的数量：
(master_eligible_nodes / 2) + 1
换句话说，如果现在有3个节点，最小候选节点数应该是（3/2)+1=2:
discovery.zen.minimum_master_nodes: 2
引导检查（Bootstrap Checks）
总的来说，曾经有用户因为没有配置 重要的配置，而引起很多意想不到的问题。对于以前的版本，配置错误将会产生一条warning日志。用户有时候没有注意到这些日志也是挺正常的。为了确保用户发现这些错误，elassticsearch在启动之前就会检查配置。
引导程序会检查elasticsearch本身和系统的配置，查看它们的值对elasticsearch的操作是否安全。如果elasticsearch以开发模式运行，每一个配置错误都会产生一条警告日志。如果以线上模式运行，配置错误将会阻止elasticsearch启动。
有一些配置错误总是会导致elasticsearch启动不了，这些情况已经被单独记录下来。
开发模式vs线上模式（Development vs. production mode）
Elasticsearch默认绑定localhost用于HTTP（用于外部通讯）和集群内部通讯（transport，内部通讯模块）。localhost对开发环境是挺合适的(因为经常多个节点运行在一台机器上)，但不能用于线上环境（节点运行在不同的机器上，需要外部地址才能互相通讯）。为了能形成一个集群，每一个节点都必须能够通过内部通讯模块访问其他节点，所以elasticsearch必须绑定到外部地址。因此我们认为：如果内部通讯模块（transport）绑定的地址不是外部地址（默认），elastisearch处于开发环境，否则处于线上环境。注意，HTTP和内部通讯模块可以分别通过http.host和transport.host绑定各自的地址。这样的好处是，不用切换到线上环境（即 内部通讯模块可以绑定localhost，HTTP模块绑定外部地址）也可以通过http请求测试开发环境的数据。
堆大小检查（Heap size check）
如果JVM启动时的堆大小和最大堆大小不一致，很用可能在系统使用期间因为需要调整堆大小而暂停运行一段时间（当堆的内存不够时就会尝试调整）。为了避免因调整堆大小造成JVM暂停运行，最好就在启动JVM的时候的堆大小设置成最大的堆大小（有可能浪费不必要的内存,因为jvm一开始就占用了最大值的内存，不管用不用到，导致其他程序就不用用这些内存了）。此外，如果boostrap.memory_lock设置为true，JVM的堆大小将会在启动时被锁定（不会进行磁盘交换），如果初始堆大小和最大堆大小不等，那么在调整堆大小后，JVM的堆将不能锁定在内存。为了通过堆大小检测，你必须要配置堆大小。
文件描述符检查（File descriptor check）
文件描述符是unix为了跟踪已打开的文件而创建的索引。在unix中，所有东西都是文件。例如，文件可以是物理文件，可以是虚拟文件（即/proc/loadavg）,也可以是网络sockets。elasticsearch需要大量的文件描述符（即，每个分片都是由多个片段和其他文件组成，再加上和其他节点的连接等等）。在OS X和linux系统中是强制进行文件描述符引导检查的。为了通过文件描述检查，你必须配置文件描述符。
内存锁定检查（Memory lock check）
当JVM进行一次主要的垃圾回收时，会遍历堆中的每一页。如果发现有被置换到硬盘的页时就会重新把它放回内存中。这将会引起大量的磁盘抖动，因为elasticsearch正使用它来处理请求。有几种方法可以禁用磁盘交换。一种是通过mlockall（Unix）或者虚拟锁（Windows）要求JVM把堆锁定在内存中，通过配置bootstrap.memory_lock可以实现这个功能。然而，有可能elasticsearch设置了内存锁定，但是实际并没有锁定。（即，如果elasticsearch 用户没有 memlock ulimited的权限）。如果elasticsearch启动了bootstrap.memory_lock，并且JVM成功锁住了堆，即认为内存锁定检查通过。为了通过内存锁定检查，你必须要配置mlockall.
最大线程数量检查（Maximum number of threads check）
elasticsearch 把请求分成多个阶段执行，每个阶段都由不同的线程池执行者处理。elasticsearch用不同的线程池执行者处理各种各样的任务。因此elasticsearch需要创建大量的线程。检查线程的最大数量确保elasticsearch进程有权力去创建足够的线程。在linux是强制进行这项检查的。如果你正好使用linux，为了通过最大线程数的检查，你必须让你的系统允许elasticsearch启动至少2048个线程。可以通过/etc/security/limits.conf 文件的nproc选项配置（注意，你必须使用root用户来增加线程数限制）。
最大虚拟内存检查（Maximum size virtual memory check）
elasticsearch 和 Luence 使用 mmap（内存文件映射）把索引的一部分映射到Elasticsearch进程的地址空间。这样保持某些索引数据在内存中，达到快速访问的效果。为了达到这一效果，elasticsearch需要无限的地址空间。最大虚拟内存检查强制elasticsearch必须要有无限的地址空间，并且在linux系统是强制检查这个选项的。为了通过最大虚拟内存检查，你必须配置你系统让elasticsearch有权力拥有无限的地址空间。可以把 /etc/security/limits.conf文件的as选项改为无限达到以上目的（注意，必须使用root用户修改这个选项）。
最大内存映射地址数检查（Maximum map count check）
继续上一章节，为了更有效地使用 mmap，elasticsearch需要有权限创建大量的内存映射地址。最大内存映射地址数量检查内核是否允许进程创建至少262144个内存映射地址，仅在linux上强制要求检查这个选项。为了通过最大内存映射地址检查，你必须要通过sysctl配置vm.max_map_count的值至少262144。
客户端JVM检查（Client JVM check）
OpenJDK提供了两种不同的JVM，客户端JVM和服务器端JVM。它们使用不同的编译器把java字节码转换成可执行的机器码。客户端JVM具有启动快，占用内存少的好处，服务端JVM启动慢，但是执行性能好。两种JVM的性能还是有本质区别的。客户端JVM检查确保elasticsearch不是运行在客户端JVM上。为了通过这项检查，你必须要用服务端JVM来启动elasticsearch，并且这是默认的行为。此外，elasticsearch被配置为强制使用服务端JVM。
序列收集器检查（Use serial collector check）
OpenJDK JVM 提供了多种垃圾收集器处理，各个收集器消耗的系统资源都不一样。其中的序列收集器最适合用在单个逻辑CPU或性能比较差的机器上，但不适合用在elasticsearch。使用序列垃圾收集器会降低elasticsearch的性能。序列收集器检查确保elasticsearch没有使用序列垃圾收集器。为了通过这项检查，你必须不使用序列垃圾收集器（不管是JVM默认指定，还是你自己通过-XX:+UseSerialGC指定）。注意，elasticsearch默认使用CMS收集器。
OnError 和 OnOutOfMemoryError 检查
JVM 的OnError和OnOutOfMemoryError选项允许在其发生致命错误（OnError）或 OnOutOfMemoryError（OnOutOfMemoryError）时执行任意的的命令。然而，elasticsearch 默认开启系统调用过滤（seccomp)，这些过滤将会阻止fork系统调用。因此使用OnError和OnOutOfMemoryError选项和系统调用过滤是冲突的，发生冲突时将会阻止elasticsearch启动。为了通过这项检查，你不能开启OnError和OnOutOfMemoryError选项，或者升级到 Java 8u92 并使用JVM标记ExitOnOutOfMemoryError。
基于 Seccomp 的系统调用过滤 Seccomp （即“"secure computing”的别名）是 2.6.12 版本重新加入的简 单沙盒机制， 用来确保系统调用处于受限状态 （仅允许对已打开的文件进行 exit, sigreturn, read 和 write 操作） 。Seccomp 现在又增加了新功能：不再是有限 并且确定的系统调用，Seccomp 现在已经成了一种过滤机制，用来管理一个系统 调用是否被禁止（和 Berkeley Packet Filter 功能类似)。
G1GC check
大家都知道jdk8附带的早期的HotSpot JVM 版本存在一个问题：如果开启了G1GC收集器，会导致索引出错。受影响的版本是JDK 8u40以前的版本。G1GC 检查是否使用了早期的HotSpot JVM。
重要的系统配置（Important System Configuration）
理想情况下，elasticsearch应该单独运行在一台服务器上，并使用所有对它有用的服务器资源。为了达到这个目的，你必须配置你的操作系统允许用户运行elasticsearch并访问比默认配置更多的资源。在发布到生产环境之前，不需要配置好下面的选项：
开发模式Vs生产模式(Development mode vs production mode)
默认，elasticsearch认为你处于开发模式中。如果上述的任何一个选项没有正确配置，都会产生一条警告日志，但你依然可以启动和运行你的elasticsearch节点。
一旦你配置网络选项：network.host ，elasticsearch就会认为你要切换到生产模式了，并把wanning提升为异常级别。这些异常会阻止你的elasticsearch节点启动。这是确保你不会因为配置错误而丢失数据的重要的安全措施。
配置系统选项(Configuring system settings)
系统选项的位置基于你安装elasticsearch时使用的安装包类型以及你使用的操作系统类型。
当使用.zip和.tar.gz安装包时，系统选项可以这样配置：
使用
ulimit进行临时配置使用
/etc/security/limits.conf进行永久配置
当使用RPM或者Debian安装包时，大部分系统选项都在system configuration file 。然而，使用systemd要求在systemd configuration file指定system limits。
ulimit 在linux系统，ulimit可以临时地改变系统资源限制。只有root用户才可以使用这个命令。例如可以通过如下命令，设置打开文件的最大数量
sudo su【1】 ulimit -n 65536 【2】 su elasticsearch 【3】
切换到root
改变打开文件的最大数量
切换回启动elasticsearch的用户
新的限制值仅仅在当前会话生效，你可以添加 -a 选项使当前所有的应用都生效。
/etc/security/limits.conf 在linux系统，可以编辑/etc/security/limits.conf是选项永久生效。在文件中加入如下代码设置elasticsearch的最大打开文件数：
elasticsearch - nofile 65536
这个改变在下次启动elasticsearch才会生效。
Ubuntu 的进程通过
init.d启动，会忽略limits.conf文件。为了使其生效，请编辑/etc/pam.d/su并注释下面那段代码：# session required pam_limits.so
系统选项文件（Sysconfig file）
当使用RPM或Debian安装包时，系统选项和环境变量可以在系统配置文件中指定，它们位于：
RPM
/etc/sysconfig/elasticsearch
Debian
/etc/default/elasticsearch
然而，对于使用systemd的系统，系统限制选项需要通过systemd指定。
systemd配置（Systemd configuration）
当在使用systemd指令的操作系统中，使用RPM或Debian安装包安装es，limit选项必须通过systemd指定。
系统服务文件（/usr/lib/systemd/system/elasticsearch.service）包含一些默认的limit配置。
可以添加这样的一个文件（/etc/systemd/system/elasticsearch.service.d/elasticsearch.conf）并编辑文件来覆盖默认配置：
[Service] LimitMEMLOCK=infinity
设置JVM选项（Setting JVM options）
配置java虚拟机选项首选的方法是修改jvm.options文件。如果通过.tar.gz或.zip包安装，文件位置是config/jvm.options，如果通过Debian或RPM，文件位置是/etc/elasticsearch/jvm.options。java每行一个选项，必须以“-”作为开头。你可以自定你的java参数，并把其加入你的版本控制系统。
另一个设置JVM选项的方法是通过修改ES_JAVA_OPTS环境变量。例如：
export ES_JAVA_OPTS="$ES_JAVA_OPTS -Djava.io.tmpdir=/path/to/temp/dir" ./bin/elasticsearch
当使用RPM 或者Debian包，可以在system configuration file指定环境变量ES_JAVA_OPTS
使用jvm.options设置jvm 堆大小（Set JVM heap size via jvm.options）
elasticsearch默认设置JVM堆大小的最少值和最大值都是2GB。当你切换到生产环境时，确保elasticsearch有足够的堆内存十分重要。
elasticsearch 在jvm.options 通过 Xms (minimum heap size) 和 Xmx (maximum heap size) 指定堆大小。
这两个值的设置基于你的可用内存大小，比较好的设置规则是：
设置最小堆大小和最大堆大小相等
elastic可用堆大小越大，就可以缓存越多的内容。但堆太多会导致垃圾回收引起的JVM暂停时间较长。
设置Xmx不要超过你内存的50%，以确保有足够的物理内存留给内核的文件系统缓存。
不要设置Xmx超过启用java压缩对象指针功能的最大阈值（compressed oops，因为64位的地址会比32位的多消耗1.5倍内存，压缩后可以节省内存，超过阈值就不会启用压缩了）。这个阈值有差异性，但接近32GB。你可以通过查看以下日志验证JVM是否启用了对象指针压缩。
heap size [1.9gb], compressed ordinary object pointers [true]为了更好，你可以尽量把Xmx设置在启用零基对象指针压缩（ zero-based compressed oops，一个优化的普通对象指针压缩的方案）的阈值之下。这个阈值有差异性，但在大多数系统是26GB，某些系统可以达到30GB。你可以通过设置JVM 选项
-XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode,并在启动elasticsearch的时候查看下面的信息，去验证是否启用了零基压缩方案：heap address: 0x000000011be00000, size: 27648 MB, zero based Compressed Oops或者heap address: 0x0000000118400000, size: 28672 MB, Compressed Oops with base 0x00000001183ff000。
下面举个设置堆大小的例子：
-Xms2g【1】 -Xmx2g 【2】
1.设置最少堆大小是2GB 2.设置最大堆大小是2GB
你也可以通过环境变量去设置：
ES_JAVA_OPTS="-Xms2g -Xmx2g" ./bin/elasticsearch ES_JAVA_OPTS="-Xms4000m -Xmx4000m" ./bin/elasticsearch
禁用磁盘交换（Disable swapping）
大多数的操作系统把尽可能多的内存用作文件系统缓存并且会把那些应用程序没用到的内存交换到磁盘中。开启磁盘交换将会导致elasticsearch的部分JVM堆交换到磁盘中。
磁盘交换会严重影响节点的性能和稳定。它会引起垃圾回收并消耗分钟级别而不是毫秒级的时间，有可能导致节点响应缓慢或者断开与集群的连接。
下面有几种方法禁用磁盘交换：
启用 bootstrap.memory_lock（Enable bootstrap.memory_lock）
在linux/UNIX系统的首选方法是使用mlockall，在windows系统使用 VirtualLock，这个操作会尝试把进程地址空间限定在内存中，并阻止elasticsearch的内存交换到磁盘。可以通过修改 config/elasticsearch.yml文件完成以上操作：
bootstrap.memory_lock: true
如果mlcokall的内存大于可用的内存，有可能会导致JVM或者Shell 会话退出。
启动elasticsearch之后，你就可以通过如下方法检验这个设置是否生效：
GET _nodes?filter_path=**.mlockall COPY AS CURL=curl -XGET 'localhost:9200/_nodes?filter_path=**.mlockall&pretty' VIEW IN CONSOLE=http://localhost:5601/app/kibana#/dev_tools/console?load_from=https://www.elastic.co/guide/en/elasticsearch/reference/current/snippets/setup-configuration-memory/1.json
如果你看到mlockall 的值是false，就意味着没生效。你会在日志中看到包含Unable to lock JVM Memory的详细信息。
造成锁定内存失败的重要原因是运行elasticsearch的用户没有足够的权限锁定内存。可以通过以下方式授权：
.zip和 .tar.gz
在启动elasticsearch之前用root用户执行 ulimit -l unlimited 或者把/etc/security/limits.conf 文件的memlock选项设置为unlimited
RPM 和 Debian
把system configuration file文件的 MAX_LOCKED_MEMORY选项 (https://www.elastic.co/guide/en/elasticsearch/reference/current/setting-system-settings.html#sysconfig)设置为 unlimited （或使用systemd）
使用 systemd的系统
在 systemd configuration 中把LimitMEMLOCK选项设置为infinity
mlockall操作失败的另一个原因是挂载的临时目录（通常是 /tmp）的时候使用了 noexec选项。可以使用ES_JAVA_OPTS 环境变量指定一个新的临时目录解决上述问题：
export ES_JAVA_OPTS="$ES_JAVA_OPTS -Djava.io.tmpdir=/path/to/temp/dir" ./bin/elasticsearch
或者在jvm.options配置文件中设置JVM标记
禁用所有交换文件（Disable all swap files）
第二种方案是完全的禁用磁盘交换。elasticsearch通常运行在一个盒子中，并且通过JVM选项管理它的内存使用，不再需要启动磁盘交换。
在linux系统，你可以运行sudo swapoff -a临时禁用磁盘交换。为了永久禁用，你需要编辑/etc/fstab 文件，并且注释所有包含swap的选项。
配置 swappiness（Configure swappiness）
对于linux系统，第二种有效的方法是把 sysctl vm.swappiness 选项的值设置为1。这将会减少内核执行磁盘交换的频率，也就是说在正常情况下不会执行交换，在紧急情况下才会执行交换。
文件描述符（File Descriptors）
这仅仅与Linux或macOS相关。
elasticsearch 使用大量的文件描述符。当文件描述符不足的时候会导致灾难性的后果，很有可能会丢失数据。确保把文件描述符的限制提高到65536以上。
对于.zip和.tar.gz 包，在elasticsearch启动之前用root设置ulimit -n 65536，或者把/etc/security/limits.conf文件的nofile选项设置为65536。
RPM和Debian已经设置文件描述符的默认大小是65536，不再需要手动配置了。
你可以使用Nodes Stats API(GET _nodes/stats/process?filter_path=**.max_file_descriptors)检查所有节点的 max_file_descriptors值
GET _nodes/stats/process?filter_path=**.max_file_descriptors COPY AS CURL=curl -XGET 'localhost:9200/_nodes/stats/process?filter_path=**.max_file_descriptors&pretty' VIEW IN CONSOLE=http://localhost:5601/app/kibana#/dev_tools/console?load_from=https://www.elastic.co/guide/en/elasticsearch/reference/current/snippets/file-descriptors/1.json
虚拟内存(Virtual memory)
elasticsearch同时使用mmapfs 和niofs目录保存索引。操作系统默认的 mmap数量很多情况下都是不够的，这将会导致内存溢出异常。
对于linux，你可以运行下面的命令去增加这个值：
sysctl -w vm.max_map_count=262144
可以修改/etc/sysctl.conf中的vm.max_map_count选项使其永久生效。并在在重启系统后 执行sysctl vm.max_map_count验证是否生效。
RPM和Debian会自动配置这个选项。
线程数(Number of threads)
elasticsearch在不同的操作系统中使用大量的线程池。确保elasticsearch用户可以至少创建2048个线程十分重要。
可以在elasticsearch启动之前用root用户执行ulimit -u 2048 临时设置线程数。也可以修改/etc/security/limits.conf文件的nproc选项设置。
升级 elasticsearch（Upgrading Elasticsearch）
在你升级elasticsearch之前:
查询 breaking changes 文档
使用Elasticsearch Migration Plugin 插件检查潜在的问题。
在部署生产环境之前先测试开发环境
经常备份你的数据，除非你备份了你的数据，否则你不能回滚到更早的版本。
如果你使用了自定义插件，检查一下是否和新版本兼用。
elasticsearch通常使用滚动升级方式，这样不会中断它的服务。这一章节讲述如何通过滚动和整个集群重启的方式升级elasticsearch。
不同版本的升级方案，查阅官网。
滚动升级（Rolling upgrades）
滚动升级允许每次升级集群中的一个节点，并且保持集群一直在线。在同一个集群运行多个不同版本的es，不支持升级。以为不能把新版本的分片分配到旧版本的es。
查询这个表格去验证你当前的版本是否支持滚动升级。
执行滚动升级的步骤：
禁用分片分发
当你关闭一个节点，分发进程将会在一分钟之后把当前节点的分片分发到集群中的其他节点，这将会造成大量的io浪费。为了避免这个情况，你在关闭节点是需要执行：
PUT _cluster/settings
{
"transient": {
"cluster.routing.allocation.enable": "none"
}
}
COPY AS CURL=curl -XPUT 'localhost:9200/_cluster/settings?pretty' -d'
{
"transient": {
"cluster.routing.allocation.enable": "none"
}
}'
VIEW IN CONSOLE=http://localhost:5601/app/kibana#/dev_tools/console?load_from=https://www.elastic.co/guide/en/elasticsearch/reference/current/snippets/rolling-upgrades/1.json停用不重要的索引和执行 synced flush（可选）
你可能想在升级期间继续索引。然而，如果你临时停止不重要的索引 并执行synced-flushApi ，分片将会恢复得很快：
POST _flush/synced COPY AS CURLcurl -XPOST 'localhost:9200/_flush/synced?pretty' VIEW IN CONSOLE=http://localhost:5601/app/kibana#/dev_tools/console?load_from=https://www.elastic.co/guide/en/elasticsearch/reference/current/snippets/rolling-upgrades/2.json
flush Api是一个不稳定的操作。如果执行期间发生任何索引操作都会执行失败，有必要的话你可以执行多次，直到执行成功。
停止和升级单个节点
在升级之前，需要先关闭当前节点。
当使用zip或者tarball安装包，
config，logs，data和plugins目录都默认放在elasticsearch家目录下。推荐把这些目录放到不同的位置，防止我们在升级的时候删除原来的目录。可以通过
path.conf,path.logs,path.data选项配置debian和RPM安装包已经默认把他们放到合适的位置了。
使用Debian和RPM包升级的方案：
使用 rmp 和dpkg 安装新版本。所有的文件都会放到合适的位置，并且不会覆盖配置文件。
使用zip或tarball的升级方案：
解压zip或tarball到新目录，确保不要覆盖
config或data目录。把旧版本的配置文件复制到新版本的
config目录，或者通过使用-E选项指定配置文件的目录把旧版本
data目录的文件复制到新版本，并配置path.data
升级插件
当升级一个节点时，elasticsearch的插件也必须升级。使用
elasticsearch-plugin插件安装你需要的插件。启动节点
启动你的节点并通过日志或api确认你的节点是否加入了集群：
GET _cat/nodes COPY AS CURL=curl -XGET 'localhost:9200/_cat/nodes?pretty' VIEW IN CONSOLE=http://localhost:5601/app/kibana#/dev_tools/console?load_from=https://www.elastic.co/guide/en/elasticsearch/reference/current/snippets/rolling-upgrades/3.json
重新启动分片分发
当节点加入集群之后，重新启动分片分发：
PUT _cluster/settings { "transient": { "cluster.routing.allocation.enable": "all" } } COPY AS CURL=curl -XPUT 'localhost:9200/_cluster/settings?pretty' -d' { "transient": { "cluster.routing.allocation.enable": "all" } }' VIEW IN CONSOLE=http://localhost:5601/app/kibana#/dev_tools/console?load_from=https://www.elastic.co/guide/en/elasticsearch/reference/current/snippets/rolling-upgrades/4.json等待节点恢复
在你升级下一个节点之前，你可能需要等待集群完成分片分发操作。你可以发送_cat/health请求查看分发进度：
GET _cat/health COPY AS CURL=curl -XGET 'localhost:9200/_cat/health?pretty' VIEW IN CONSOLE=http://localhost:5601/app/kibana#/dev_tools/console?load_from=https://www.elastic.co/guide/en/elasticsearch/reference/current/snippets/rolling-upgrades/5.json
等待status字段从yellow变成green。status字段等于green意味着所有的主分片和复制分片已经成功分发好数据了。
在升级期间，新版本节点的主分片将不能分发到旧版本节点的复制分片中，因为新版本可能会有不一样的数据结构，而旧版本不能解析它。
也不能把旧版的复制分片分发到新版节点。即如果只有一个高版本的节点，复制分片依然保持未赋值状态（因为低版本的主分片不能分发到高版本作为复制分片），集群状态会是yellow。
对于这个例子，在继续之前要确保不存在初始化中或重新迁移中的分片（对应
init和relo字段）。一旦另一个节点更新完毕，复制分片将会被赋值，并且集群健康状态也会变成green。
没有执行 sync-flushed的分片会花费比较多的时间恢复。每个分片的恢复状态可以通过_cat/recoveryAPI 查看：
GET _cat/recovery COPY AS CURL=curl -XGET 'localhost:9200/_cat/recovery?pretty' VIEW IN CONSOLE=http://localhost:5601/app/kibana#/dev_tools/console?load_from=https://www.elastic.co/guide/en/elasticsearch/reference/current/snippets/rolling-upgrades/6.json
如果你在升级前停止了索引，一旦恢复完成就要重启索引功能。
重复
当当前节点恢复完毕，并且集群也稳定的时候，在其它节点重复上述步骤。
通过重启整个集群升级（Full cluster restart upgrade）
当升级一个大版本的时候，elasticsearch需要重启整个集群，并且不支持滚动升级。 查看这个表格确认是否必须要重启整个集群升级。
用重启集群的方式升级的过程如下：
禁用分片分发功能
当你关闭一个节点，分发进程会立即尝试复制当前节点的分片到集群的其他节点，并且会引起大量的io操作。在关闭节点之前通过如下API禁用分发功能：
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.enable": "none"
}
}
COPY AS CURL=curl -XPUT 'localhost:9200/_cluster/settings?pretty' -d'
{
"persistent": {
"cluster.routing.allocation.enable": "none"
}
}'
VIEW IN CONSOLE=http://localhost:5601/app/kibana#/dev_tools/console?load_from=https://www.elastic.co/guide/en/elasticsearch/reference/current/snippets/restart-upgrade/1.json执行sysced flush操作
如果你停止索引和执行 synced-flush API，分片很快就可以恢复：
POST _flush/synced COPY AS CURLcurl -XPOST 'localhost:9200/_flush/synced?pretty' VIEW IN CONSOLE=http://localhost:5601/app/kibana#/dev_tools/console?load_from=https://www.elastic.co/guide/en/elasticsearch/reference/current/snippets/rolling-upgrades/2.json
flush Api是一个不稳定的操作。如果执行期间发生任何索引操作都会执行失败，有必要的话你可以执行多次，直到执行成功。
关闭并升级所有节点
停止集群中所有的elasticsearch节点。每个节点的更新过程参考更新节点章节。
更新所有插件
当升级一个节点时，elasticsearch的插件也必须升级。使用elasticsearch-plugin 插件安装你需要的插件。
启动集群
如果你有专用的master节点，即node.master 值是true（默认）并且node.data值是false的节点，建议你先启动master节点。在处理数据节点之前，先等待他形成一个集群并被选举成主节点。你可以查看日志文件检查启动进度。
一旦已启动的节点数满足集群最少master候选节点数并且他们互相发现了对方，就会形成一个集群并选举一个主节点。从那时起，可以访问_cat/health和 _cat/nodes API 监控节点加入集群的情况：
GET _cat/health GET _cat/nodes COPY AS CURL=curl -XGET 'localhost:9200/_cat/health?pretty' curl -XGET 'localhost:9200/_cat/nodes?pretty' VIEW IN CONSOLE=http://localhost:5601/app/kibana#/dev_tools/console?load_from=https://www.elastic.co/guide/en/elasticsearch/reference/current/snippets/restart-upgrade/3.json
使用上述API检查所有节点是否都成功加入了集群。
等待集群状态变成yellow
一旦每个节点都加入了集群，那么它会恢复本地的所有主分片。在刚开始的时候，集群状态将会变成red，意味着当前主分片还没完全分发好。
一旦每个节点都恢复好本地的分片，集群状态就会yellow，意味着 所有主分片已经恢复好，但并还有复制分片没有分发好，这也是意料之中的，因为分发进程被禁用了。
启用分发
当所有的节点都加入了集群，就要开启分发，以允许master分发复制分片的数据到那些已经恢复好本地分片的节点。当所有节点都进入了集群就可以安全的重启分发功能了：
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.enable": "all"
}
}
COPY AS CURL=curl -XPUT 'localhost:9200/_cluster/settings?pretty' -d'
{
"persistent": {
"cluster.routing.allocation.enable": "all"
}
}'
VIEW IN CONSOLE =http://localhost:5601/app/kibana#/dev_tools/console?load_from=https://www.elastic.co/guide/en/elasticsearch/reference/current/snippets/restart-upgrade/4.json集群将会分发复制分片到所有数据节点。此时，就可以安全的启动索引和搜索功能，但如果你在所有分片都恢复完成之后再启动索引和搜索功能，集群将会恢复得很快
使用 _cat/health 和 _cat/recovery API 监控这个过程：
GET _cat/health GET _cat/recovery COPY AS CURL=curl -XGET 'localhost:9200/_cat/health?pretty' curl -XGET 'localhost:9200/_cat/recovery?pretty' VIEW IN CONSOLE=http://localhost:5601/app/kibana#/dev_tools/console?load_from=https://www.elastic.co/guide/en/elasticsearch/reference/current/snippets/restart-upgrade/5.json
一旦集群状态变成green，就意味着所有主分片和分片都恢复好了。
重新索引的方式升级（Reindex to upgrade）
新版本的es可以使用上一个大版本创建的索引。例如，es5.x可以使用es2.x创建的索引，但不能使用es1.x创建的索引。
使用太旧的索引会导致es启动失败。
如果你正在运行es2.x集群，它包含2.x之前创建的索引，你要么删除这些旧索引，要么在升级到5.x之前重新索引它们。
如果你正在运行 es1.x集群，你有两个办法：
首先升级到es2.4,重新索引旧索引，然后升级到5.x
创建一个新的5.x集群，然后使用 reindex-from-remote直接从1.x集群导入索引。查阅 Upgrading with reindex-from-remote.
Time-based indices and retention periods 大多数基于时间的索引，都不需要担心如何从1.x升到5.x。基于时间的数据通常随着时间流逝越来越不感兴趣。一旦这些数据超出了你定义的保存期限，你就可以支持删除它。
Reindex in place
reindex 旧版（1.x）索引，最简单的方法是使用 Elasticsearch Migration Plugin。首先你需要升级到es2.3x或es2.4x。
迁移插件中提供的reindex工具用来：
创建一个新版本的的索引，并把es的版本号追加到索引名字结尾部分（例如，my_index-2.4.1），复制旧索引的mapping和setting。禁用新索引refresh功能，并把复制分片的数量设置为0，以便提高reindex的速度。
把旧索引设置为只读状态，确保不会有新数据写到旧索引
从旧索引中reindex所有数据到新索引。
重置新索引的refresh_interval和number_of_replicas值（与旧索引一致），等待新索引变成green状态
把旧索引的别名添加到新索引
删除旧索引
添加一个别名到新索引，并把它的名字改为旧索引的名字，例如 别名my_index 指向my_index-2.4.1
在这个过程处理完毕后，你将会获得一个2.x版本的索引，并且可以用在es5.x的集群中。
Upgrading with reindex-from-remote
如果你正在运行1.x集群，并且你想不经过2.x直接迁移到5.x ，你可以使用 reindex-from-remote.
es 包含向后兼代码，它允许旧的大版本的索引可以升级到当前版本。你可以支持从ex1.x升级到es5.x，解决所有向后兼容的问题。
5.1x的集群要求能够访问1.x集群的REST API.
为了把1.x索引升级到5.x，你需要：
在5.x集群中创建一个具有合适的 mappings and settings的索引。设置refresh_interval为-1，number_of_replicas为9，加快索引速度。
使用 reindex-from-remote从1.x索引拉取文档到5.x索引。
如果你的reindex操作在背景运行（wait_for_completion set to false），reindex请求将会返回一个task_id ，它可以用来监控reindex 操作的处理进度，GET _tasks/TASK_ID.
一旦reindex完成，把refresh_interval和number_of_replicas设置为你想要的值（默认值分别是30s和1）
一旦新索引完成复制，你就可以删除旧索引。
停止elasticsearch（Stopping Elasticsearch）
有序关闭elasticsearch确保它可以清理和关闭资源。例如，有序关闭的节点首先会离开集群，然后同步事务日志 到磁盘，并且执行其他相关的清理操作。你可以适当停止es，确保elasticsearch以有序的方式关闭。
如果你以服务的形式运行elasticsearch，你可以通过应用程序提供的服务管理功能关闭它。
如果你直接运行elasticsearch，你可以通过control-C停止它。如果你运行在控制台，你可以发送 SIGTERM信号给elasticsearch进程。你可以通过ps或jps命令获取进程id。
$ jps | grep Elasticsearch 14542 Elasticsearch
或者从启动日志获取：
[2016-07-07 12:26:18,908][INFO ][node ] [I8hydUG] version[5.0.0-alpha4], pid[15399], build[3f5b994/2016-06-27T16:23:46.861Z], OS[Mac OS X/10.11.5/x86_64], JVM[Oracle Corporation/Java HotSpot(TM) 64-Bit Server VM/1.8.0_92/25.92-b14]
或者在启动的时候把PID保存到文件中：
$ ./bin/elasticsearch -p /tmp/elasticsearch-pid -d $ cat /tmp/elasticsearch-pid && echo 15516 $ kill -SIGTERM 15516
在发生致命错误时停止（Stopping on Fatal Errors）
在elasticsearch运行过程中，有可能会发生某些致命错误，并且使虚拟机处于有问题的状态。这些致命错误包括内存溢出错误，虚拟机内部错误，io错误等。
当发错这些错误时，elasticsearch会把他们写到日志中，然后停止虚拟机。非正常关闭中，es并不会和上述那样做一些善后操作，而是会返回一个错误码。
JVM internal error 128 Out of memory error 127 Stack overflow error 126 Unknown virtual machine error 125 Serious I/O error 124 Unknown fatal error 1
推荐阅读