Elasticsearch 出现 “429 rejected” 报错，怎么办？

1、引言

本系列文章介绍如何修复 Elasticsearch 集群的常见错误和问题。

这是系列文章的第五篇，主要探讨：Elasticsearch 出现 “429 reject 报错"，怎么办？

第一篇：Elasticsearch 磁盘使用率超过警戒水位线，怎么办？

第二篇：Elasitcsearch CPU 使用率突然飙升，怎么办？

第三篇：Elasticsearch 断路器报错，怎么办？

第四篇：Elasticsearch JVM 堆内存使用率飙升，怎么办？

2、常见的“429拒绝请求”错误

线上报错描述：

问题 1：“我们目前节点还是有很多 reject 429，用了一些方法，比如增加Thread_pool 好像效果不大，还会load增高。还是很多堆积和reject。现在想咨询一下，是否只能增加服务器节点，如果增加，应该怎么样评估，更加合理？因为没有多余机器来做压测，只能根据现有的监控数据评估，能不能给些建议，重点来看哪些参数？”

问题2：“es集群，写入经常reject 429，同时经常会出现 request retries exceeded max retry timeout [60000] 超时的情况。想问下，一般都有什么办法缓解这种问题。现在数据堆积kafka的很多，消费不过来，会丢失一部分数据。目前节点的thread_pool 是200，调高了部分节点到300，效果不是特别明显。”

如上两个问题都和 “reject 429” 错误紧密结合在一起。

3、“429 拒绝请求”原因解读

当 Elasticsearch 拒绝请求时，它会停止操作并返回带有 429 响应码的错误。被拒绝的请求通常由以下原因引起：

• 原因1：线程池资源耗尽。

检索线程池或者写入线程池资源耗尽，会出现：TOO_MANY_REQUESTS 错误消息。

• 原因2：断路器报错，也就是内存出现熔断现象。

• 原因3：超过限制的写入压力。

主要原因在于：将文档写入到 Elasticsearch 会以内存和 CPU 负载的形式导致系统负载升高。如果在存在过多频繁的写入操作，集群可能会变得饱和。这可能会对其他操作产生不利影响，例如搜索、集群协调和后台处理。

为了防止这些问题，Elasticsearch 在内部监控索引负载。当负载超过一定限度时，新的请求将会被拒绝。

写入请求最高内存上限 indexing_pressure.memory.limit 设置为堆内存的 10%。

我以 elasticsearch 8.0 单节点环境作为测试：

上截图 limit_in_bytes = 410202931 Byte = 391.2 MB，约等于 4GB 堆内存的 10%。

此外， “429 拒绝错误“可以作为衡量是否达到性能瓶颈的依据——做压力测试时可以不断增加并发，观察CPU使用率、磁盘IO使用率，当 Elasticsearch 返回 429 错误码时，可以认为 Elastic 集群达到负载极限。

4、如何检查 “429 拒绝请求”错误？

要检查每个线程池的拒绝任务数，可以使用如下的 cat 线程池 API。被拒绝任务与已完成任务的比例很高，尤其是在搜索和写入线程池中，这意味着 Elasticsearch 会定期拒绝请求。

我模拟多进程数百+批量 wildcard 查询和 bulk 批量写入方式将 CPU 和 堆内存尽可能打满，基本如下图所示：

执行如下命令，可以查看 rejected 拒绝情况。

GET /_cat/thread_pool?v=true&h=id,name,active,rejected,completed

即便上CPU被打满，依然没有出现 reject，需要更多并发请求压测

5、如何阻止或提前预防“429 拒绝请求”错误？

方案一：修复高CPU和高内存使用率问题。

如果 Elasticsearch 经常出现拒绝请求，则你所管理集群可能具有高 CPU 使用率或高 JVM 内存压力。

推荐阅读：

Elasitcsearch CPU 使用率突然飙升，怎么办？

Elasticsearch JVM 堆内存使用率飙升，怎么办？

方案二：避免出现内存熔断。

如果你的业务环境经常触发断路器错误或者内存熔断，请参阅断路器错误以获取有关诊断和预防错误的提示。

推荐阅读：Elasticsearch 断路器报错了，怎么办？

5、小结

做好监控和核心指标的预警工作，“防患于未然”。

你的实际业务场景有没有遇到类似问题，你是怎么解决和避免的？欢迎留言讨论。

更短时间更快习得更多干货！

和全球近 1600+ Elastic 爱好者一起精进！