并发控制常用定位方法及解决措施

并发控制常用定位方法及解决措施

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。