由VIP漂移引发的算法异常问题调查和解决

最近工作中的一个问题,耗时一个月之久终于观察完毕且顺遂解决,马上感慨万千。耗时之久和预期解决时间和环境搭建以及日志不合理等等有关,固然这个并非此文的重点。
之所以在良久以后的今天又最先写文,主要是这个问题观察的历程值得铭刻。详细情况如下文述。

一、问题发现历程
数据告警服务提醒相关剖析效果缺失,经开端观察,发现剖析服务在挪用对应的NLP算法服务时泛起大量Failed,遂查看算法日志,确实存在错误信息。

二、问题观察和解决
1.定位问题
1) 反馈给算法相关开发同砚:他们以为可能是该算法遇到了长文本数据(跨越3000字),由于剖析时间超长,导致后续算法请求时泛起壅闭而导致failed。
2) 凭据开发的反馈,最先定位是否存在这样的长文本数据:通过剖析日志和数据库查询确认后,并没有剖析长文本数据,且泛起异常时的文本数据均为短文本(小于200)。
3) 深入观察:该算法部署了多个节点,泛起异常时,多个节点均泛起了异常,因此可能是算法自己遇到了某个瓶颈问题。经确认,该算法使用了统一台GPU服务器上的tf-serveing服务。
4) 确认GPU服务器是否发生了异常情况:经确认,该服务器举行过VIP漂移操作。
5) 问题是否可以复现:测试环境中,对GPU服务器举行vip漂移操作,发现错误征象泛起,问题可复现。
因此,问题的原由是GPU服务器举行了VIP漂移操作,导致算法泛起异常。

2.观察问题
1) 领会vip原理,开端领会后,以为可能是我们的算法缺少超时设置,因此算法中新增超时设置后,再次举行测试
备注:keepalived可以将多个无状态的单点通过虚拟IP(以下称为VIP)漂移的方式搭建成一个高可用服务,常用组合好比 keepalived+nginx,lvs,haproxy和memcached等。
它的实现基础是VRRP协议,包罗焦点的MASTER竞选机制都是在VRRP协议所约定的。
2)一轮测试发现:问题仍然存在,修复失败,且无新增日志。于是,我们要求增添日志信息,并以Debug方式启动算法,举行二轮测试。
3)二轮测试发现:问题仍然存在,泛起新的错误日志,错误信息为:Connect error: No route to host(errno:113)。
百度一番,都说是server端的防火墙设置了过滤规则;然则,Server端并没有,怎么办?
Server端抓包:
经抓包发现,GPU服务器完成vip漂移需要耗时4s左右,然而,算法在漂移最先的2s内发送了近20次请求之后无请求。
问题的泉源(可能):Server端vip漂移未完成时,算法却发送了大量请求导致Server端的tcp连接池满,后续server端不再为其他请求分配资源。

Golang从合并链表聊递归

3.解决问题
1)凭据观察的缘故原由,修复方式是:sever端在举行vip漂移完成前,只管削减算法的请求次数,因此我们对该算法举行了超时重试次数的设置和请求距离的设置(可设置)。
2)算法修复后经测试,问题解决。

三、总结
1)合理且主要的日志输出对于问题的定位和观察非常主要
2)涉及HTTP请求的问题观察时,服务端抓包有需要
3)Linux 的errno113问题并不一定是设置了防火墙导致的

备注:
(一)vip环境:用来给K8s做三节点高可用,被K8s的kubeproxy的ipvs方式转发到详细pod,四层转发,tcp协议(NAT模式)
(二)Linux errono下令

由VIP漂移引发的算法异常问题调查和解决

 

原创文章,作者:870t新闻网,如若转载,请注明出处:https://www.870t.com/archives/20428.html