要不要再翻翻文档呢?

ES协调节点每20分钟会出现一次查询响应时间长

Elasticsearch | 作者 wangxinrong | 发布于2020年09月21日 | 阅读数:2439

配置如下:
应用通过域名连接ES,域名指向负载均衡,后端是ES集群的协调节点,作为查询节点。
 
问题现象如下:
1.应用每过一段时间就会出现一波查询超时报错,这个应用对延时要求比较高,设置的是150ms。
2.通过查看日志发现,负载均衡每台后端节点都会很有规律地每20分钟出现一次这种情况。出现问题的时候大部分请求也都是快速返回的,但这个时间点会出现一波超时的响应。
3.每台节点出现问题的时刻不同,但都是有规律的20分钟一次,比如A是03、23、43分出现,B是15、35、55分出现,这样。
4.根据错误请求的doc id去查所在分片,发现分片各不相同,分配在不同的数据节点,所以看起来协调节点本身的可能性较大,和数据节点关系不大。
5.自己跑脚本指向一台查询节点测试,也有每20分钟出现一波超时的情况。但把这台节点从负载均衡中移除,不接入线上请求再测,就没有这种情况。
 
这种现象很奇怪,
如果说和用户请求有关,那么应该出现问题的时间点相同,但实际是每个报错节点的时刻不同,间隔相同。
如果说和系统中某个设置有关,那么不接入线上查询时就没有这个现象,而且我尝试过停掉系统里所有的其他进程没有效果,crontab里也没有内容。
如果说和ES本身有关,那也没听说过有什么操作会这么固定的每20分钟一次。
 
请问有什么好的排查问题的思路吗?
已邀请:

locatelli

赞同来自:

 
- 一般查询超时会联想到GC。查过GC log吗?Old GC的时间点有没有关联性?
- 如果重启协调节点,出现问题的规律是否有变化?
- 会不会有外部产生的周期性拥塞?syslog, /var/log/messages等查过吗

wangxinrong

赞同来自:

gc问题查过,已经优化过,改成g1gc并且调整过参数。现在每次gc时间都在30ms以内。
这是在优化过之后仍然存在的一个问题。现象是正常的查询一般不会超过50ms,最长基本也不会超过80ms。但出现我上面周期性的报错时,超时时间至少是大于150ms的,因为到这个值就已经客户端超时了,所以不能确定具体是用了多少ms。
 
现在的发现是我看了下默认参数
_cluster/settings?include_defaults
_settings?include_defaults
有两个配置的默认值是20m,可能与这个20分钟间隔的报错有关。
xpack.security.authc.token.timeout: 20m
xpack.security.authz.store.roles.index.cache.ttl: 20m
 
另外一个发现是查询节点出现报错的时刻,就是它加入负载均衡,流量开始打进来的时刻,这样的话看起来倒像是刚开始没有缓存,请求进来有一波报错,20分钟后缓存到期,重新缓存时又出现一波报错,当然这个也只是猜测,不知道有人遇到过类似的问题没。

wangxinrong

赞同来自:

已经确认是xpack.security.authc.realms的cache.ttl默认值20m导致
 
_xpack/security/realm/*/_clear_cache 清空缓存就会触发一波报错,把这个值调大就不再有20分钟一波报错的情况。
 
那么这个cache清空后为什么会导致查询耗时这么长,除了调大以外有其他办法能彻底解决吗,目前我调整之后仍然会不定期的有少量报错,或者某个时刻出现一波报错。

要回复问题请先登录注册