赵岩的博客

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

垃圾收集器

在章节已经有一个简短的介绍，JVM使用一个垃圾收集器来释放不再使用的内存，这篇内容的确是上一篇的一个延续，但是因为重要，所以值得单独拿出来作为一节。

不要更换默认的垃圾收集器！
Elasticsearch默认的垃圾收集器是CMS垃圾收集器。这个垃圾收集器因为可以和应用并行处理，所以有很小的暂停，当然它有两个stop-the-world阶段，处理大内存也有点吃力。

尽管这些缺点，它也是目前像Elasticsearch这样低延迟需求的软件的最佳垃圾收集器。官方建议使用CMS。

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

听起来不错，很遗憾的是G1 GC还是太新，经常有bug爆出，这些bug大都是段错误那种，会导致硬盘崩溃。Lucene的测试套件对GC是很严格残酷的，好像G1 GC一直都无法完全胜任。

我们很希望在将来某一天推荐使用G1 GC，但是对于现在，它还不能足够稳定以满足Elasticsearch和luncene的要求。

线程池

许多人喜欢调整线程池，无论什么原因，人们好像都无法抵挡的想增加线程数。索引太多了？增加线程！搜索太多了，增加线程！节点空闲率低于95%？ 增加线程！
Elasticsearch默认的线程设置已经是很合理的了。对于所有的线程池（除了搜索的），线程个数是根据CPU核心数设置的。如果你有8个核，你可以同时运行8个线程，那么对于一些线程池，你设置8个线程是合适的。

搜索线程池设置的大一点，是核心数的3倍。

你可能争辩说，一些线程会堵塞在IO处，所以你才想加大线程的。对于elasticsearch来说，这不是问题，因为大多数IO的操作是由Lucene线程管理的，而不是Elasticsearch。
此外，线程池通过彼此之间的合作工作。你不需要担心网络相关的线程因为它在等待磁盘写入而堵塞。因为网络线程早已把这个工作交给另外的线程池，并且网络进行了响应。

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

这个上下文的切换，会循环的带来管理调度开销，在现代的CPU上，估计高达30us，也就是说线程会被堵塞30us，如果这个时间用于线程的运行，估计早就结束了。

人们经常稀里糊涂的设置线程池的值，8个核的CUP，我们见过有人配了60,100甚至1000个线程，这些设置只会让CPU实际工作效率更低。

所以下次请不要调整线程池的线程数，如果真想调整，一定要关注你的CPU核心数，最多设置成核心数的两倍，再多了都是浪费。

原文地址：http://www.elastic.co/guide/en/elasticsearch/guide/current/_don_8217_t_touch_these_settings.html