elasticsearch不能触碰的配置

垃圾收集器(Garbage Collector)

Elasticsearh默认的GC是CMS。让GC并发的运行应用程序，以便最大限度的减少暂停时间。然而它有两个stop-the-world阶段，在回收大量的heaps。

    尽管有这些缺点，它是目前对于像Elasticsearch低延迟服务器软件的最佳的GC。 官方建议使用CMS。

    有一个新的GC叫垃圾第一GC（g1gc）。这个新的GC的设计是为了尽量减少停顿比CMS更大的堆，和操作。它的工作原理是将堆分割成区域，预测区域包含最可回收的空间。通过收集这些区域（第一），它可以最大限度地减少暂停和操作非常大的堆。
 
    听起来很棒！不幸的是，g1gc仍然是新的，和新的漏洞被发现的常规。这些错误通常会导致各种各样的段错误，硬盘崩溃。Lucene的测试套件是残酷的GC算法，似乎g1gc没有扭结的工作了。
 
    我们想总有一天会推荐g1gc，但现在，它只是不够稳定满足Elasticsearch和Lucene的要求

线程池(Threadpoolsedit)

每个人都喜欢好的线程池。不管出于什么原因，人们似乎无法抗拒增加线程数。索引很多？更多线程！搜索很多？更多线程！节点空闲时间95%的时间？更多线程！    

    在Elasticsearch默认的线程池的设置是非常明智的。 对于所有的线程池（除了search ）的经纬被设置为CPU核心的数量。 如果你有八个核心，你可以同时运行的只有八个线程。 它有道理仅分配八个线程在任何特定的线程池。

    搜索得到一个较大的线程池，并且被配置为 # cores * 3
 
    你可能会争辩说，一些线程可以阻止（如在一个磁盘上IO操作），这就是为什么你需要更多的线程。这不是一个问题：在Elasticsearch的磁盘I/O是由Lucene的线程处理，不是Elasticsearch。

    此外，合作的线程池通过传递彼此之间的工作。 您不必再担心网络线程阻塞，因为它正在等待磁盘写入。 联网线程都有，因为另一个线程池转交给了工作单位长期得到回网络。

    最后，你的程序的计算能力是有限的。 有更多的线程只是迫使处理器切换线程上下文。 处理器可以一次运行只有一个线程，因此当它需要切换到一个不同的线程，它存储了当前的状态（寄存器，等等），并装载另一个线程。 如果你是幸运的，交换机将发生在相同的核心。 如果你运气不好，开关可能会迁移到不同的核心，并要求运输核间通信总线上。

    这个上下文切换吃掉周期只需做管理清洁; 估计能挂它高达对现代的CPU为30μs。 所以，除非该线程将被阻塞比为30μs长，极有可能是那个时候会被更好地用刚刚加工和提早完成。

    人们通常设置线程池错误的值。 八核的机器，我们已经与60，100，甚至1000个线程运行在整个的configs。 这些设置将让CPU大于得到真正的工作要做。

    所以。 下次你要调整一个线程池，请不要。 如果你绝对无法抗拒 ，请保持你的核心数量在心中，也许设置数量增加一倍。 更重要的是仅仅是一种浪费。

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