导读
Wrapped by: java.io.IOException: Request POST https://xxx/_search?search_type=xxx HTTP/1.1 yielded text/plain;charset=ISO-8859-1, should be json: HTTP/1.1 429 Too Many Requests
报错分析
如何看懂异常日志呢？
- 先知道异常日志的输出规则。
- 异常名，细节信息，路径 的概念如下图。（参考：https://www.lmlphp.com/user/58062/article/item/671925/）
 - 异常名+细节信息以先进后出（FILO）的顺序打印，即：打印内容最下方的异常最早被抛出，逐渐导致上方异常被抛出。
- 路径以先进先出（FIFO）的顺序打印，即：位于打印内容最上方的位置最早被该异常经过，逐层向外抛出。
- tips：这也是为什么叫异常栈了，栈就是先进后出（FILO）
报错的猜想
- 猜想一：调用es的search api，入参有问题，因为看到关于json的报错。
- 猜想二：429 Too Many Requests 导致。
生产情况分析
- 偶发产生这个报错
- 产生这个报错的入参不固定
- 入参再次请求没有产生报错
- 报错时 CPU 和 内存 没有告警
我个人认为合理的猜想
- 根据异常日志的输出规则，json异常是在最先输出，再结合生产情况的分析，我更倾向 429 是真实报错原因，json的异常是返回结果时，es返回的不是json串，所以json解析报错。
429报错怎么产生的？
查找资料
百度
elastic中文社区
- https://elasticsearch.cn/question/8753
- https://elasticsearch.cn/question/2632
书籍
- 书名：Elasticsearch 源码解析与优化实战
github
- https://github.com/elastic/elasticsearch
关键资料总结
bulk
- bulk：es 批量增删改操作（特殊情况：index/delete操作转变成了只包含一条文档的bulk请求）
高IO (IO密集型)
- 频繁写入操作会导致高IO，占内存和磁盘，IO密集型建议使用脚本语言进行编码，比如python，相对编码简单，编码效率快。
高CPU(CPU密集型)
- 频繁查询操作会导致高CPU，占CPU，CPU密集型建议使用编译型语言进行编码，比如C、C++、Java和C#
es接收请求队列
- 每个节点都有一个线程池队列，可以容纳若干个请求，具体取决于您使用的 Elasticsearch 版本。队列已满时，将拒绝新请求。
es使用场景
- “tagline” : “You Know, for Search”
我个人分析429产生的原因
- 当es接到bulk请求后，放入线程池处理请求，线程池满后会放入队列，队列满了，会拒绝新的请求，产生报错 429 Too Many Requests。
- 一味的调用search接口，没有bulk操作，只会把CPU打满，也不会报429，因为search是CPU密集型操作，而且ES本身就是为了查询分析设计的。
- 但是有大量bulk操作，把队列打满，偶尔有个search查询，该查询也会返回429报错。
429问题的进一步排查
- 分析下 产生429报错的时间段，是不是有大量的 bulk操作。
考虑对ES的优化
ES的优化
- 参考文章：https://blog.csdn.net/wmj2004/article/details/80804411
- elasticsearch.yml 中增加如下设置
indices.memory.index_buffer_size: 20%
indices.memory.min_index_buffer_size: 96mb
# Search pool 设置 search 的线程数和队列数
thread_pool.search.size: 5
thread_pool.search.queue_size: 100
# 这个参数慎用！强制修改cpu核数，以突破写线程数限制
# processors: 16
# Bulk pool 设置 bulk 的线程数和队列数
#thread_pool.bulk.size: 16
thread_pool.bulk.queue_size: 300
# Index pool 设置 Index 的线程数和队列数
#thread_pool.index.size: 16
thread_pool.index.queue_size: 300
# 设置 filedata cache 大小
indices.fielddata.cache.size: 40%
# 设置节点之间的故障检测配置
discovery.zen.fd.ping_timeout: 120s
discovery.zen.fd.ping_retries: 6
discovery.zen.fd.ping_interval: 30s
PUT /_template/elk
{
"order": 6,
"template": "logstash-*", #这里配置模板匹配的Index名称
"settings": {
"number_of_replicas" : 0, #副本数为0,需要查询性能高可以设置为1
"number_of_shards" : 6, #分片数为6, 副本为1时可以设置成5
"refresh_interval": "30s",
"index.translog.durability": "async",
"index.translog.sync_interval": "30s"
}
}
最后聊两句
- 金发姑娘原则，对于项目的技术选型时，没有最好的技术，只有最适合的技术。
- 里面有很多我个人的猜测和思考，可能有不正确的地方，希望各位大佬多多指教评论。
|
