疲劳是最舒适的枕头,努力工作吧。

es client节点每20分钟cpu抖动一下,导致上游超时,es版本是6.2.4

Elasticsearch | 作者 yushiweibill | 发布于2022年07月22日 | 阅读数:403

现象是每过20分钟,es请求rt就飙升一下,然后观察es集群,发现clien头节点每20分钟cpu会飙升一下,网上说可能和es xpack认证有关系,不知道怎么解决,麻烦大神帮忙解答下,谢谢!
现象是每过20分钟,es请求rt就飙升一下,然后观察es集群,发现clien头节点每20分钟cpu会飙升一下,网上说可能和es xpack认证有关系,不知道怎么解决,麻烦大神帮忙解答下,谢谢
已邀请:

Charele

赞同来自: yushiweibill

clien头节点每20分钟cpu会飙升一下
你这个“clien头节点”是指什么?
 
在cpu升高的时候,你可以用hotThread API看下线程是哪些在作用,贴下结果

Charele

赞同来自: yushiweibill

谈下个人看法:
refresh缺省是1秒执行一次
(就是说,1秒它会检查一次,看看索引有没有变化,如果有,它就会在每个分片上执行实际的refresh动作,生成新段)
 
  1 实际上会有些不一样,
111.png

 
看下其中两个条件:
蓝色是说当searchIdle的时候,
红色的是说你没有显式设置refresh的时候
(注意:缺省的1秒和你显式地去设置为1秒,是有区别的)
 
就算你执行了插入或更新操作,
它是有可能不会实际执行refresh的,只是把它存下来,
等待下次执行。(因为这个时候没人查索引,那么急着refresh没实际意义)
 
else 黄色表示要执行refresh(当然,是不是实际执行了,得看后面的判断)
所以ES在这里做了点优化,你说的现像也许没有那么严重
 
2 如果是低版本的ES,可能没有这个判断,
如果实时性要求不是那么,或者你在做load数据时,
可以refresh设长一点,3秒或10秒,或者禁止自动refresh
 

liujiacheng

赞同来自:

是不是GC导致的?

Charele

赞同来自:

1 看你信息,好像是在hash值,
你可以指定一个迭代次数小一点的Blowfish算法试下
 
xpack.security.authc.password_hashing.algorithm: bcrypt4
 
 
2 “网上的一些说法是es默认20分钟的xpack认证,缓存清空导致的”,
你也可以把这个token有效时长改大,至少不会这么频繁了

Charele

赞同来自:

感觉你上面那些话有道理,看了下代码。
分析一下你说的(基于ES8.2,也许低版本逻辑不一样,那bypass)
 
 
111.png

a 第一次update时,没有版本值(就是你说的缓存值),不会执行上面的
但会设置版本值
 
b 第二次update时,有版本值。会走这里
(1处黄色的,在update时肯定是true)
由于初始没有track位置信息,所以它会执行3处绿色的,设置一下track,
且主动触发一下内部refresh,紫色的
 
c 第三次update,
要分两种情况:
c1 第三次update前,有后台refresh发生过,
如果有后台refresh发生了,它会清除版本值 ,取不到版本值,所以不执行这里
 
c2 第三次update前,没有后台refresh发生过,
有版本值存在,所以执行这里,
因为上面已经设置了track,所以版本值里面有loc信息了,
所以走蓝色里面的,从log里面取数据就返回了,不会走到下面去了。
 
d 后面的第4次,第5次,,,update的执行,跟第3次是一样的。
 
所以你说的“主动触发refresh”仅仅只会执行一次,
我想不会出现你说的“这个会导致段增多”
 
 
 
 

要回复问题请先登录注册