摘要：現網在使用動态負載管理的時候，經常出現很多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，找到問題語句：
第三步 根據pid和cn，使用pg_terminate_backend(pid)清除殘留語句。釋放并發以及記憶體資源之後恢複。
處理場景三 長跳轉鎖問題
第一步 确認問題
打堆棧
gstack $ccn_pid > ccnStack.log
grep grep pthread_mutex_lock ccnStack.log
如有類似如下結果，則确認該問題
第二步 應急處理
處理方法：
kill -9 ccn_pid
點選關注，第一時間了解華為雲新鮮技術~