共计 2873 个字符，预计需要花费 8 分钟才能阅读完成。
摘要： 现网在应用动静负载治理的时候，经常出现很多 wait in ccn 的状况，大家解决起来就会认为是 hung 住或者怎么着了，很着急，但 wait ccn 其实就是一个期待资源的状态，在此总结一个 ccn 问题解决的博文，ccn 的问题都能够通过此贴解决。
本文分享自华为云社区《GaussDB(DWS) wait in ccn queue 的时候，怎么迅速定位解决？》，作者：Malick。
前言
现网在应用动静负载治理的时候，经常出现很多 wait in ccn 的状况，大家解决起来就会认为是 hung 住或者怎么着了，很着急，但 wait ccn 其实就是一个期待资源的状态，在此总结一个 ccn 问题解决的博文，ccn 的问题都能够通过此贴解决。
背景常识：
- 哪个是 ccn：
连贯环境，
source 环境变量
source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile执行：
cm_ctl query -Cv | grep Cen -A 4
后果如下：
5003 就是集群的 ccn。
ccn 是什么：ccn 作为集群并发管制大脑，所有简单作业都会到 ccn 去申请资源，申请到资源的语句能力下发。简单语句都会在 ccn 对立记录。
视图解释：
- pg_stat_get_workload_struct_info();
- totalsize 代表 ccn 总体能调配的内存，totalsize: 即最大动态内存；freesize_limit 即最大可用于 ccn 调配的内存，为最大动态内存的 80%。freesize 代表以后残余内存。
- 只须要关注图中的 central waiting/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 by status,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) from pgxc_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) from pgxc_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_lock ccnStack.log
如有相似如下后果，则确认该问题
第二步 应急解决
解决办法：
kill -9 ccn_pid
点击关注，第一工夫理解华为云陈腐技术~
