数仓出现“wait in ccn queue”的时候，怎么迅速定位处理？

​​​​摘要：现网在使用动态负载管理的时候，经常出现很多 waitin ccn 的情况，大家处理起来就会认为是 hung 住或者怎么着了，很着急，但 wait ccn 其实就是一个等待资源的状态，在此总结一个 ccn 问题处理的博文，ccn 的问题都可以通过此帖处理。

本文分享自华为云社区《GaussDB(DWS) wait in ccn queue的时候，怎么迅速定位处理？》，作者：Malick 。

前言

现网在使用动态负载管理的时候，经常出现很多 wait in ccn 的情况，大家处理起来就会认为是 hung 住或者怎么着了，很着急，但 wait ccn 其实就是一个等待资源的状态，在此总结一个 ccn 问题处理的博文，ccn 的问题都可以通过此帖处理。

背景知识

1.    哪个是 ccn：

连接环境，

source 环境变量

source/opt/huawei/Bigdata/mppdb/.mppdbgs_profile

执行：

cm_ctl query -Cv | grep Cen -A 4

结果如下：

5003 就是集群的 ccn。

ccn 是什么：ccn 作为集群并发控制大脑，所有复杂作业都会到 ccn 去申请资源，申请到资源的语句才能下发。复杂语句都会在 ccn 统一记录。

2.    视图解释：

• pg_stat_get_workload_struct_info();

• totalsize 代表 ccn 总体能分配的内存，totalsize:即最大动态内存；freesize_limit 即最大可用于 ccn 分配的内存，为最大动态内存的 80%。freesize 代表当前剩余内存。

• 只需要关注图中的 centralwaiting/running number（global 的可以不用关注，属于另一个数据结构，和 central waiting 是重复信息。）。每一行代表一个语句。running 代表语句正在运行，waiting 代表语句正在排队。queryId 代表语句的线程号，对应 pg/pgxc_thread_wait_status 中的 lwtid、pg_sessiion_wlmstat 中的 processid。

• pg_session_wlmstat/pgxc_session_wlmstat();

步骤一、判断问题场景

• 连接 ccn 查询以下语句， 判断问题场景：

第一步，查询 pgxc_stat_activity，判断是否语句大量在 wait ccn。或者某个资源池的语句都在 wait ccn。

• 查询 pg/pgxc_session_wlmstat，判断是否所有复杂语句都在排队。或者同一队列的语句都在排队。

第一步，连接 ccn 节点，查询

select * from pg_stat_get_workload_struct_info();

第二步，查询 pgxc_session_wlmstat();

select threadid,processid,usename,attribute,status,enqueue,statement_mem,active_points,control_group,resource_pool,substring(query,position('explain'in query),20) as subquery from pg_session_wlmstat order bystatus,attribute,usename,subquery,resource_pool;

根据以下场景判断使用后续哪种处理办法：

1）如果 workload 视图中有个别语句处于 Running 状态，并且 running 的语句占用内存很大， 占据 freesize，大量语句处于 waiting 状态，那么基本可以确定走问题处理场景一。

2）如果是有 workload 视图中有 running 状态的语句，但是实际上 pgxc_stat_activity 或者 pg_session_wlmstat 视图中只有 waiting 状态的语句，并且 workload 视图中，存在两条或者多条语句的 qid.queryId 的值相同。那么基本确定走问题处理场景二。

3）如果所有语句都在 waiting 状态，没有 running 状态的语句，那么基本确定走处理场景三。

处理场景一 大内存语句导致问题

第一步 找到 workload 视图中占用内存过大的语句。

如上图：总共可用内存为 1638MB，目前正在运行的一个语句占用内存为 1048MB，剩余内存 freesize=590MB

此时，其余语句内存估算大小都是 600MB，因此内存不足全都无法下发下去，只有等到该 1048 的语句结束，内存释放才能恢复正常。

第二步 根据语句对应的 qid.queryId，找到语句的 pid。如上图为 9145

select coorname,pid,usename,substr(query,0,30) frompgxc_stat_activity a,pgxc_thread_wait_status b where a.pid = b.tid and b.lwtid= $qid.query_id;

第三步 根据 pid 和 cn，查杀大内存语句。释放内存后即可恢复。

处理场景二 hash 残留或者其他语句残留问题

第一步 确认有问题的资源池上的并发配置：

select * from pg_resource_pool;

第二步 如果只是达到了资源池并发上限，例如，资源池并发设置为 10，残留的 running 语句数量是 10，因为并发达到上限，语句都处于等待状态，那么调整队列并发为-1，不限制之后，等待并发的语句即可下发下去。

修改办法，以 son_pool 为例：

alter resource pool son_pool with(active_statements=-1);

第三步 清理掉问题语句（连接不断开，线程不释放，残留信息不会自动清理）

备注：清理已经失效的语句信息，是根据/proc/processed 是否还存在进行判断，如不存在，则清理，如一直占有该连接，则不会释放线程。残留也不会自动清理。

• 问题语句的判定：

在 workload 视图中 qid.queryId 重复的语句便是问题语句，问题线程，重复两条，可能其中一条是正常的，另一条是残留的。也可能都是有问题的，但是终究实际上只有一个活跃的语句在排队或者执行。

2）清理问题语句方法，根据上述 1）中提到的重复的 qid.queryId，找到问题语句：

select coorname,pid,usename,substr(query,0,30) frompgxc_stat_activity a,pgxc_thread_wait_status b where a.pid = b.tid and b.lwtid= $qid.query_id;

第三步 根据 pid 和 cn，使用 pg_terminate_backend(pid)查杀残留语句。释放并发以及内存资源之后恢复。

处理场景三 长跳转锁问题

第一步 确认问题

打堆栈

gstack $ccn_pid >ccnStack.log

grep grep pthread_mutex_lockccnStack.log

如有类似如下结果，则确认该问题

第二步 应急处理

处理方法：

kill -9 ccn_pid

点击关注，第一时间了解华为云新鲜技术~