本文分享自华为云社区《【带你走进DWS大集群内幕】大集群通信：作业hang、残留问题定位》，作者： 雨落天穹丶。
前言：
测试过程中，我们会遇到这样一种情况，我的作业都执行很久了，为啥还不结束，是不是作业hang掉了？ 或者说，明明看到CN上的作业都没了，为什么通过全局视图发现DN上还有作业在执行而没有退出，这是不是有问题啊？那么就带着这样的疑问点来阅读本篇分析问题的方式方法，给初学者一点定位思路。
【通信系统视图】
pgxc_comm_send_stream ：展示所有DN上的通信库发送流状态。
pgxc_comm_recv_stream ：展示所有DN上的通信库接收流状态。
pg_thread_wait_status ：通过PG_THREAD_WAIT_STATUS视图可以检测当前实例中工作线程（backend thread）以及辅助线程（auxiliary thread）的阻塞等待情况。
pgxc_thread_wait_status ：通过CN节点查看PGXC_THREAD_WAIT_STATUS视图，可以查看集群全局各个节点上所有SQL语句产生的线程之间的调用层次关系，以及各个线程的阻塞等待状态，从而更容易定位进程停止响应问题以及类似现象的原因。
pg_stat_activity ：PG_STAT_ACTIVITY视图显示和当前用户查询相关的信息。若有管理员权限或预置角色权限可以显示和所有用户查询相关的信息。
pgxc_stat_activity ：PGXC_STAT_ACTIVITY视图显示当前集群下所有CN的当前用户查询相关的信息。
单实例查询：可直连DN/CN 通过此条SQL进行DN/CN上活跃会话访问查询。
select datname,usename,pid,query_id,query_start,query from pg_stat_activity where state='active' order by query_start;
全局查询： 获取所有的CN上当前的作业执行情况
select coorname,datname,usename,pid,query_id,query_start,query from pgxc_stat_activity where state='active' order by query_start;
【发现问题】1. 集群作业停止一段时间后，发现集群DN还存在比较高的压力CPU，查询活跃会话视图，观察是否存在未执行完的作业，或者只是主备DN数据同步(同步属于正常情况，但持续时间过长，就要分析DN HA catchup 机制是否正常)
例如，如下查询到的结果可以观察到，当前时间19:38，作业已经退出很久了，发现在linux0802集群的6606端口DN上还存在16:49分的作业还在执行，且通过作业分析发现，该作业是简单的 create table as select * 场景 ，正常测试返回结果在10s之内，那当前作业还存在于此DN上处于active执行状态，就显得很不正常。
![cke_143.png]()
那我们就针对这条存在的活跃会话进行分析。
【分析问题】通过全局会话等待视图观察这个作业当前的执行状态
获取上图中的执行query的 query_id 通过query_id查询作业执行状态：
select * from pgxc_thread_wait_status where query_id='219269006857675600' order by 1,2;
-- 通过上面查出query_id分析
![cke_144.png]()
查询结果发现所有的线程都是在获取stream连接状态，且已经不存在与CN的连接信息
那我们找一个DN节点查看堆栈：选取 dn_6007_6008 lwtid = 2238755
![cke_145.png]()
通过cm_ctl query -Cv 查找dn 6007 所在的物理节点环，观察当前主DN是 6007 还是 6008(一般业务连接都是主DN，如果发生主备切换，那么我们查看堆栈就要到6008节点[当前的主DN节点])
![cke_146.png]()
连接到到所在物理节点， 用gstack 2238755 (多执行几遍,如果栈内容一直不变，可能就是hang，需要分析位，如果栈一直在变可能是在工作，确实是sql执行慢，可联系开发帮忙确认分析是不是正常堆栈)
![cke_147.png]()
【问题初步结论】初步分析堆栈代码属于通信相关，找对应的责任田定位问题。
【发现问题】2. 集群作业停止一段时间后，发现集群CN上还存在未执行完的作业，但是DN上的作业连接已经全部退出
还是通过上面的例子中的查询活跃会话的语句，分析找到对应的query id。
通过线程等待视图查询当前作业执行情况。
select * from pgxc_thread_wait_status where query_id='237283405371509247' order by 1,2;
![cke_148.png]()
上图中当前只剩下CN线程，DN线程全部退出，那么这种情况就需要去分析CN对应等待状态中的dn 6301实例上的对应远端线程在干什么
通过通信pooler视图查询对应的remote node 线程号： select * from pg_pooler_status where pid=140069915589224;
![cke_149.png]()
然后用线程等待视图查询：select * from pgxc_thread_wait_status where pid = 140704341249976 order by 1,2;
![cke_150.png]()
可以按上面第一种类型的查询DN节点操作 访问dn_6301_6302 主DN 所在的物理机器节点 用 gstack 39625 观察堆栈。
![cke_151.png]()
【问题初步结论】
初步判断是DN在等主备同步呢，此时DN上的query id清0了，用query_id匹配不到，后续联系对应责任田分析。
点击关注，第一时间了解华为云新鲜技术~
