//www.greatytc.com/p/9605a8ce3b34
重要配置项的修改
Elasticsearch 已经有了 很好 的默认值， 特别是涉及到性能相关的配置或者选项。 如果你有疑问，最好就不要动它。
官方已经目睹了数十个因为错误的设置而导致毁灭的集群， 因为它的管理者总认为改动一个配置或者选项就可以带来 100 倍的提升。
其它数据库可能需要调优，但总得来说，Elasticsearch 不需要。 如果你遇到了性能问题，解决方法通常是更好的数据布局或者更多的节点。 在 Elasticsearch 中很少有“神奇的配置项”， 如果存在，官方也已经帮你优化了！
下面有些 逻辑上的 配置在生产环境中是应该调整的。 这些调整可能会让你的工作更加轻松，又或者因为没办法设定一个默认值（因为它取决于你的集群布局）。
下面的需要修改的配置项均在 elasticsearch.yml 文件中修改。
指定集群名字
Elasticsearch 默认启动的集群名字叫 elasticsearch 。 你最好给你的生产环境的集群改个名字，改名字的目的很简单， 就是防止某人的笔记本电脑加入了集群这种意外。
官方建议，简单修改成 elasticsearch_production 会很省心。
cluster.name: elasticsearch_production
指定节点名字
同样，最好也修改你的节点名字。
因为，Elasticsearch 会在你的节点每次启动的时候随机给它指定一个名字。
这样就是导致群集每次在启动的时候，节点会得到一个新的名字。这会使日志变得很混乱，因为所有节点的名称都是不断变化的。
建议给每个节点设置一个有意义的、清楚的、描述性的名字：
node.name: elasticsearch_005_data
指定相关路径
默认情况下， Elasticsearch 会把插件、日志以及你最重要的数据放在安装目录下。这会带来不幸的事故， 如果你重新安装 Elasticsearch 的时候不小心把安装目录覆盖了。如果你不小心，你就可能把你的全部数据删掉了。
最好的选择就是把你的数据目录配置到安装目录以外的地方， 同样你也可以选择转移你的插件和日志目录。
path.data: /path/to/data1,/path/to/data2
# Path to log files:
path.logs: /path/to/logs
# Path to where plugins are installed:
path.plugins: /path/to/plugins
- 注意：你可以通过逗号分隔指定多个目录。
数据可以保存到多个不同的目录， 如果将每个目录分别挂载不同的硬盘，这可是一个简单且高效实现一个软磁盘阵列（ RAID 0 ）的办法。
集群优化
elasticsearch节点怎么脱离集群初始化？
index.number_of_shards: 1
index.number_of_replicas: 0
2个属性会禁用分布式，这两个属性的设置直接影响集群中索引和搜索操作的执行
关于性能和安全的提示
Elasticsearch 试图将全部的条带化分片放到单个驱动器来保证最小程度的数据丢失。这意味着 分片 0 将完全被放置在单个驱动器上。 Elasticsearch 没有一个条带化的分片跨越在多个驱动器，因为一个驱动器的损失会破坏整个分片。
这对性能产生的影响是：如果您添加多个驱动器来提高一个单独索引的性能，可能帮助不大，因为 大多数节点只有一个分片和这样一个积极的驱动器。多个数据路径只是帮助如果你有许多索引／分片在单个节点上。
设置最新主节点数
minimum_master_nodes 设定对你的集群的稳定 极其 重要。
当你的集群中有两个 masters（注：主节点）的时候，这个配置有助于防止 脑裂 。
如果你的集群发生了脑裂，那么你的集群就会处在丢失数据的危险中，因为主节点被认为是这个集群的最高统治者，它决定了什么时候新的索引可以创建，分片是如何移动的等等。如果你有 两个 masters 节点， 你的数据的完整性将得不到保证，因为你有两个节点认为他们有集群的控制权，就会导致冲突。
此设置应该始终被配置为 master 候选节点的法定个数（大多数个）。法定个数就是 ( master 候选节点个数 / 2) + 1 。 这里有几个例子：
- 如果你有 10 个节点（能保存数据，同时能成为 master），法定数就是 6 。
- 如果你有 3 个候选 master 节点，和 100 个 data 节点，法定数就是 2 ，你只要数数那些可以做 master 的节点数就可以了。
- 如果你有两个节点，你遇到难题了。法定数当然是 2 ，但是这意味着如果有一个节点挂掉，你整个集群就不可用了。 设置成 1 可以保证集群的功能，但是就无法保证集群脑裂了，像这样的情况，你最好至少保证有 3 个节点。
建议这样配置：
discovery.zen.minimum_master_nodes: 2
但是由于 ELasticsearch 是动态的，你可以很容易的添加和删除节点， 但是这会改变这个法定个数。 你不得不修改每一个索引节点的配置并且重启你的整个集群只是为了让配置生效。
解决办法是同时添加如下的配置项：
PUT /_cluster/settings
{
"persistent" : {
"discovery.zen.minimum_master_nodes" : 2
}
}
这个配置允许通过 API 调用的方式动态进行配置。
==这将成为一个永久的配置，并且无论你配置项里配置的如何，这个将优先生效。==
==当你添加和删除 master 节点的时候，你需要通过 API 的方式更改这个配置。==
关于集群恢复涉及到的配置
当你集群重启时，几个配置项影响你的分片恢复的表现。 首先，我们需要明白如果什么也没配置将会发生什么。
想象一下假设你有 10 个节点，每个节点只保存一个分片，这个分片是一个主分片或者是一个副本分片，或者说有一个有 5 个主分片／1 个副本分片的索引。当处于某种原因，你不得不暂时关闭所有集群节点，之后再重新启动所有节点。
就在你重启所有节点的过程中，不管处于什么原因，恰巧有 5 个节点没有和其他 5 个节点同时启动。
这时，你会有 5 个节点在线上，这五个节点会相互通信，选出一个 master，从而形成一个集群。 他们注意到数据不再均匀分布，因为有 5 个节点在集群中丢失了，所以他们之间会立即启动分片复制。
最后，你的其它 5 个节点打开加入了集群。这些节点会发现 它们 的数据正在被复制到其他节点，所以他们删除本地数据（因为这份数据要么是多余的，要么是过时的）。 然后整个集群重新进行平衡，因为集群的大小已经从 5 变成了 10。
在这整个过程中，你的节点会消耗磁盘和网络带宽，来回移动数据，因为没有更好的办法。对于有 TB 数据的大集群, 这种无用的数据传输需要 很长时间 。
假如等待所有的节点都重启好了，整个集群的相关功能再上线，这样所有的本地的数据就都不需要移动了。
所以我们可以做一些配置来来缓解这种情况的发生。
- 对于上面的情况，首先我们要给 ELasticsearch 一个 严格 的限制：
gateway.recover_after_nodes: 8
这个值的设定取决于个人喜好：整个集群提供服务之前你希望有多少个节点在线？
这里我们设置为 8，这意味着至少要有 8 个节点（数据节点或者 master 节点）在线，该集群才可用，才进行数据恢复。
- 此外，我们还需要告诉 elasticsearch 集群中的每个成员，该集群应该有多少个节点，以及我们愿意等待这些节点恢复在线状态，付出多少时间。
gateway.expected_nodes: 10
gateway.recover_after_time: 5m
这意味着 Elasticsearch 会采取如下操作：
等待集群至少存在 8 个节点
等待 5 分钟，或者10 个节点上线后，才进行数据恢复，这取决于哪个条件先达到。
这三个设置可以在集群重启的时候避免过多的分片交换。这可能会让数据恢复从 数个小时 缩短为 几秒钟。
gateway.expected_nodes
预计在群集中的（数据或主节点）数量。一旦预期的节点数量加入到群集中，本地碎片的恢复就会开始。默认为0
gateway.expected_master_nodes
预计将在群集中的主节点的数量。当主节点加入集群时，本地碎片的恢复将立即开始。默认为0
gateway.expected_data_nodes
预计将在群集中的数据节点的数量。只要预期的数据节点已加入群集，就会立即恢复本地碎片。默认为0
gateway.recover_after_time
如果未达到预期的节点数量，则无论恢复尝试恢复，恢复过程都会等待配置的时间量。默认为5m如果expected_nodes配置其中一个设置。
一旦recover_after_time持续时间超时，只要满足以下条件，恢复就会开始：
gateway.recover_after_nodes #只要这么多数据或主节点已加入群集，就可以进行恢复。
gateway.recover_after_master_nodes # 只要这么多的主节点已经加入群集就可以恢复。
gateway.recover_after_data_nodes # 只要这么多的数据节点已经加入群集就可以恢复
==注意：这些配置只能设置在 config/elasticsearch.yml 文件中或者是在命令行里（它们不能动态更新）它们只在整个集群重启的时候有实质性作用。==
- 故障检测，集群中 master 是如何确认其他成员存活的
一种是 master 主动 ping 各个成员
一种是 各个成员主动确认自己还活着
以下设置使用discovery.zen.fd前缀控制故障检测过程 ：
| 设置 | 描述 |
|---|---|
| ping_interval | 一个节点多久被ping一次。默认为1s。 |
| ping_timeout | 等待ping响应需要多长时间，默认为 30s。 |
| ping_retries | 有多少ping故障/超时会导致节点被视为失败。默认为3。 |
使用单播代替组播编辑
Elasticsearch 默认被配置为使用单播发现，以防止节点无意中加入集群。只有在同一台机器上运行的节点才会自动组成集群。
虽然组播仍然 作为插件提供， 但它应该永远不被使用在生产环境了，否在你得到的结果就是一个节点意外的加入到了你的生产环境，仅仅是因为他们收到了一个错误的组播信号。
使用单播，你可以为 Elasticsearch 提供一些它应该去尝试连接的节点列表。 当一个节点联系到单播列表中的成员时，它就会得到整个集群所有节点的状态，然后它会联系 master 节点，并加入集群。
这意味着你的单播列表不需要包含你的集群中的所有节点， 它只是需要足够的节点，当一个新节点联系上其中一个并且说上话就可以了。如果你使用 master 候选节点作为单播列表，你只要列出三个就可以了。
这个配置可以配置成下面的样子：
discovery.zen.ping.unicast.hosts: ["host1", "host2:port"]
不需要修改的配置
在 Elasticsearch 中有一些热点，人们可能不可避免的会碰到。 我们理解的，所有的调整就是为了优化，但是这些调整，你真的不需要理会它。因为它们经常会被乱用，从而造成系统的不稳定或者糟糕的性能，甚至两者都有可能。
垃圾回收器( GC )
Elasticsearch 默认的垃圾回收器（ GC ）是 CMS。 这个垃圾回收器可以和应用并行处理，以便它可以最小化停顿。 然而，它有两个 stop-the-world 阶段，处理大内存也有点吃力。
尽管有这些缺点，它还是目前对于像 Elasticsearch 这样低延迟需求软件的最佳垃圾回收器。官方建议使用 CMS。
现在有一款新的垃圾回收器，叫 G1 垃圾回收器（ G1GC ）。 这款新的 GC 被设计，旨在比 CMS 更小的暂停时间，以及对大内存的处理能力。 它的原理是把内存分成许多区域，并且预测哪些区域最有可能需要回收内存。通过优先收集这些区域（ garbage first ），产生更小的暂停时间，从而能应对更大的内存。
遗憾的是，G1GC 还是太新了，经常发现新的 bugs。这些错误通常是段（ segfault ）类型，便造成硬盘的崩溃。 Lucene 的测试套件对垃圾回收算法要求严格，看起来这些缺陷 G1GC 并没有很好地解决，还不能足够稳定的满足 Elasticsearch 和 Lucene 的要求。
线程池
许多人 喜欢 调整线程池。 无论什么原因，人们都对增加线程数无法抵抗。索引太多了？增加线程！搜索太多了？增加线程！节点空闲率低于 95％？增加线程！
Elasticsearch 默认的线程设置已经是很合理的了。对于所有的线程池（除了 搜索 ），线程个数是根据 CPU 核心数设置的。 如果你有 8 个核，你可以同时运行的只有 8 个线程，只分配 8 个线程给任何特定的线程池是有道理的。
搜索线程池设置的大一点，配置为 int（（ 核心数 ＊ 3 ）／ 2 ）＋ 1 。
大多数 I／O 的操作是由 Lucene 线程管理的，而不是 Elasticsearch。
此外，线程池通过传递彼此之间的工作配合。你不必再因为它正在等待磁盘写操作而担心网络线程阻塞， 因为网络线程早已把这个工作交给另外的线程池，并且网络进行了响应。
最后，你的处理器的计算能力是有限的，拥有更多的线程会导致你的处理器频繁切换线程上下文。 一个处理器同时只能运行一个线程。所以当它需要切换到其它不同的线程的时候，它会存储当前的状态（寄存器等等），然后加载另外一个线程。 如果幸运的话，这个切换发生在同一个核心，如果不幸的话，这个切换可能发生在不同的核心，这就需要在内核间总线上进行传输。
这个上下文的切换，会给 CPU 时钟周期带来管理调度的开销；在现代的 CPUs 上，开销估计高达 30 μs。也就是说线程会被堵塞超过 30 μs，如果这个时间用于线程的运行，极有可能早就结束了。
人们经常稀里糊涂的设置线程池的值。8 个核的 CPU，我们遇到过有人配了 60、100 甚至 1000 个线程。 这些设置只会让 CPU 实际工作效率更低。
所以，下次请不要调整线程池的线程数。如果你真 想调整 ， 一定要关注你的 CPU 核心数，最多设置成核心数的两倍，再多了都是浪费。
堆内存： 大小 和 交换
就是 java 虚拟机的内存设置。
最新版的 5.x 设置堆内存是在 jvm.options 文件中：
下面的是默认值 2 G
-Xms2g
-Xmx2g
==确保堆内存最小值（ Xms ）与最大值（ Xmx ）的大小是相同的，防止程序在运行时改变堆内存大小， 这是一个很耗系统资源的过程==
官方建议通过设置环境变量来设置这个值：
export ES_HEAP_SIZE=10g
- 把你的内存的（少于）一半给 Lucene编辑
假如，不会有剩余的内存交给 Lucene。 这将严重地影响全文检索的性能。
==如果你不需要对分词字符串做聚合计算（例如，不需要 fielddata ）可以考虑降低堆内存。堆内存越小，Elasticsearch（更快的 GC）和 Lucene（更多的内存用于缓存）的性能越好。==
不用分配大于 32 G的内存给 Elasticsearch
这里有另外一个原因不分配大内存给 Elasticsearch。事实上 ， JVM 在内存小于 32 GB 的时候会采用一个内存对象指针压缩技术。
一旦你越过那个神奇的 ~32 GB 的边界，指针就会切回普通对象的指针。 每个对象的指针都变长了，就会使用更多的 CPU 内存带宽，也就是说你实际上失去了更多的内存。事实上，当内存到达 40–50 GB 的时候，有效内存才相当于使用内存对象指针压缩技术时候的 32 GB 内存。
这段描述的意思就是说：即便你有足够的内存，也尽量不要 超过 32 GB。因为它浪费了内存，降低了 CPU 的性能，还要让 GC 应对大内存。
我有一个 1 TB 内存的机器！
这个 32 GB 的分割线是很重要的。那如果你的机器有很大的内存怎么办呢？ 一台有着 512–768 GB内存的服务器愈发常见。
首先，我们建议避免使用这样的高配机器（参考 硬件）。
但是如果你已经有了这样的机器，你有三个可选项：
1. 你主要做全文检索吗？考虑给 Elasticsearch 4 - 32 GB 的内存， 让 Lucene 通过操作系统文件缓存来利用余下的内存。那些内存都会用来缓存 segments，带来极速的全文检索。
2. 你需要更多的排序和聚合？而且大部分的聚合计算是在数字、日期、地理点和 非分词 字符串上？你很幸运，你的聚合计算将在内存友好的 doc values 上完成！ 给 Elasticsearch 4 到 32 GB 的内存，其余部分为操作系统缓存内存中的 doc values。
3. 你在对分词字符串做大量的排序和聚合（例如，标签或者 SigTerms，等等）不幸的是，这意味着你需要 fielddata，意味着你需要堆空间。考虑在单个机器上运行两个或多个节点，而不是拥有大量 RAM 的一个节点。仍然要坚持 50％ 原则。
假设你有个机器有 128 GB 的内存，你可以创建两个节点，每个节点内存分配不超过 32 GB。 也就是说不超过 64 GB 内存给 ES 的堆内存，剩下的超过 64 GB 的内存给 Lucene。
如果你选择这一种，你需要配置
cluster.routing.allocation.same_shard.host: true 。
这会防止同一个分片（shard）的主副本存在同一个物理机上（因为如果存在一个机器上，副本的高可用性就没有了）
Swapping 是性能的坟墓
有必要说的更清楚一点：内存交换 到磁盘对服务器性能来说是 致命 的。想想看：一个内存操作必须能够被快速执行。
如果内存交换到磁盘上，一个 100 微秒的操作可能变成 10 毫秒。 再想想那么多 10 微秒的操作时延累加起来。 不难看出 swapping 对于性能是多么可怕。
最好的办法就是在你的操作系统中完全禁用 swap。这样可以暂时禁用：
sudo swapoff -a
如果需要永久禁用，你可能需要修改 /etc/fstab 文件，这要参考你的操作系统相关文档。
如果你并不打算完全禁用 swap，也可以选择降低 swappiness 的值。 这个值决定操作系统交换内存的频率。 这可以预防正常情况下发生交换，但仍允许操作系统在紧急情况下发生交换。
对于大部分Linux操作系统，可以在 sysctl 中这样配置：
vm.swappiness = 1
- swappiness 设置为 1 比设置为 0 要好，因为在一些内核版本 swappiness 设置为 0 会触发系统 OOM-killer（注：Linux 内核的 Out of Memory（OOM）killer 机制）。
最后，如果上面的方法都不合适，你需要打开配置文件中的 mlockall 开关。 它的作用就是允许 JVM 锁住内存，禁止操作系统交换出去。在你的 elasticsearch.yml 文件中，设置如下：
bootstrap.mlockall: true
设置文件描述符数量
max_file_descriptors 字段显示 Elasticsearch 进程可以访问的可用文件描述符数量。
Elasticsearch 对各种文件混合使用了 NioFs（ 注：非阻塞文件系统）和 MMapFs （ 注：内存映射文件系统）。请确保你配置的最大映射数量，以便有足够的虚拟内存可用于 mmapped 文件。这可以暂时设置：
sysctl -w vm.max_map_count=262144
或者你可以在 /etc/sysctl.conf 通过修改 vm.max_map_count 永久设置它。
部署之后
动态更新集群的相关设置
Elasticsearch 里很多设置都是动态的，可以通过 API 修改。需要强制重启节点（或者集群）的配置修改都要极力避免。 而且虽然通过静态配置项也可以完成这些变更，我们建议你还是用 API 来实现。
集群更新 API 有两种工作模式：
临时（Transient）
这些变更在集群重启之前一直会生效。一旦整个集群重启，这些配置就被清除。
永久（Persistent）
这些变更会永久存在直到被显式修改。即使全集群重启它们也会存活下来并覆盖掉静态配置文件里的选项。
临时或永久配置需要在 JSON 体里分别指定：
PUT /_cluster/settings
{
"persistent" : {
# 这里面的设置项会永久生效
"discovery.zen.minimum_master_nodes" : 2
},
"transient" : {
# ；这里面的设置之会临时生效
"indices.store.throttle.max_bytes_per_sec" : "50mb"
}
}
