Elasticsearch重要文章之一:不要触碰这些配置

在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核心数，最多设置成核心数的两倍，再多了都是浪费。