您应该考虑使用基于时间序列的索引，而不是TTL功能。假设您只关心文档的最近30分钟窗口，请使用基于日期/时间的命名约定为每30分钟创建一个新索引：docs-201309120000，docs-201309120030，docs-201309120100，docs-201309120130等（请注意命名惯例中30分钟的增量。）
使用Elasticsearch的索引别名功能（http://www.elasticsearch.org/guide/reference/api/admin- indices-aliases/），您可以别名docs到最近创建的索引，以便在进行批量索引时始终使用别名docs，但是docs-201309120130例如，它们将被写入。
查询时，您将过滤日期时间字段以确保仅返回最近30分钟的文档，并且您需要查询2个最近创建的索引以确保获得完整的30分钟的文档- 您可以在此处创建另一个别名以指向两个索引，或者直接查询两个索引名称。
使用此模型，您无需承担TTL使用的开销，并且仅可以删除过去一个多小时内未使用的旧索引。
还有其他方法也可以提高批量索引和查询的速度，但是我认为删除TTL将是最大的赢家- 另外，您的索引仅具有数量有限的数据要过滤/查询，这应该提供一个不错的选择提速。
这是我通常为运行ES的服务器调整的一些设置-http://pastebin.com/mNUGQCLY，请注意，它仅适用于1GB VPS，因此需要进行调整。
查看主数据库，数据数据库和“客户端” ES节点类型也可能对您有所帮助-http://www.elasticsearch.org/guide/reference/modules/node/
进行批量插入时，请考虑同时修改两者的值index.refresh_intervalindex.merge.policy.merge_factor-我看到您已将修改refresh_interval为5s，但请考虑-1在批量索引操作之前将其设置为，然后再返回所需的时间间隔。或者，考虑_refresh在批量操作完成后手动执行一次API命中，特别是如果您每分钟只 进行批量插入-在这种情况下，这是受控环境。
使用index.merge.policy.merge_factor，将其设置为较高的值可减少ES在后台执行的段合并数量，然后在批量操作恢复正常行为后恢复为默认值。30通常建议将插入设置为，默认值为10。
602392714
清零编程群