数仓出现“wait|数仓出现“wait in ccn queue”的时候,怎么迅速定位处理()

摘要:现网在使用动态负载管理的时候,经常出现很多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
结果如下:
数仓出现“wait|数仓出现“wait in ccn queue”的时候,怎么迅速定位处理()
文章图片

5003就是集群的ccn。
ccn是什么:ccn作为集群并发控制大脑,所有复杂作业都会到ccn去申请资源,申请到资源的语句才能下发。复杂语句都会在ccn统一记录。
视图解释:
  • pg_stat_get_workload_struct_info();
    数仓出现“wait|数仓出现“wait in ccn queue”的时候,怎么迅速定位处理()
    文章图片
  • 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();
    数仓出现“wait|数仓出现“wait in ccn queue”的时候,怎么迅速定位处理()
    文章图片
步骤一、判断问题场景
  • 连接ccn查询以下语句, 判断问题场景:
第一步,查询pgxc_stat_activity,判断是否语句大量在wait ccn。或者某个资源池的语句都在wait ccn。
  • 查询pg/pgxc_session_wlmstat,判断是否所有复杂语句都在排队。或者同一队列的语句都在排队。
第一步,连接 ccn节点,查询
select * from pg_stat_get_workload_struct_info();
数仓出现“wait|数仓出现“wait in ccn queue”的时候,怎么迅速定位处理()
文章图片

第二步,查询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;

数仓出现“wait|数仓出现“wait in ccn queue”的时候,怎么迅速定位处理()
文章图片

根据以下场景判断使用后续哪种处理办法:
1)如果workload视图中有个别语句处于Running状态,并且running的语句占用内存很大, 占据freesize,大量语句处于waiting状态,那么基本可以确定走问题处理场景一。
2)如果是有workload视图中有running状态的语句,但是实际上pgxc_stat_activity或者pg_session_wlmstat视图中只有waiting状态的语句,并且workload视图中,存在两条或者多条语句的qid.queryId的值相同。那么基本确定走问题处理场景二。
3)如果所有语句都在waiting状态,没有running状态的语句,那么基本确定走处理场景三。
处理场景一 大内存语句导致问题 第一步 找到workload视图中占用内存过大的语句。
数仓出现“wait|数仓出现“wait in ccn queue”的时候,怎么迅速定位处理()
文章图片

如上图:总共可用内存为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;
数仓出现“wait|数仓出现“wait in ccn queue”的时候,怎么迅速定位处理()
文章图片

第二步 如果只是达到了资源池并发上限,例如,资源池并发设置为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
如有类似如下结果,则确认该问题
数仓出现“wait|数仓出现“wait in ccn queue”的时候,怎么迅速定位处理()
文章图片

第二步 应急处理
处理方法:
kill -9 ccn_pid
【数仓出现“wait|数仓出现“wait in ccn queue”的时候,怎么迅速定位处理()】点击关注,第一时间了解华为云新鲜技术~

    推荐阅读