单SQL性能慢,客户作业对时延要求或者不满足客户预期。
b.定期巡检WDR报告发现异常SQL,如CPU消耗较多的Top SQL等。
1、获取完整的SQL语句和SQL中相关表的结构、索引信息、表大小和索引大小等信息。
2、获取数据库的参数配置信息,包括work_mem、maintance_work_mem、shared buffers等,比如排序操作或者hash操作语句可能因为work_mem太小而影响执行执行效率。
3、获取SQL中相关结构的pgstat信息,pgstat相关可以用来分析vacuum和analyze情况、以及表和索引的状态信息,这部分可以通过pg_stat_all_tables, pg_stat_all_indexes, pg_statio_all_tables, pg_statio_all_indexes等视图获取,具体视图分析请参考1.2.2 单SQL性能慢-视图分析。
4、对于有可能写大量日志的慢SQL,需要先确认该环境是否有开启流控(recovery_time_target)操作,为了保证RTO对于突然激增的xlog日志,流控可能会限制xlog同步到备机的速度,导致语句执行变慢,具体排查方法请参考1.2.2 单SQL性能慢-视图分析。
5、收集慢SQL对应时间段的系统资源情况,确认系统资源是否有异常。
a.首先确定SQL慢在什么地方,可以通过pg_thread_wait_status或者ASP信息分析该SQL的Top Wait Event信息,具体分析方法参考1.2.2 单SQL性能慢-视图分析,其中等待事件的说明请参考•异常等待事件。
b.如该SQL有大量的等锁事件,可以通过ASP中的block sessionid信息找到锁等待关系,并确定等锁的原因。
c.如果语句执行时间超过慢SQL阈值log_min_duration_statement,可以通过Full SQL视图查看计划,具体分析方法请参考1.2.2 单SQL性能慢-视图分析。
d.根据找到的慢SQL,跟业务沟通是否能获取完成的业务SQL,尝试复现。
a.拿到慢SQL语句首先考虑通过explain获取计划,能快速确定语句的性能瓶颈点,并结合步骤2获取的信息分析具体原因,计划分析参考1.2.8 执行计划常见问题。
b.另外可以通过summary_statement和statement_history分析SQL的KPI信息,首先可以通过SQL的时间模型确定具体的耗时阶段,然后结合行活动、语句级别wait event等信息确定SQL的耗时原因,具体分析参考1.2.2 单SQL性能慢-视图分析。
a.如果SQL的执行时间超过慢SQL阈值log_min_duration_statement,则通过statement_history查看慢SQL的执行计划、时间模型、行活动、wait event、锁等信息,其中计划分析参考1.2.8 执行计划常见问题,其他参考1.2.2 单SQL性能慢-视图分析。
b.如果慢SQL的top wait event有等事件,可以通过ASP信息查看会话间的锁等待关系。
c.如果语句执行时间没超过log_min_duration_statement阈值,第一种可以考虑打开full SQL,set track_stmt_stat_level = ‘L1,L1’,需要注意打开会SQL会记录所有执行的语句(可以会话级别打开),会占用大量的磁盘,用完后要理解关闭;第二种可以考虑调用动态接口,对固定的慢进行跟踪。一般是先通过慢SQL视图分析,通过gs_asp查看慢SQL对应的wait event信息,通过statement_history查看慢SQL信息。
select * from
dynamic_func_control('GLOBAL', 'STMT', 'TRACK', '{"3182919165",
"L1"}');
select * from dynamic_func_control('GLOBAL', 'STMT', 'UNTRACK',
'{"3182919165"}');
select * from dynamic_func_control('GLOBAL', 'STMT', 'LIST', '{}');
select * from dynamic_func_control('LOCAL', 'STMT', 'CLEAN', '{}');