网站建设人员配置,学电子商务有前途吗,python免费看电影的应用,软件商城电脑版下载记elasticsearch CPU负载100%问题 环境#xff1a;问题表现#xff1a;初步排查#xff1a;日志查询hot_thread 深入查询当前elasticsearch正在运行的Task查看Task详情解决问题对导致问题的原因的几个猜测问题复现#xff1a;导致问题的原因。json导入规则问题json导入规则… 记elasticsearch CPU负载100%问题 环境问题表现初步排查日志查询hot_thread 深入查询当前elasticsearch正在运行的Task查看Task详情解决问题对导致问题的原因的几个猜测问题复现导致问题的原因。json导入规则问题json导入规则问题解决中英文非ndjson格式数据上传问题中英文非ndjson格式数据问题解决 reference附录elasticsearchindex基本数据格式elasticsearch的analyzer 环境
单台2核4G的阿里云ecs部署单node的elasticsearchkibana。 测试环境刚上手elasticsearch学习用。本来是构建LLM的RAG系统的结果突然来了个100%CPU占用而且居高不下没办法干回老本行运维工程师启动
问题表现
在上午9.50分开始阿里云控制台可看见ecs的CPU从原本的4%占用左右快速飙到了100%并且长时间居高不下。
初步排查
日志
先看日志通过正则筛选elasticsearch.log中9.40-50分中的所有日志。
cd /var/log/elasticsearch
grep ^\[2024-01-31T09:[4-5] elasticsearch.log可以见到日志中有多段如下日志。其主要内容是Grok在对非结构化数据的正则匹配提取信息。而我从未进行过任何的Grok配置与操作。
查询hot_thread
elasticsearch的API中提供了一个查询当前node中资源占用量大的进程的接口。
GET /_nodes/hot_threads查询结果如下可以详细看到这些进程大部分都在进行正则匹配的工作和之前log中看到的一致。并且下方textstructure.structurefinder这个类即是Gork提取非结构化数据信息的类。
深入
查询当前elasticsearch正在运行的Task
通过API可以详细的查找到当前elasticsearch中正在运行的Task的详细内容。
GET /_cat/tasks?vdetailedtrue可以看到其中存在几个text_structure/findstructure的Task和hot_thread中看到的一致并且启动的时间也基本对应CPU升高的时间。
查看Task详情
通过通配符匹配查询这几个Task的详细信息。
GET /_tasks?detailedtrueactions*/text_structure/findstructure可以看到这几个任务的Type为Transport的类型。 从elasticsearch文档中可以看到Transport类型的任务的主要功能是 到这卡住了 transport类型一般的node之间通信的任务但是我是单node
所以我又找到发现我创建的index默认replica1即分片有一个备份而我是单node备份必须是存储在不同的node上导致备份分片一直不能被分配使得index状态处于yellow状态。
但是不确定这个和我当前的任务是否有关系
好了更新的replica但是问题还在现在index都是绿的了
解决问题
重启解决问题重启后所有的structurefinder进程都消失了 OK不用查了es崩了直接重启了。 在此之前还检查了是否是pipeline的问题但是pipeline都没有在使用。 OK重启了之前看到的structurefinder进程都没有了CPU也降下来。 问题虽然解决但是还是不知道为啥。
对导致问题的原因的几个猜测
几个怀疑看看之后我会不会再复现这个问题
多副本问题导致有副本切片一直没有合适的node分配但是不应该占用CPU啊因为导入的时候使用了默认的pipeline导致对导入的数据进行的非结构化分析和提取导致CPU占用高。但是不应该一直持续存在吧中间有玩了一次kibanaUI界面添加集成直接上传了一个json格式的问题不知道是不是这个问题。返回的结果是失败说需要结构化的数据并且是请求超时我认为这个最有可能。
问题复现
因为对于原因3最为怀疑而且确实时间点也对的上就是上传完之后开始CPU飙升同时上传失败的返回也确实怪怪的。所以重新上传。 json内容值为中文的unicode
重新上传之后仍然是以下的问题。 再次查看发现CPU又100%负载了。并且之前的structurefinder进程又出现
导致问题的原因。
那么基本可以确定就是在解析上传的文件时通过grok尝试解析失败后却没有关闭进程。从而导致CPU不断被占用。 而上图UI界面中返回的Request:time out 基本可以确定是structurefinder在尝试解析json内容时花费的时间太久从而返回的time out。
json导入规则问题
只是问题是为什么我的json文件会解析这么久并且仍然没有结束。上午的解析进程最长的一个运行了近6个消失但是仍然没有结果。 我的json文件是python直接dump出来的并且json格式校验也没有问题。
json导入规则问题解决
因为es要求的上传的json格式为ndjson。即换行符分割的json每一行都是一个完整的json对象。 而我上传的只是传统json格式导致无法解析。
中英文非ndjson格式数据上传问题
仍然还有一个问题没有解决 当一个英文的非ndjson格式的json被上传时会报错非ndjson格式。直接返回没有timeout 当一个unicode中文的非ndjson的json被上传时会直接无限等待导致CPU100%占用返回timeout。并且后台持续存在一个task在进行解析并且不结束占用CPU100%
中英文非ndjson格式数据问题解决
我又去看了一遍hot_thread可以看到这里的进程中主要的函数是log Text Structure Finder。即对log的格式解析。 在上传文件时es有明确可以上传带标准时间戳格式的log问题。 由此推测当unicode的json被上传后不符合ndjson但是不知为何被当作了log去解析而又并非log导致了一些奇奇怪怪的bug导致解析的进程无限等待并没有进入任何一个错误返回。从而导致timeout同时解析的进程卡死CPU占用100% 而英文可能更方便所以并没有触发这个bug。 reference
https://www.elastic.co/guide/en/elasticsearch/reference/8.12/high-cpu-usage.html#high-cpu-usage 聊聊 Elasticsearch 中的任务管理机制 red-yellow-cluster-status 你所不知道的ndJSON序列化与管道流 附录
elasticsearchindex基本数据格式
{settings: {analysis: {analyzer: {default: {type: simple //整个index使用的analyzer},default_search: {type: whitespace //默认对这个index的搜索关键字使用的analyzer 也就是分词tokenizer去停用词等操作。}}},number_of_shards: 3,// 分片存储将数据分块存储在集群中搜索时将请求发向对应的分片类似hadoop也能增加搜索时的并行性number_of_replicas: 1 // 副本即整个集群上不同机器中存储副本。默认为1即有一个副本但是副本必须存在不同的机器上单node多余的副本会无法被alloc导致node状态为yellow},mappings: {properties: {title: {type: text,analyzer: ik_smart //对单个field定义分析器仅对该field生效。},field1: {type: keyword},field2: {type: date}}}
}elasticsearch的analyzer
analyzer主要做分词去除停用词等数据预处理的工作。 默认有一个standardwhitespacesimple等 分别对应不同的分词方法。 但是都不支持中文分词所以只用中文文本数据一定要使用ik分词的插件否则分词效果差会非常影响搜索的准确性。 具体安装配置IK分词器的方法详见 ElasticSearch中文分词
