es搜索速度取决于data节点,和master节点没关系。
集群有4个节点:111(md),211(md),166(d),61(m)。括号里是节点可扮演的角色, m表示master, d表示data。
data目录都是指向系统盘,而系统盘都是ssd。
这个配置搜索速度很快, 1s内就响应了。
后来数据越来越多,有的节点磁盘爆满了,占100%,导致很多分片shard unassigned了。
为了解决磁盘满的问题,就把211和166的data挂载到了61的200g的高效云盘。然后也把61添加进来作为data节点,data的存储位置也是高效云盘。
即节点变为: 111(md),211(md),166(d),61(md)
这样磁盘占用率降下来了,但是搜索速度突然很慢了,可能7、8秒甚至更迟才响应。
后来111,211,166分别购买了100g的ssd盘, data目录均移到了新购买的ssd盘。然后再弃用61节点。
搜索速度立马又飞快起来了。
另外这也说明搜索速度和磁盘关系很大,和内存关系不大。
因为211,166均是4核8g的系统,而top查看es数据在每个节点均占用了20多g的内存。
*********
es搜索速度和cpu内存的配置也有关系,但是要求并不是很高,4核8g的配置就够用了,只要保证cpu没被占满即可。
之前的配置是: 111(md),211(md),166(d),61(md),其中111是16核32g的机器。
配置改为211(md),166(d),35(md)(这3个都是4核8g的机器)后,搜索速度一点没变慢。
这个配置在第二天突然变慢甚至无响应了。
最后查出来是因为35的机器放了rds, mysql查询未对where语句的字段建index,导致几乎占满了cpu。
补建索引后,cpu降下来,es的搜索速度又飞快了。