根据_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会变好，想问下上面这个查询什么原理，造成这么大的读磁盘
机器配置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会变好，想问下上面这个查询什么原理，造成这么大的读磁盘
3 个回复
medcl - 今晚打老虎。
赞同来自: laoyang360
JiangJibo - 喊我雷锋
赞同来自:
pony_maggie - 公众号:犀牛饲养员的技术笔记
赞同来自:
1. 节点的总内存是多少，ES JVM配置了多少（标准的建议是把50%的内存给elasticsearch，剩下的50%也不会没有用处的，Lucene会很快吞噬剩下的这部分内存用于文件缓存）
2. 关注下query cache，这部分是用的堆内存，node/stat看下缓存占用，命中率等