AWS Elasticsearch 索引内存使用问题

Question

问题：数据索引期间非常频繁的“403 请求因请求过多而受到限制”错误，这应该是memory usage 问题。

基础设施：

• Elasticsearch 版本：7.8
• t3.small.elasticsearch 实例（2 个 vCPU，2 GB 内存）
• 默认设置
• 单域，1 个节点，每个索引 1 个分片，无副本

有 3 个索引可搜索数据。其中两个有大约 100 万个文档（500-600 MB），一个有 25k（~20 MB）。索引不是很简单（有历史跟踪），所以我一直在用true、wait_for 值测试refresh，或者在需要时单独调用它。该过程使用搜索和批量查询（一直在尝试 500、1000 的大小）。 AWS 端应该有 10MB 的限制，所以这些是安全的。我还测试了在请求之间添加 0.5/1 秒的延迟，但这些摆弄都没有任何明显的好处。

该项目目前正在开发中，因此除了索引过程本身之外基本上没有流量。最小的索引通常需要每 24 小时更新一次，较大的索引需要每周更新一次。升级基础设施并不是我们想做的事情，因为索引太脆弱了。即使只连续两次更新 25k 数据索引也会因上述错误而失败。任何想法如何合理地解决这个问题？

2020 年 11 月 10 日更新

在过去的日志中进行了一些挖掘，发现我们曾经有429circuit_breaking_exception-s（而不是当前的403），原因在于[parent] Data too large, data for [<http_request>] would be [1017018726/969.9mb], which is larger than the limit of [1011774259/964.9mb], real usage: [1016820856/969.7mb], new bytes reserved: [197870/193.2kb], usages [request=0/0b, fielddata=0/0b, in_flight_requests=197870/193.2kb, accounting=4309694/4.1mb]。使用 cluster stats API 跟踪索引期间的内存使用情况，但没有发现任何可以确定为问题的直接原因的内容。

Answer 1

最终根据我能找到的信息创建了一个解决方案。经过一番搜索和阅读后，似乎在遇到错误时再次尝试是 Elasticsearch 的有效方法。 For example:

请务必注意 TOO_MANY_REQUESTS (429) 响应代码 （Java客户端的EsRejectedExecutionException），就是这样 Elasticsearch 告诉你它跟不上当前的 索引率。发生这种情况时，您应该先暂停索引 再试一次，最好使用随机指数退避。

The same guide 也有关于刷新的有用信息：

包括使更改对搜索可见的操作 - 称为刷新 - 代价高昂，并且经常在有的时候调用它 正在进行的索引活动可能会影响索引速度。

默认情况下，Elasticsearch 每秒定期刷新索引， 但仅限于已收到一个或多个搜索请求的索引 最后 30 秒。

在我的用例中，索引是一个不经常发生的单一线性过程，所以这就是我所做的：

• Disabled automatic refreshes（index.refresh_interval设置为-1）
• 在需要的时间和地点使用refresh API 和refresh parameter（带有true 值）
• 当遇到“403 请求因请求过多而受到限制”错误时，程序将继续每 15 秒尝试一次，直到成功或达到时间限制（当前为 60 秒）。如果需要，将调整数字/功能，但到目前为止效果很好。

这样索引仍然很快，但在需要时会减慢以提供更好的稳定性。