如何快速更新充满渴望的全局序数

Question

我有一个8节点集群( AWS上的8 r3.xlarge，它使用的是与实例一起附带的短暂的80 on磁盘)。有一个主索引和两个主要索引类型。他们之间存在着父子关系。有7500万父母和1500万儿童。(我们定期清理孩子，但保留父母)

为了加速has_child查询，我在子字段的父字段上使用了热切的全局序号。

使用热切的全局序数似乎大大减慢了刷新时间。刷新现在最多需要3秒。

我相信我可以通过增加我的机器上的IO来加速更新。但是，还有什么其他设置我可以玩，以加快刷新吗？

我正在使用elasticsearch 1.4.2。

请注意，当我使用带有1个EBS卷的8m3.xLarge时，刷新速度更快。(这是没有意义的，因为EBS卷的IOs应该比临时磁盘慢.)

谢谢!

Answer 1

如果没有任何指标来指出争用的位置，这是很棘手的。你真的是自己人吗？还是计算界？我经常发现我是后者。这可能是您通过比较两种四核实例类型得出的结论，但当您进入r3时，其他情况也可能发生了变化。

有几件可能有帮助的事情：

• 取消合并节流，index.store.throttle.type: none。对于SSD，您不需要它，我们只是为了安全而打开它，这样索引就不会消耗一个方框。您可以将其设置为每个索引，但如果测试显示它有助于而不是减缓搜索速度，则只需将其放到每个节点的配置中，或者在创建索引时抛到应用程序中即可。
• 如果您使用的是Linux，请确保将数据卷的IO调度程序设置为noop，或者至少设置为deadline。当使用SSD时，CFQ应该是DTRT，但我还没有发现这是真的。此外，在EC2上，您不需要带有虚拟化层的任何存储(理论上)的调度程序。请记住，除非您看到写操作始终限制在60 if /s左右，或者如果您是计算机绑定的，否则这不会产生真正的影响。
• 由于您没有在m3上使用热切的加载，所以它实际上是苹果和橙子。只是一种预感，但速度放缓可能是一小步，段在堆积，只有在索引流量中断时才能恢复。您可以尝试将index.refresh_interval提高到5s，并查看手动刷新是否加快。这很容易用/_cat/segments/INDEX | wc -l进行监控。
• 您可以尝试增加允许Lucene使用的线程数。在四个核心上，您可能没有太多的空间(需要那些CPU图)，但是您可以做一些测试并检查它。index.merge.scheduler.max_thread_count: 6 (在硬件上默认为4)。