GaussDB整体性能慢-视图分析

问题描述

整体性能慢。不满足客户作业对时延要求或者不满足客户预期。

问题现象

业务反馈业务接口时延高;或者数据库P80/P95等指标升高;有可能会出现大量慢SQL。

告警

  • 业务侧相关接口时延、成功率等告警。
  • 数据库内核P80/P95相关告警。

业务影响

业务时延受损,或者业务在预期时间内无法执行完成。

原因分析

通常整体慢,建议参考"整体性能慢分析"章节,逐步找到性能慢问题点。本章节主要描述使用性能视图分析如下原因导致的性能慢,找到问题的根因点。

  • CPU高
  • IO高
  • 内存高
  • 异常等待事件(包含并发更新)
  • 性能抖动

处理方法

本章节描述内容聚焦在识别到影响性能相关SQL,具体SQL优化可参考1.2.1 单SQL性能慢分析。

CPU高

如果CPU高是gaussdb进程导致的,通常是由于不优SQL导致,本部分仅关注由于用户语句导致的CPU异常。

  1. 如果是持续CPU高,可查询如下两个视图,对cpu_time字段进行逆序排序即可识别。
    1. dbe_perf.statement:可查询分布式本CN/集中式DN发起的历史语句信息。
    2. dbe_perf.summary_statement:可查询分布式所有CN/集中式本DN发起的历史语句信息。
  2. 如果当前CPU高,表示正在执行的SQL语句CPU消耗较高。
    1. 查询pg_stat_activity获取正在运行的SQL的query_id。
    2. 使用上一步的query_id,查询pg_thread_wait_status获取正在运行的SQL的lwtid。
    3. 使用操作系统命令top -Hp gaussdb进程号,查看相应lwtid(PID)的CPU使用率。
    4. 如果确实CPU占用较高,可能为目标SQL;但本步骤假设是SQL运行时间较久,几个查询对应的SQL在运行,线程号不变,具体使用中,可灵活运行。
  3. 如果过去某段时间内CPU高,可参考本章节性能抖动部分识别目标SQL。
  4. 可查询慢SQL,通常如果说语句的CPU消耗较高,慢SQL语句的cpu_time和db_time差距就较小。
    1. 登录至各CN/DN结点查询相应时间段的statement_history表。
    2. 使用全局接口dbe_perf.get_global_full_sql_by_timestamp(‘开始时间’,‘结束时间’)。
      注意:需要切换至postgres库。
  5. 如果上述步骤找到的语句,CPU消耗过高可能是间隔性的,可以使用动态接口,抓取后续执行Query的详细信息。
    1. 抓此SQL(unique sql id是3182919165)的FULL SQL L2。
      select * from dynamic_func_control(‘LOCAL’,‘STMT’,‘TRACK’,’{“3182919165”,“L2”}’);
    2. 取消抓取SQL(unique sql id是3182919165)。
      select * from dynamic_func_control(‘LOCAL’,‘STMT’,‘UNTRACK’,’{“3182919165”}’);
    3. 查看所有在抓取的SQL状态。
      select * from dynamic_func_control(‘LOCAL’,‘STMT’,‘LIST’,’{}’);
    4. 取消抓取所有SQL。
      select * from dynamic_func_control(‘LOCAL’,‘STMT’,‘CLEAN’,’{}’);
    5. 最终在动态接口命令下达后,后续有目标SQL运行的话,会记录到statement_history表内,此处一定注意:动态接口一定要评估好目标SQL的执行次数,不可长开,否则会导致statement_history表占用空间过高;使用后,记得清理动态接口内所有SQL语句。

IO高

通常可使用pidstat/iotop识别到导致IO高的线程,有可能是其它内核后台线程导致的IO高,比如刷WAL线程,这些场景不具有代表性,而且和特性业务场景强关,本部分仅关注由于用户语句导致的IO异常。

  1. 如果持续IO高,可查询dbe_perf.statement/dbe_perf.summary_statement内n_blocks_fetched/n_blocks_hit字段,通常导致IO读高的情况,两个字段的差值会比较高,两者差值表示物理读的次数。
  2. 如果当前IO高,可查询pg_thread_wait_status视图,查询wait_status/wait_event字段,通常Query两者状态为IO_EVENT/DataFileRead表示有物理读产生。
  3. 如果过去某段时间IO高,可查询视图或者表dbe_perf.local_active_session/gs_asp中Query等待事件为:IO_EVENT/DataFileRead的记录,具体细节可参考本章节性能抖动部分。
  4. 查询慢SQL内n_blocks_fetched/n_blocks_hit字段差值较高记录,或者查询data_io_time较高记录;如果慢SQL开启了L2, details字段内相应events也会有相关events(DataFileRead)耗时显示,注意:仅在内核503版本有此能力。
    解析details字段:pg_catalog.statement_detail_decode(details, ‘plaintext’, true)
  5. 使用动态接口(见•CPU高),结合d也可识别异常SQL。

内存高

本节内容仅讨论数据库内核内部内存高分析定位。

  1. 查询dbe_perf.memory_node_detail视图,明确内存占用点。

    • max_process_memory:进程最大使用内存
    • process_used_memory:进程已经使用的内存
    • max_dynamic_memory:最大可使用动态内存
    • dynamic_used_memory:已使用动态内存
    • dynamic_used_shrctx:已使用的共享动态内存

    通常我们仅需要关注max_dynamic_memory和dynamic_used_memory差距,如果dynamic内存不足,会导致用户查询报错,dynamic_used_memory包含两部分内容:

    1. 用户session上的内存消耗,比如:计划缓存、排序等。
    2. 内核模块的内存消耗,如:Global Sys Cache、Unique SQL等。
  2. dynamic_used_shrctx较小,查询dbe_perf.session_memory_detail可获取到不同Session的内存消耗,通常来讲:用户会话数和用户每个session上内存占用都会导致动态内存异常问题。

  3. dynamic_used_shrctx较大,查询dbe_perf.shared_memory_detail可获取到异常内存消耗的context,通常此处有过多的异常消耗,多数情况下为用户session上的内存异常消耗。

异常等待事件(包含并发更新)

异常等待事件导致的整体慢,通常需要先识别到异常等待事件,分析此等待事件是否有可能导致性能慢,然后再去想办法消减异常等待事件,常见等待事件相关处理手段,可参考1.2.7 整体性能慢-等待事件分析。

  1. 当时性能慢
    查询pg_thread_wait_status,获取当前多数会话正在等待的事件。
  2. 过去性能慢
    • 过去短时间内性能慢,查询dbe_perf.local_active_session。
    • 两天内的性能慢,查询gs_asp表(postgres库内)。
  3. 排查异常慢SQL
    • 查询statement_history表内details字段(内核需要503版本及以上),需要切换至postgres库内。
    • 使用pg_catalog.statement_detail_decode(details, ‘plaintext’, true)函数解析异常events。
  4. 一直慢
    • 可排查dbe_perf.wait_events,按total_wait_time或者avg_wait_time进行逆序排序。
    • 识别top events,可参考1.2.7 整体性能慢-等待事件分析。

性能抖动

小时级性能抖动,可使用WDR分析;分钟级性能抖动,可通过ASP(Active Session Profile)的相关视图和表进行分析识别。

  • ASP默认每秒采样活跃会话信息,然后存入内存(dbe_perf.local_active_session),默认内存存储10W条记录,满后按十分之一采样率下盘(gs_asp)。
  • 所以理想情况下,ASP内存视图存储每秒的会话数据,物理表存储以10秒为间隔存储会话数据。
  1. 对于短时间秒级性能抖动,分析相应时间点的dbe_perf.local_active_session,可排查点如下:
    • 异常等待事件,当时SQL的异常等待事件,可参考1.2.7 整体性能慢-等待事件分析。
    • 异常SQL,分析某些SQL出现的频率变化,以及执行速度,如多次采样均被采集到,即可反向分析到SQL执行时间。
    • 异常连接数变化,比如业务突然连接增加。
  2. 对于两天内秒级性能抖动,分析相应时间点的gs_asp表,排查点参考1。

你可能感兴趣的:(GaussDB经验总结,gaussdb,GaussDB,云原生,DBA,数据库,sql)