接着上一篇  Elasticsearch 最全调优，最佳实践（一）

15、在 Elasticsearch 中，是怎么根据一个词找到对应的倒排索引的？

• Lucene 的索引过程，就是按照全文检索的基本过程，将倒排表写成此文件格式的过程。

• Lucene 的搜索过程，就是按照此文件格式将索引进去的信息读出来，然后计算每篇文档打分(score)的过程。

16、Elasticsearch 在部署时，对 Linux 的设置有哪些优化方法？

（1）64 GB 内存的机器是非常理想的， 但是 32 GB 和 16 GB 机器也是很常见的。少于 8 GB 会适得其反。

• 如果你要在更快的CPUs 和更多的核心之间选择，选择更多的核心更好。多个内核提供的额外并发远胜过稍微快一点点的时钟频率。

• 如果你负担得起SSD，它将远远超出任何旋转介质。 基于SSD 的节点，查询和索引性能都有提升。如果你负担得起，SSD 是一个好的选择。

• 即使数据中心们近在咫尺，也要避免集群跨越多个数据中心。绝对要避免集群跨越大的地理距离。

• 请确保运行你应用程序的JVM 和服务器的JVM 是完全一样的。 在

Elasticsearch 的几个地方，使用Java 的本地序列化。

• 通过设置gateway.recoverafternodes、gateway.expectednodes、 gateway.recoverafter_time 可以在集群重启的时候避免过多的分片交换，这可能会让数据恢复从数个小时缩短为几秒钟。

• Elasticsearch 默认被配置为使用单播发现，以防止节点无意中加入集群。只有在同一台机器上运行的节点才会自动组成集群。最好使用单播代替组播。

• 不要随意修改垃圾回收器（CMS）和各个线程池的大小。

• 把你的内存的（少于）一半给Lucene（但不要超过 32 GB！），通过 ESHEAPSIZE 环境变量设置。

• 内存交换到磁盘对服务器性能来说是致命的。如果内存交换到磁盘上，一个 100 微秒的操作可能变成 10 毫秒。 再想想那么多 10 微秒的操作时延累加起来。 不难看出swapping 对于性能是多么可怕。

• Lucene 使用了大量的文件。同时，Elasticsearch 在节点和HTTP 客户端之间进行通信也使用了大量的套接字。 所有这一切都需要足够的文件描述符。你应该增加你的文件描述符，设置一个很大的值，如 64,000。

索引阶段性能提升方法

• 使用批量请求并调整其大小：每次批量数据 5–15 MB 大是个不错的起始点。

• 存储：使用SSD

• 段和合并：Elasticsearch 默认值是 20 MB/s，对机械磁盘应该是个不错的设置。如果你用的是SSD，可以考虑提高到 100–200 MB/s。如果你在做批量导入，完全不在意搜索，你可以彻底关掉合并限流。另外还可以增加 index.translog.flushthresholdsize 设置，从默认的 512 MB 到更大一些的值，比如 1 GB，这可以在一次清空触发的时候在事务日志里积累出更大的段。

• 如果你的搜索结果不需要近实时的准确度，考虑把每个索引的

index.refresh_interval 改到 30s。

• 如果你在做大批量导入，考虑通过设置index.numberofreplicas: 0 关闭副本。

16、对于 GC 方面，在使用 Elasticsearch 时要注意什么？

• 倒排词典的索引需要常驻内存，无法GC，需要监控data node 上

segmentmemory 增长趋势。

• 各类缓存，field cache, filter cache, indexing cache, bulk queue 等等，要设置合理的大小，并且要应该根据最坏的情况来看heap 是否够用，也就是各类缓存全部占满的时候，还有heap 空间可以分配给其他任务吗？避免采用clear cache 等 “自欺欺人”的方式来释放内存。

• 避免返回大量结果集的搜索与聚合。确实需要大量拉取数据的场景ÿ