并发控制常用定位方法及解决措施
7.1 排队问题
出现业务阻塞、性能下降、查询无响应等类似现网问题时，通过以下方法可以排查是否排队问题并定位排队原因，同时根据排队原因给出相应规避措施。
7.1.1 确认是否排队
首先确认是否排队问题，其次排查排队原因，确认是否属于正常排队：
- 813 及以上版本查询资源池监控视图
select rpname,slow_run,slow_wait,slow_limit,used_cpu,cpu_limit,used_mem,estimate_mem from gs_respool_resource_info;- 老版本查询作业负载视图
select resource_pool,attribute,lane,status,enqueue,sum(statement_mem) as stmt_mem,count(1) from pgxc_session_wlmstat where status!='finished' and attribute!='Internal' and usename!='Ruby' group by 1,2,3,4,5;通过视图可以获取到各资源池快慢车道作业运行信息，据此可以判断是否排队问题：
如果有作业处于排队状态，则可能是排队导致的问题，否则排除排队问题；可能的排队原因包括：
- 单 CN 全局并发排队；
- 快车道并发排队；
- 静态慢车道并发排队；
- 静态慢车道内存排队；
- 动态 CCN 全局内存排队；
- 动态 CCN 慢车道并发排队；
- 动态 CCN 慢车道内存排队。
排查排队原因
常见排队原因及解决措施
1）全局并发排队
单 CN 实际运行作业数≥全局并发上限，则全局并发排队正常；
单 CN 实际运行作业数长时间小于全局并发上限，则可能存在计数泄露。
2）快车道排队
快车道实际运行作业数≥快车道并发上限，则快车道并发排队正常；
快车道实际运行作业数长时间小于快车道并发上限，则可能存在计数泄露。
3）静态慢车道排队
慢车道实际运行作业数≥慢车道并发上限，则慢车道并发排队正常；
慢车道实际运行作业累计估算内存≥慢车道内存上限，则慢车道内存占用达到上限导致排队，关注是否有查询估算内存过大；
如果慢车道并发和内存占用长时间达不到上限，则可能存在计数泄露。
4）动态 CCN 排队
如果查询在 CCN 排队，则需要查询 CCN 开发者视图确认排队原因：
select * from pg_stat_get_workload_struct_info();CCN 上可能的排队原因：
- CCN 全局可用内存不足导致排队，此时需特别关注是否有查询估算内存过大；
- 资源池实际运行作业数≥慢车道车道并发上限，资源池并发上限，正常排队；
- 资源池实际运行作业累计估算内存≥慢车道内存上限，则慢车道内存占用达到上限导致排队，此时需特别关注是否有查询估算内存过大；
- 资源池实际运行作业数或占用内存与记账值不符，则可能存在计数泄露 BUG；
- 队首作业在 CCN 哈希中不存在，说明队首作业残留导致查询不能正常下发；
- CN/CCN 处于 recover 状态或收集 DN 内存信息失败（多 CCN）导致所有查询等待 5s 下发，现象为所有查询排队时间均为 5~6s。
