Elasticsearch集群部署中重要配置的修改不要触碰的配置

Elasticsearch集群部署中重要配置的修改-不要触碰的配置目录1垃圾回收器2线程池垃圾回收器1垃圾回收器（一）

在Elasticsearch中有一些热点，人们可能不可避免的会碰到。我们理解的，所有的调整就是为了优化，但是这些调整，你真的不需要理会它。因为它们经常会被乱用，从而造成系统的不稳定或者糟糕的性能，甚至两者都有可能一、垃圾回收器JVM使用一个垃圾回收器来释放不再使用的内存。

不要更改默认的垃圾回收器！Elasticsearch默认的垃圾回收器（GC）是CMS。这个垃圾回收器可以和应用并行处理，以便它可以最小化停顿。然而，它有两个stop-the-world阶段，处理大内存也有点吃力。

尽管有这些缺点，它还是目前对于像Elasticsearch这样低延迟需求软件的最佳垃圾回收器。官方建议使用CMS。垃圾回收器（二）

现在有一款新的垃圾回收器，叫G1垃圾回收器（G1GC）。这款新的GC被设计，旨在比CMS更小的暂停时间，以及对大内存的处理能力。它的原理是把内存分成许多区域，并且预测哪些区域最有可能需要回收内存。通过优先收集这些区域（

garbagefirst

），产生更小的暂停时间，从而能应对更大的内存。G1GC还是太新了，经常发现新的bugs。这些错误通常是段（segfault）类型，便造成硬盘的崩溃。Lucene的测试套件对垃圾回收算法要求严格，看起来这些缺陷G1GC并没有很好地解决。

很希望在将来某一天推荐使用G1GC，但是对于现在，它还不能足够稳定的满足Elasticsearch和Lucene的要求。线程池2线程池（一）线程池

许多人喜欢调整线程池。无论什么原因，人们都对增加线程数无法抵抗。索引太多了？增加线程！搜索太多了？增加线程！节点空闲率低于95％？增加线程！Elasticsearch默认的线程设置已经是很合理的了。对于所有的线程池（除了搜索），线程个数是根据CPU核心数设置的。如果有8个核，可以同时运行的只有8个线程，只分配8个线程给任何特定的线程池是有道理的。

搜索线程池设置的大一点，配置为

int（（核心数＊3）／2）＋1

。可能会认为某些线程可能会阻塞（如磁盘上的I／O操作），所以才想加大线程的。对于Elasticsearch来说这并不是一个问题：因为大多数I／O的操作是由Lucene线程管理的，而不是Elasticsearch。线程池（二）

此外，线程池通过传递彼此之间的工作配合。不必再因为它正在等待磁盘写操作而担心网络线程阻塞，因为网络线程早已把这个工作交给另外的线程池，并且网络进行了响应。

最后，处理器的计算能力是有限的，拥有更多的线程会导致你的处理器频繁切换线程上下文。一个处理器同时只能运行一个线程。所以当它需要切换到其它不同的线程的时候，它会存储当前的状态（寄存器等等），然后加载另外一个线程。如果幸运的话，这个切换发生在同一个核心，如果不幸的话，这个切换可能发生在不同的核心，这就需要在内核间总线上进行传输。

这个上下文的切换，会给CPU时钟周期带来管理调度的开销；在现代的CPUs上，开销估计高达30μs。也就是说线程会被堵塞超过30μs，如果这个时间用于线程的运行，极有可能早就结束了。人们经常稀里糊涂的设置线程池的值。8个核的CPU，我们遇到过有人配了60、100甚至1000个线程。这些设置