[翻译]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核心数,最多设置成核心数的两倍,再多了都是浪费。

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

留言

提示:你的email不会被公布,欢迎留言^_^

*

验证码 * Time limit is exhausted. Please reload CAPTCHA.