玩转GaussDB(DWS)线程管理问题系列（一） --- GaussDB for DWS线程残留定位手段

【背景知识】

DWS产品，基于公有云基础架构和平台的在线数据处理数据库，为用户提供海量数据挖掘和分析服务。主要提供不同行业的在线分析场景。如：增强ETL+实时BI分析、电商、IoT场景。

当前的分布式架构，简单来说，是以多个组件分工负责不同的任务，构成整个集群，以下简单介绍部分组件，后续对各个组件详细介绍：

CN:Coordinatornode,协调节点。客户端连接CN，发送SQL，CN接收解析后发送给所有DN执行，执行完后返回结果给CN，由CN统一返回给客户端。

DN:Data node，数据存储节点，参与“本地数据”运算。

GTM：全局事务管理器，系统中只有一个，采用主备方式，多线程架构。主要用来管理Id和快照信息，保证系统中全局事务的一致性。

由于DWS是分布式架构，所以会涉及到整个集群的各个节点之间的互相通信，建立连接等通信相关功能，对于通信我们也有完善的一套架构方案，此处要知道的是我们通过cn与dn之间建立连接，互相通信，完成整个作业的执行，执行完作业之后，该连接会被回收。

         本文就是介绍曾经某个据点出现过的一个cn进行了进程kill，此时cn进程的连接清理之后，dn有连接的时候，可以使用的分析定位手段。

【视图介绍】

pg_stat_activity：查询作业执行情况。

pg_thread_wait_status:查询节点各个线程执行等待的情况。

【定位手段】针对dn是否有线程残留，可以采用以下方法进行定位。

1、确定是否是dn线程残留，如dn_6015_6016，表为postgres，cn查以下视图：

select count(*) from pgxc_thread_wait_status where node_name='dn_6015_6016' and db_name='postgres' and thread_name='cn_5001' and  tlevel=0;

解释：tlevel = 0代表stream处理层的上层，表示cn和dn之间的连接。

select count(*) from pg_pooler_status where node_name='dn_6015_6016' and database='postgres'

解释：查看此时dn_6015_6016的对应连接数量。此视图只能在cn查询，显示本地cn的pooler模块连接缓存信息。

二者结果不同：第二个语句查询结果大于第一个语句。可以说明有连接残留。

2、若发生线程残留，从pgxc_thread_wait_status 视图中找到dn上残留的线程号（即比pooler视图中多的线程号），ssh 到dn_6015_6016所在机器，登录到dn_6015_6016

select * from pg_stat_activity where pid=?;

解释：用该视图可以查询到client_port，client_port是与当前实例用于TCP连接的后台客户端的端口号。

找到端口号例如：50079 、44101。

3、在当前线程残留dn查看该端口号状态，使用netstat命令，查看对端ip。如下：

Netstat –anop | grep 50079

可以得到类似如下结果：

解释：一个连接由一个五元组唯一确定：协议名(tcp)，本端ip，本端端口号，对端ip，对端端口号，决定，与图中对应。（a:所有有效连接 n:使用ip地址代替名称 p:显示建立相关连接的程序名和PID  o:显示与网络计时器相关信息）

当前图片中可以看到，对端是192.100.12.6:50079，此时可以ssh到对端，查看是否是cn，并且用同样命令：

netstat -anop|grep 50079

查看cn节点的进程号是否与上述命令结果中的连接中的相同：

连接进程号即结果中xxxxx/gaussdb的xxxxx。如上图中的1240/gaussdb，1240即进程号。

cn进程号可以通过：ps aux | grep coo查看。如下：

此时可以判断该连接是由cn建立，与dn连接。此时确定连接还是有在使用的。

【更换思路】

一、这个时候线索断了，换一种思路，以dn上作业开始执行的时间对应在cn查询：

cn_5003上执行：select * from pg_stat_activity order by query_start;

这里发现有语句可以用开始的时间可以和dn上的作业开始时间对应上，并且语句完全一样，只是此时的queryid已经被置为0（因此一开始在cn没有查到），并且状态是idel in transaction，这个状态代表事务未提交。

二、此时查看对应线程的cn和dn之间的连接视图（前面有结果）：

可以看到对应线程号还是 inuse状态，表明连接不是残留。

三、根据cn上的连接client_port，继续看当前是谁连接了该cn，占用连接：

这里发现是有java进程一直占用连接，说明客户的客户端一直在连接事务一直没有commit。

【问题解决】

是客户的误操作，不是连接残留，但是既然客户有疑问，那就要分析清楚。

此篇博文可应用于所有连接残留问题定位分析。