Elasticsearch:Lucene Merge Thread的高CPU使用率

时间:2016-11-23 23:34:38

标签: elasticsearch lucene

我有一个ES 2.4.1群集,其中包含3个主节点和18个数据节点,这些节点每天都会创建一个新索引来收集日志数据。在一天中,索引大小增长到大约2TB。超过7天的索引将被删除。在群集上执行的搜索非常少,因此主要目标是增加索引吞吐量。

我看到以下很多例外,这是我接下来要说的另一个症状:

EsRejectedExecutionException[rejected execution of org.elasticsearch.transport.TransportService$4@5a7d8a24 on EsThreadPoolExecutor[bulk, queue capacity = 50, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@5f9ef44f[Running, pool size = 8, active threads = 8, queued tasks = 50, completed tasks = 68888704]]];]];

群集中的节点一直在ping CPU。我将索引刷新间隔增加到30秒,但效果不大。当我检查热线程时,我看到每个节点使用100%CPU的多个“Lucene Merge Thread”。我还注意到每个碎片的段数一直在1000左右,这似乎很多。以下是分段统计信息的示例:

"_2zo5": {
  "generation": 139541,
  "num_docs": 5206661,
  "deleted_docs": 123023,
  "size_in_bytes": 5423948035,
  "memory_in_bytes": 7393758,
  "committed": true,
  "search": true,
  "version": "5.5.2",
  "compound": false
}

非常高的“生成”数字令我担心,我想优化段创建和合并以减少节点上的CPU负载。

有关索引和群集配置的详细信息:

  • 每个节点都是具有8个CPU核心和1.6T SSD驱动器的i2.2xl AWS实例
  • 文档由6个批量大小为1000的客户端线程持续编制索引
  • 每个索引有30个分片,1个副本
  • 每批1000份文件大约需要25秒
  • / _ cat / thread_pool?h = bulk *& v表​​示bulk.completed在节点间分布均匀
  • 索引缓冲区大小和事务持久性保留为默认值
  • _all已禁用,但已启用动态映射
  • 默认情况下保留合并线程的数量,鉴于我正在使用SSD
  • ,这应该是正常的

最好的方法是什么?

谢谢!

2 个答案:

答案 0 :(得分:3)

以下是我对群集进行的优化,以提高索引吞吐量:

  • 将threadpool.bulk.queue_size增加到500,因为索引请求经常超载队列
  • 增加了磁盘水印,因为默认设置对我们使用的大型SSD来说过于激进。我设置了#34; cluster.routing.allocation.disk.watermark.low":" 100gb"和#34; cluster.routing.allocation.disk.watermark.high":" 10gb"
  • 删除未使用的索引以释放ES用于管理其分片的资源
  • 将主分片数量增加到175,目标是将分片大小保持在50GB以下,每个处理器大约有一个分片
  • 将客户端索引批量大小设置为10MB,这对我们来说似乎非常有效,因为索引的文档大小差异很大(从KB到MB)

希望这有助于其他人

答案 1 :(得分:0)

我已经运行了类似的工作负载,您最好的选择是运行每小时指数并对旧指数运行优化以保持细分市场。