配置如下:
应用通过域名连接ES，域名指向负载均衡，后端是ES集群的协调节点，作为查询节点。
问题现象如下:
1.应用每过一段时间就会出现一波查询超时报错，这个应用对延时要求比较高，设置的是150ms。
2.通过查看日志发现，负载均衡每台后端节点都会很有规律地每20分钟出现一次这种情况。出现问题的时候大部分请求也都是快速返回的，但这个时间点会出现一波超时的响应。
3.每台节点出现问题的时刻不同，但都是有规律的20分钟一次，比如A是03、23、43分出现，B是15、35、55分出现，这样。
4.根据错误请求的doc id去查所在分片，发现分片各不相同，分配在不同的数据节点，所以看起来协调节点本身的可能性较大，和数据节点关系不大。
5.自己跑脚本指向一台查询节点测试，也有每20分钟出现一波超时的情况。但把这台节点从负载均衡中移除，不接入线上请求再测，就没有这种情况。
这种现象很奇怪，
如果说和用户请求有关，那么应该出现问题的时间点相同，但实际是每个报错节点的时刻不同，间隔相同。
如果说和系统中某个设置有关，那么不接入线上查询时就没有这个现象，而且我尝试过停掉系统里所有的其他进程没有效果，crontab里也没有内容。
如果说和ES本身有关，那也没听说过有什么操作会这么固定的每20分钟一次。
请问有什么好的排查问题的思路吗？
应用通过域名连接ES，域名指向负载均衡，后端是ES集群的协调节点，作为查询节点。
问题现象如下:
1.应用每过一段时间就会出现一波查询超时报错，这个应用对延时要求比较高，设置的是150ms。
2.通过查看日志发现，负载均衡每台后端节点都会很有规律地每20分钟出现一次这种情况。出现问题的时候大部分请求也都是快速返回的，但这个时间点会出现一波超时的响应。
3.每台节点出现问题的时刻不同，但都是有规律的20分钟一次，比如A是03、23、43分出现，B是15、35、55分出现，这样。
4.根据错误请求的doc id去查所在分片，发现分片各不相同，分配在不同的数据节点，所以看起来协调节点本身的可能性较大，和数据节点关系不大。
5.自己跑脚本指向一台查询节点测试，也有每20分钟出现一波超时的情况。但把这台节点从负载均衡中移除，不接入线上请求再测，就没有这种情况。
这种现象很奇怪，
如果说和用户请求有关，那么应该出现问题的时间点相同，但实际是每个报错节点的时刻不同，间隔相同。
如果说和系统中某个设置有关，那么不接入线上查询时就没有这个现象，而且我尝试过停掉系统里所有的其他进程没有效果，crontab里也没有内容。
如果说和ES本身有关，那也没听说过有什么操作会这么固定的每20分钟一次。
请问有什么好的排查问题的思路吗？
3 个回复
locatelli
赞同来自:
- 一般查询超时会联想到GC。查过GC log吗？Old GC的时间点有没有关联性？
- 如果重启协调节点，出现问题的规律是否有变化？
- 会不会有外部产生的周期性拥塞？syslog, /var/log/messages等查过吗
wangxinrong
赞同来自:
这是在优化过之后仍然存在的一个问题。现象是正常的查询一般不会超过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/realm/*/_clear_cache 清空缓存就会触发一波报错，把这个值调大就不再有20分钟一波报错的情况。
那么这个cache清空后为什么会导致查询耗时这么长，除了调大以外有其他办法能彻底解决吗，目前我调整之后仍然会不定期的有少量报错，或者某个时刻出现一波报错。