在部署ES时 Linux 的设置有哪些优化

• 64 GB 内存的机器是非常理想的， 但是 32 GB 和 16 GB 机器也是很常见的。少于 8 GB 会适得其反
• 如果要在更快的 CPUs 和更多的核心之间选择，选择更多的核心更好。多个内核提供的额外并发远胜过稍微快一点点的时钟频率
• 如果负担得起 SSD，它将远远超出任何旋转介质。 基于 SSD 的节点，查询和索引性能都有提升
• 即使数据中心们近在咫尺，也要避免集群跨越多个数据中心
  • 绝对要避免集群跨越大的地理距离
• 请确保运行应用程序的 JVM 和服务器的 JVM 是完全一样的
  • 在 Elasticsearch 的几个地方，使用 Java 的本地序列化
• 通过设置 gateway.recover_after_nodes、 gateway.expected_nodes、 gateway.recover_after_time 可以在集群重启的时候避免过多的分片交换，这可能会让数据恢复从数个小时缩短为几秒钟
• Elasticsearch 默认被配置为使用单播发现，以防止节点无意中加入集群
  • 只有在同一台机器上运行的节点才会自动组成集群
  • 最好使用单播代替组播
• 不要随意修改垃圾回收器（CMS）和各个线程池的大小
• 把少于内存的一半给 Lucene（但不要超过 32 GB），通过 ES_HEAP_SIZE 环境变量设置
• 内存交换到磁盘对服务器性能来说是致命的
  • 如果内存交换到磁盘上，一个 100 微秒的操作可能变成 10 毫秒。 那么多 10 微秒的操作时延累加起来。 不难看出 swapping 对于性能是多么可怕
• Lucene 使用了大量的文件。同时， Elasticsearch 在节点和 HTTP 客户端之间进行通信也使用了大量的套接字。 所有这一切都需要足够的文件描述符。应该增加文件描述符，设置一个很大的值，如 64,000

索引阶段性能提升方法

• 使用批量请求并调整其大小：每次批量数据 5–15 MB 大是个不错的起始点
• 存储：使用 SSD
• 段和合并：Elasticsearch 默认值是 20 MB/s，对机械磁盘应该是个不错的设置
  • 如果用的是 SSD，可考虑提高到 100–200 MB/s
  • 如果在做批量导入，完全不在意搜索，可以彻底关掉合并限流
  • 可以增加 index.translog.flush_threshold_size 设置，从默认的 512 MB 到更大一些的值，比如 1 GB，可以在一次清空触发的时候在事务日志里积累出更大的段
• 如果搜索结果不需要近实时的准确度，考虑把每个索引的 index.refresh_interval 改到 30s
• 如果在做大批量导入，考虑通过设置 index.number_of_replicas: 0 关闭副本