yabo2021最新版|靠谱的赌博十大网站





技术人生系列——追踪图数据库中“突然隐身”的通信连接

日期:2021-02-23

图数据库作为新兴的数据库技术热点,正在广泛的被各大银行客户采用。作为NoSQL数据库中最为突出的代表,图数据库对目前各种比较火热的精准营销业务场景、风控业务场景、客户图谱场景都能提供强大的底层支持。yabo2021最新版大数据产品团队作为国内银行业接触图数据库较早的技术团队,为各大客户持续提供平台层面的技术支持能力。

 

最近,我们在客户现场的图数据库生产集群中遇到了一个罕见的通讯故障:数据库的导入组件和内部组件的通信通道会不定时丢失,且再也无法建立。经过现场反复协调排查和远程持续分析排查,并联合了yabo2021最新版工程师和美国原厂的核心技术力量,终于分析出引发故障的系统原因并最终排除了故障,整个过程历经不少波折,真相大白水落石出时,大家都恍然大悟,原来是这样简单的原因——虽然答案和解决方案很简单,但是在分析过程中,由于大数据复杂的技术架构,需要抽丝剥茧,逐个分析可能因素,所以相对于最终的结果,这样的分析过程更值得记录,借本期技术人生系列文章,分享给大家。

 

 

 

一、故障描述

 

TG图数据库集群状态gadmin status均为正常工作状态,m1、m2、m3节点间连接状态均为正常,且TG所使用端口无被占用情况。在跑生产批量日更脚本中加载数据部分时,发现加载任务有一定几率卡住在读取文件步骤,且卡住后未产生报错日志和加载任务日志。经TG的Abort命令打断当前加载任务后重新运行多次该加载任务,故障依旧;gadmin start命令重启集群后,可成功运行该加载任务;重启后仍有一定几率重新发生此故障。

 

简单来说,在无人干预的情况下,原来正常的数据导入进程会hang死。重启后正常一段时间后,又会继续hang死,且图数据库层面通讯的两端组件都没有收到报错。

 

图片

 

通过上图,我们可以了解到,TigerGraph图数据库导入的基本原理:

 

1、每个节点admin组件会有一个线程定时轮询集群中每个节点的8500端口,尝试建立TCP连接。

 

2、当某个节点,如m1节点开启导入任务时,会开启restpp-loader进程,监听本地的8500端口,这时自然会和admin的线程建立连接。

 

3、通过建立好的tcp连接进行数据通信,由本地的restpp-loader读取文件,数据转换,传送至admin和其他组件,从而进行下游的导入任务。

 

 

二、排查过程

 

1.初步排查定位原因

我们首先针对TigerGraph版本,License,Schema脚本和loading脚本、数据源格式及生产机器内存硬盘资源进行了一一检查,均无发现异常。基本可以确定原有的流程是没有逻辑上的问题。

 

紧接着,我们对图数据库产品底层组件一一进行了故障排查。首先是对TigerGraph的Kafka、Nginx、GPE、GSE、GSQL、ZooKeeper、DICT、TS3、Restpp等组件的检查,经检查发现产品各组件均正常运行,日志文件均无报错情况。

 

经采用小批量数据进行测试并进行后台日志监控,我们发现一个特殊的现象:集群主节点m1不能接收到加载任务,而m2、m3可以接收到,那是否可以说明这其实是一个节点通讯的问题?但是我们紧接着分别对m1、m2、m3进行多次的测试,故障依然存在。这说明不光是 m1 主节点无法和其他节点通信,其他节点之间也会不定时无法建立连接。随着对数据流的逐个环节的分析,发现是RESTPP_LOADER所在的节点无法接收到本节点所发的请求,如下图所示,我们初步定位到了故障点:restpp-loader 尝试去与8500端口建立连接的线程出现了异常。

图片

 

 

2.尝试排除环境中其他软件的干扰

 

首先我们可以判断TigerGraph本身是没有问题的,因为在研发环境一直都是正常运行的。那么就需要判断是生产环境中安装的其他软件对TigerGraph造成了干扰,还是linux系统环境的不同导致了故障的发生。

 

遂在生产环境装有conductor、ctm等软件的其他节点,以及未安装上述软件但系统环境大致相同的两个节点,分别成功安装了TigerGraph单节点企业版。经测试,发现安装有conductor、ctm等软件的节点上的TigerGraph复现了生产环境三节点集群的数据加载故障,而未安装上述软件的节点可正常运行所有任务,无故障产生。经行内老师协调,临时关闭了生产节点的conductor和ctm服务,但故障依然存在,且故障依然为GSE与RESTPP组件通信受阻导致。

 

如下图显示,简单来说,在有其他软件的环境会出现故障,在“干净”的环境中正常运行,关掉其他软件依然有故障复现。那么真相直接指向唯一的一个方向:由于安装其他软件,修改了某项系统配置,引发了这个故障。

图片

 

3.设置监控脚本进行监控

 

问题分析到这里,我们再次回过头去分析哪些系统配置可能影响端口的情况。

 

首先是看系统资源限制,发现配置都比较正常:

图片

 

接下来分成两个方向进行排查:

 

◆ 通过gdb在产品层面打断点去分析

这个方向的考虑是希望在美国原厂的支持下,对TigerGraph图数据库进行调试,在导入组件内部通过打断点的方式,发现组件层面的报错。之前已经分析过了,在产品提供的通用日志中并没有提供报错信息,那么我们本质上是去提取debug级别的日志。

 

令我们困惑的一点是,在debug日志中只能看到某一次程序从线程池中取得线程,并去建立连接,并且建立了连接!但是这个连接从此就消失了,并且从系统的nestat无法找到?!这是让我们百思不得其解的一点。

 

程序认为连接已经建立,系统中却找不到建立的连接,那么这个连接去哪里了?

 

 

◆ 通过shell脚本在系统层去监控进程和网络情况

既然从产品层面无法获得更多信息,我们把思路转向系统层面,通过监控系统的进程情况和网络情况,来定位到故障发生的瞬间,到底发生了什么。

图片

图片

 

4.分析监控日志最终发现原因 

 

如果您能有耐心看到这里,想必也能或多或少体会到这个问题的诡异程度。已经可以确认就是端口之间通讯的问题,但是又找不到这个“隐身”的连接到底去哪了?

 

在系统运行一晚后,我们分析了监控日志,我们发现在某一个时刻连接自己8500端口的线程突然消失了。

图片

 

我突然联想到之前查到的一个资料:因为TigerGraph底层用了zmq进行通信,我在社区中看到一个人在2013年提交了一个issue,说他发现在大并发的情况下,他写的单机程序会时不时的hang住,建议zmq修复这个bug。他遇到的问题和我们很像,但是这个issue没有被fix,而是被关闭了,说明zmq的社区管理判断他提的并不是一个真实的bug。

图片

 

但是在他的描述中出现了self connection ,这个词就像一道闪电,照亮了整个黑暗。我再次联系美国开发,他也立马反应过来,去查看关键的系统配置项,果然真相大白,我们苦苦追寻的配置项就是下图中的:

正常的配置应该是如下:

图片

 

该配置项是linux为了区分服务端程序可用端口和客户端可用随机端口而设置的,就是为了防止端口冲突。在这个故障中,TigerGraph所在集群的默认系统配置中

/proc/sys/net/ipv4/ip_local_port_range

的32768  60999被修改为1025  65535。在这个配置修改后,客户端在申请随机端口连接服务端的时候,有一定概率申请到8500端口,从8500端口去与8500端口建立自连接,从而导致TigerGraph组件认为连接建立,而系统却认为服务未建立,进而导致整个导入功能的异常。而重启过后能正常一段时间的原因就是在图数据库进程关闭后,在8500端口隐身的线程连接也会被系统回收。

 

为了保险起见,根据这个原因,我们在多个安装且正常运行TigerGraph的环境中修改了系统配置,并都复现了生产环境的故障。

 

到此为止,我们完全确定了故障的发生原因。

 

 

三、故障修复方案制定与执行

1.修复方案

故障由/proc/sys/net/ipv4/ip_local_port_range的默认配置被修改导致,行内老师协调,将该设置还原系统默认设置,以解决TigerGraph加载故障。

具体步骤如下:

图片

 

2.修复故障

经由行内老师内部自检及评估后,暂未发现该系统设置被修改原因,遂将该设置修改回系统默认设置,TigerGraph再也没有出现该加载故障。

 

 

四、故障总结

1.控制变量快速定位故障根源

在本次故障排除的过程中,我们面对的是一个复杂的分布式系统环境,系统环境本身与其他环境不同,而且在这个环境中还有多个软件的潜在干扰。这个时候需要我们冷静的采用枚举法列出所有可能的故障原因,再通过控制变量法和排除法逐一去除干扰因素。排除一切不可能的因素后,剩下的肯定是正确的答案。

 

2.关键系统配置检查

在定位到系统级别的问题时,应该第一时间检查相关关键配置项。首先,我们需要定时监控维护这些配置项。在这次排除后,我们也无从得知到底是什么原因这个配置项被修改了。这警示我们可能在平时的工作需要关注这个方面。第二是需要了解这些系统参数的含义和配置方法,这就需要我们不断对自己的技术进行提高。

 

3.广泛积累夯实技术基础、深入钻研挖掘技术深度

这次排查问题,我们从图数据库产品本身技术架构,组件功能原理,到linux系统运行机制,考虑了很多技术问题和可能原因,这对我们提出了很大的挑战。所幸这次有美国原厂技术力量并肩作战,最终取得胜利,但是这次问题也鞭策我们平时需要广泛的去学习技术知识,并在自己的技术领域持续深耕,正所谓博观而约取,厚积而薄发。只有这样,在考验来临时,我们才能举重若轻的解决,为客户创造价值。

 

 


锻造凝炼IT服务 助推用户事业发展
地址:北京市西城区百万庄大街11号粮科大厦3层
电话:(010)58523737
传真:(010)58523739