摘要：现网在应用动静负载治理的时候，经常出现很多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

点击关注，第一工夫理解华为云陈腐技术~