如何解决Postgresql 12 在 Slave 上的高 CPU 峰值通过运行分析修复..无法 RCA
您好，Postgresql 12 的 cpu 使用率逐渐飙升至 100%。应用团队从 60 分钟开始处理问题。 2 个不同的查询占用了高 cpu。涉及的表很小，所以我只是对所有 3 个涉及的表进行分析以修复任何底层统计问题，而没有先检查查询计划。分析运行后，问题得到修复。
现在我们尝试从比问题时间早几个小时的备份中重新创建问题，但在分析之前和之后的查询计划是相同的。我们找不到 RCA。
系统详细信息： 虚拟cpu：8 内存：61GB 模式：从/只读副本
表格详情 资源类型：174 行 角色：290026 行 user_role_mapping：3332118 行
从产品复印机查询计划（用于 RCA）： 解释（分析为真、详细为真、成本为真、缓冲区为真、时间为真） SELECT * FROM user_role_mapping u WHERE u.user_profile_id = '44130444' AND u.service_name = 'GLOBAL' AND u.status = 'ACTIVE' AND EXISTS（SELECT * FROM roles r WHERE r.id=u.role_id AND r.role_name= 'Owner') AND EXISTS (SELECT * FROM resource_type_dummy r WHERE r.id=u.resource_type_id AND r.type='HOTEL');
解释（分析为真，详细为真，成本为真，缓冲区为真，时间为真） SELECT * FROM user_role_mapping u WHERE u.user_profile_id = 'x1' AND u.service_name = 'GLOBAL' AND u.status = 'ACTIVE' AND EXISTS (SELECT * FROM roles r WHERE r.id=u.role_id AND r.role_name= 'Owner') AND EXISTS (SELECT * FROM resource_type r WHERE r.id=u.resource_type_id AND r.type='HOTEL');
QUERY PLAN
嵌套循环（cost=1.00..424.35 rows=1 width=361）（实际时间=368.512..369.536 rows=1 loops=1） 输出：u.id、u.status、u.created_by、u.created_at、u.modified_by、u.last_modified_at、u.service_name、u.crs_id、u.identity_id、u.role_id、u.resource_id、u.resource_type_id、 u.user_profile_id 内在唯一性：true 缓冲区：共享命中=3 读取=9 I/O 时序：读取=369.368 -> nested Loop (cost=0.57..415.82 rows=1 width=361) (实际时间=281.798..282.821 rows=1 loops=1) 输出：u.id、u.status、u.created_by、u.created_at、u.modified_by、u.last_modified_at、u.service_name、u.crs_id、u.identity_id、u.role_id、u.resource_id、u.resource_type_id、 u.user_profile_id 加入过滤器：（u.resource_type_id = r_1.id） 缓冲区：共享命中=1 读取=7 I/O 时序：读取=282.696 -> 在 public.resource_type r_1 上使用 type_index_resource_type 进行索引扫描（cost=0.14..8.16 rows=1 width=16）（实际时间=0.054..0.055 rows=1 loops=1） 输出：r_1.id、r_1.status、r_1.created_by、r_1.created_at、r_1.modified_by、r_1.last_modified_at、r_1.service_name、r_1.crs_id、r_1.type、r_1.actions 索引条件：((r_1.type)::text = 'HOTEL'::text) 缓冲区：共享命中=1 读取=1 I/O 时序：读取=0.016 -> 索引扫描使用 user_profile_id_index_user_role_mapping on public.user_role_mapping u (cost=0.43..407.19 rows=37 width=361) (actual time=281.739..282.759 rows=1 loops=1) 输出：u.id、u.status、u.created_by、u.created_at、u.modified_by、u.last_modified_at、u.service_name、u.crs_id、u.identity_id、u.role_id、u.resource_id、u.resource_type_id、 u.user_profile_id 索引条件：((u.user_profile_id)::text = 'x1'::text) 过滤器：(((u.service_name)::text = 'GLOBAL'::text) AND ((u.status)::text = 'ACTIVE'::text)) 过滤器移除的行数：2 缓冲区：共享读取=6 I/O 时序：读取=282.680 -> 使用 pk_roles 对 public.roles 进行索引扫描 r (cost=0.42..8.44 rows=1 width=16) (actual time=86.708..86.708 rows=1 loops=1) 输出：r.id、r.status、r.created_by、r.created_at、r.modified_by、r.last_modified_at、r.service_name、r.crs_id、r.role_name、r.team_name、r.access_category、r.crs_team_id、动作 索引条件：（r.id = u.role_id） 过滤器：((r.role_name)::text = 'Owner'::text) 缓冲区：共享命中=2 读取=2 I/O 时序：读取=86.672 规划时间：0.439 毫秒 执行时间：369.570 毫秒 （30 行）
解释（分析为真，详细为真，成本为真，缓冲区为真，时间为真） SELECT CAST(urm.id AS VARCHAR),urm.status,urm.created_by,urm.created_at,CAST(urm.modified_by AS VARCHAR),urm.last_modified_at,urm.service_name,urm.crs_id,urm.identity_id,CAST(urm .role_id AS VARCHAR),urm.resource_id,CAST(urm.resource_type_id AS VARCHAR),urm.user_profile_id,r.role_name role_name,rt.type resource_type_name FROM user_role_mapping urm INNER JOIN (SELECT id,role_name FROM roles .r W ('xa','xb','xc','xd'))r ON urm.role_id = r.id INNER JOIN (SELECT id,rt.type FROM resource_type rt WHERE rt.type = 'experiment')rt ON urm.resource_type_id = rt.id WHERE (urm.user_profile_id IN ('11','12')) AND urm.service_name = 'CRS' AND urm.status = 'ACTIVE';
嵌套循环（cost=1.00..830.89 rows=1 width=271）（实际时间=240.293..240.294 rows=0 loops=1） 输出：(urm.id)::character变量、urm.status、urm.created_by、urm.created_at、(urm.modified_by)::character变量、urm.last_modified_at、urm.service_name、urm.crs_id、urm.identity_id、 (urm.role_id)::字符变化、urm.resource_id、(urm.resource_type_id)::字符变化、urm.user_profile_id、r.role_name、rt.type 内在唯一性：true 缓冲区：共享命中=8 读取=5 I/O 时序：读取=240.145 -> nested Loop (cost=0.57..822.43 rows=1 width=379) (实际时间=240.292..240.293 rows=0 loops=1) 输出：urm.id,urm.modified_by,urm.role_id,urm_typere urm.user_profile_id,rt.type 加入过滤器：（urm.resource_type_id = rt.id） 加入过滤器删除的行：2 缓冲区：共享命中=8 读取=5 I/O 时序：读取=240.145 -> 在 public.resource_type rt 上使用 type_index_resource_type 进行索引扫描（cost=0.14..8.16 rows=1 width=34）（实际时间=0.018..0.019 rows=1 loops=1） 输出：rt.id、rt.status、rt.created_by、rt.created_at、rt.modified_by、rt.last_modified_at、rt.service_name、rt.crs_id、rt.type、rt.actions 索引条件：((rt.type)::text = 'experiment'::text) 缓冲区：共享命中=2 -> 在 public.user_role_mapping urm 上使用 user_profile_id_index_user_role_mapping 进行索引扫描 (cost=0.43..814.21 rows=4 width=361) (actual time=138.694..240.267 rows=2 loops=1) 输出：urm.id,urm_typere urm.user_profile_id 索引条件：((urm.user_profile_id)::text = ANY ('{11,12}'::text[])) 过滤器：(((urm.service_name)::text = 'CRS'::text) AND ((urm.status)::text = 'ACTIVE'::text)) 缓冲区：共享命中=6 读取=5 I/O 时序：读取=240.145 -> 使用 pk_roles 对 public.roles r 进行索引扫描（成本=0.42..8.45 行=1 宽度=32）（从未执行） 输出：r.id、r.status、r.created_by、r.created_at、r.modified_by、r.last_modified_at、r.service_name、r.crs_id、r.role_name、r.team_name、r.access_category、r.crs_team_id、动作 索引条件：（r.id = urm.role_id） 过滤器：((r.role_name)::text = ANY ('{xa,xb,xc,xd}'::text[])) 规划时间：0.860 毫秒 执行时间：240.358 毫秒 （27 行）
还有其他方向可以看吗？
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
