高峰只对攀登它而不是仰望它的人来说才有真正意义。

term _id 查询导致磁盘读非常高

Elasticsearch | 作者 xiaowoniu | 发布于2020年11月21日 | 阅读数:169

根据_id查询没有用GET,而是通过term去查询,结果导致磁盘非常高
 机器配置3台 16C/32G jvm16G

业务是按着月份分的索引,分别为index-2020.09, index-2020.10,index-2020.11
每个索引12个主分片
每个索引的大小都是100G,共300G


GET index-*/_search
{
"query": {
"term": {
"_id": {
"value": "2ec1d06bc8734447a0c71bc09e2a1845_592"
}
}
}
}
_id是自动生成的id

QPS非常低,只有2个左右,但是造成了磁盘的大量的读,读在150MB左右,磁盘负载很高

目前猜想,换成get会变好,想问下上面这个查询什么原理,造成这么大的读磁盘
 
111.png
已邀请:

JiangJibo - 喊我雷锋

赞同来自:

你的索引都是hot的,也就是没有配置生命周期?可能是因为QPS很低,大部分数据都没有加载到内存,当你查询时触发缺页异常,把磁盘的索引文件加载到缓存,前几次查询应该会有很多这种情况,后面应该会好点吧,感觉是这个原理

pony_maggie - 公众号:犀牛饲养员的技术笔记

赞同来自:

磁盘IO高大概率和缓存有关,有几个分析思路:
1. 节点的总内存是多少,ES JVM配置了多少(标准的建议是把50%的内存给elasticsearch,剩下的50%也不会没有用处的,Lucene会很快吞噬剩下的这部分内存用于文件缓存)
 
2. 关注下query cache,这部分是用的堆内存,node/stat看下缓存占用,命中率等

medcl - 今晚打老虎。

赞同来自:

首先你要关注的是这个指标是瞬间还是持续的,如果是瞬间那有什么关系, es读取文件是Mmap映射然后磁盘顺序读取,速度自然快, 并且越快越好,如果是持续的指标就不正常了,一般不可能会这么高,要再具体分析是什么原因。

要回复问题请先登录注册