更新时间:2024-11-30 GMT+08:00
历史TopSQL
系统提供了资源监控历史视图用来查询历史TopSQL。资源监控历史视图记录了查询作业运行结束时的资源使用情况(包括内存、下盘、CPU时间等)和运行状态信息(包括报错、终止、异常等)以及性能告警信息。但对于由于FATAL、PANIC错误导致查询异常结束时,状态信息列只显示aborted,无法记录详细异常信息。特别的,对于查询解析,优化阶段的状态信息则无法监控。
历史视图具体的对外接口如下表所示:
视图级别 |
节点范围 |
查询视图 |
|
---|---|---|---|
query级别/perf级别(推荐使用) |
当前CN |
历史(内部转储接口,仅显示最近三分钟内结束的语句) |
|
历史(全部语句) |
|||
所有CN |
历史(内部转储接口,仅显示最近三分钟内结束的语句) |
||
历史(全部语句) |
|||
operator级别 |
当前CN |
历史(仅显示最近三分钟内结束的语句) |
|
历史(内部转储接口,全部语句) |
|||
所有CN |
历史(仅显示最近三分钟内结束的语句) |
||
历史(内部转储接口,全部语句) |
- 视图级别取决于资源监控的等级,即参数resource_track_level的配置。
- perf和operator级别会影响GS_WLM_SESSION_STATISTICS/PGXC_WLM_SESSION_INFO中的query_plan和warning字段的取值,详细内容参见SQL自诊断。
- 对外接口通过不同的前缀(gs与pgxc)来区分单CN查询视图以及集群级别查询视图。普通用户仅支持登录到集群的某个CN查询以gs为前缀的视图。
- 实例故障时,历史TopSQL视图有可能记录不全。
- 在某些异常的情况下,历史TopSQL中的状态信息列可能会显示为unknown,其记录的监控信息会导致不准确。
- 历史TopSQL能够记录的SQL语句的规格与实时TopSQL能够记录的SQL语句的规格一致。请参考实时TopSQL中能够记录的SQL语句的规格。
- 历史TopSQL只有在GUC参数enable_resource_record开启时才会记录数据。
- 查询历史TopSQL Query以及算子级别数据时,仅能通过postgres数据库进行访问。
- 历史TopSQL侧重于查询性能的定位定界辅助分析,不作为审计功能使用,不记录语法分析报错类语句。
- 8.2.1集群版本开始,新增GUC参数resource_track_subsql_duration(默认值为180秒),用于过滤存储过程中执行时间小于该参数的子语句,仅归档执行时间大于该参数的子语句。且从8.2.1版本开始,GUC参数enable_track_record_subsql默认值由off变更为on,默认将会记录存储过程中的子语句。如果一条子语句被记录,那么它必然满足以下几个条件:
- 语句所在的会话中,参数enable_track_record_subsql开启。
- 该子语句一定要下推到DN端执行(为避免TopSQL记录过多的子语句,不下推到DN端执行的子语句会被过滤)。
- 该子语句的执行时间超过所在会话中resource_track_subsql_duration参数值。
- 关于history视图,默认会查询最近3分钟内结束的语句,该视图内部实际查询的是表,属于因性能考虑而实现的临时视图,从8.1.3集群版本开始,TopSQL监控功能中的实时监控和归档功能已有大幅度提升,不再有性能问题查询中不再建议优先使用history视图。
- 从8.1.3集群版本开始,TopSQL实时监控功能几乎对语句性能无影响,完全可以将GUC参数resource_track_cost设置为0来监控所有语句的运行时的信息;而TopSQL历史监控中对语句归档的能力,对语句执行性能也无影响,但当TPS较高时,需要考虑以下两个因素:
- 记录所有语句的磁盘开销,用户可以将一条语句归档所需要的磁盘空间估算为8KB,按照业务TPS的峰值来计算相应的空间占用情况,来合理调整resource_track_duration和resource_track_subsql_duration参数。
- 缓存所有语句的内存开销,用户可以将一条语句归档所需要的内存大小估算为16KB,语句批量归档的间隙为5秒,按照业务TPS的峰值来计算所需的内存峰值,计算方法为:5秒*TPS*16KB,需要session_history_memory GUC参数(默认值为100MB)要大于所需值,才能保证所有语句都能被记录。
前提条件
- GUC参数enable_resource_track为on (默认为on)。
- GUC参数resource_track_level为query、perf或operator(默认为query)。设置方法详见表2。
- GUC参数enable_resource_record为on(默认为on)。
- GUC参数resource_track_duration小于作业执行时间(默认为60s)。
- GUC参数enable_track_record_subsql控制是否记录存储过程、匿名块内部语句(默认为on)。
- GUC参数resource_track_subsql_duration小于存储过程中内部语句的执行时间(默认为180s)。
- 监控作业类型为:资源监控实时视图(参见表1)中记录的作业结束时的执行时间大于或等于resource_track_duration的作业。
- Cgroups功能正常加载,可通过gs_cgroup -P查看控制组信息。
操作步骤
- 通过视图gs_wlm_session_history查询当前CN最近执行作业结束后的负载记录。
1
SELECT * FROM gs_wlm_session_history;
- 通过视图pgxc_wlm_session_history查询所有CN最近执行作业结束后的负载记录。
1
SELECT * FROM pgxc_wlm_session_history;
- 通过数据表gs_wlm_session_info查询当前CN作业执行结束后的负载记录。要查到历史记录,必须保证enable_resource_record为on。
1
SELECT * FROM gs_wlm_session_info;
- 消耗内存最多的10个Query(可指定查询时间段)。
1
SELECT * FROM gs_wlm_session_info order by max_peak_memory desc limit 10;
1
SELECT * FROM gs_wlm_session_info WHERE start_time >= '2022-05-15 21:00:00' and finish_time <='2022-05-15 23:30:00' order by max_peak_memory desc limit 10;
- 消耗CPU最多的10个Query。
1
SELECT * FROM gs_wlm_session_info order by total_cpu_time desc limit 10;
1
SELECT * FROM gs_wlm_session_info WHERE start_time >= '2022-05-15 21:00:00' and finish_time <='2022-05-15 23:30:00' order by total_cpu_time desc limit 10;
- 通过视图pgxc_wlm_session_info查询所有CN的作业执行结束后的负载记录。要查到历史记录,必须保证enable_resource_record为on。
1
SELECT * FROM pgxc_wlm_session_info;
- 查询所有CN消耗时间最多的10个query
1
SELECT * FROM pgxc_wlm_session_info order by duration desc limit 10;
- 查询已经完成执行的query语句的执行信息。如:查询queryid为76561193695026478的语句执行信息。
SELECT * FROM pgxc_wlm_session_info where queryid = '76561193695026478';
- 通过函数pgxc_get_wlm_session_info_bytime对视图pgxc_wlm_session_info进行筛选查询,要查到历史记录,必须保证enable_resource_record为on。在统计数据量很大的场景中,建议使用该函数进行查询。
GaussDB(DWS)集群默认使用时区为UTC时间,与系统时间存在8h时差,请确保数据库时间与系统时间一致后进行以下查询。
- 查询所有CN上开始时间介于“2019-09-10 15:30:00”和“2019-09-10 15:35:00”之间的query,每个CN最多返回10条记录
1
SELECT * FROM pgxc_get_wlm_session_info_bytime('start_time', '2019-09-10 15:30:00', '2019-09-10 15:35:00', 10);
- 查询所有CN上结束时间介于“2019-09-10 15:30:00”和“2019-09-10 15:35:00”之间的query,每个CN最多返回10条记录
1
SELECT * FROM pgxc_get_wlm_session_info_bytime('finish_time', '2019-09-10 15:30:00', '2019-09-10 15:35:00', 10);
- 通过视图gs_wlm_operator_history查询当前CN作业算子最近执行资源信息。要查到记录,必须保证resource_track_level为operator。
1
SELECT * FROM gs_wlm_operator_history;
- 通过视图pgxc_wlm_operator_history查询所有CN作业算子最近执行资源信息。要查到记录,必须保证resource_track_level为operator。
1
SELECT * FROM pgxc_wlm_operator_history;
- 通过数据表gs_wlm_operator_info查询当前CN作业算子历史执行资源信息。要查到记录,必须保证resource_track_level为operator和enable_resource_record为on。
1
SELECT * FROM gs_wlm_operator_info;
- 通过视图pgxc_wlm_operator_info查询所有CN作业算子历史执行资源信息。要查到记录,必须保证resource_track_level为operator和enable_resource_record为on。
1
SELECT * FROM pgxc_wlm_operator_info;
- 对于上述的视图信息,由于预设内存的限制,内存中能够保留的数据记录数量有限,实时查询在结束后会导入到历史相关的视图中。关于记录上限,对于query级别视图,当新的需要记录的查询超过内存约束记录数上限时,则当前查询无法记录,下条查询重新进行规则判断;在每个CN上,记query级别历史视图的内存占用(默认100MB)可通过PG_TOTAL_MEMORY_DETAIL视图进行查询。
- 对于算子级别视图,当需要记录的查询的plan_node数量加上当前内存中已有的记录数量超过内存约束记录数上限时,则当前查询的所有算子节点不记录,下条查询重新按照算子规则判定。在每个CN上,算子级别视图在内存中可记录的最大实时和历史记录数分别为max_oper_realt_num(当前系统值为56987),max_oper_hist_num(113975);记当前用户业务系统的平均每个查询的节点数为num_plan_node,则在每个CN上,实时视图允许客户执行的最大并发数: num_realt_active = max_oper_realt_num/num_plan_node;历史视图允许客户执行的最大并发数:num_hist_active = max_oper_hist_num/(180/run_time)/num_plan_node。
- 如果并发过高,避免需要记录的查询数量超过query级别视图和算子级别视图的值,可以通过参数session_history_memory修改历史查询视图的内存,内存增大和查询数量成正比。
父主题: GaussDB(DWS)资源监控