GaussDB for DWS 负载管理核心技术解密二： 白话历史资源监视

文章目录

1. 负载管理简介

2. 资源监视功能介绍

负载管理(WLM)简介

对于任何一个分布式数据库而言，无论数据库集群规模有多大，其计算资源（CPU、内存）与存储资源（磁盘空间、网络、IO）总归是有上限的。对于数据仓库应用而言，随着业务规模的逐日累积，当数据量或者查询作业达到一定的规模，不同组织、不同用户之前的必然会出现计算、存储资源的争抢，在无人干预的情况下，数据库系统通常会“笨”的想着把你的所有业务都尽可能快的执行完，通常会导致所有的业务执行速度都变慢了。GaussDB 负载管理（WLM）存在的目的就是为了让资源的分配合理化，重要的作业优先运行，次要的作业在资源不足情况下避免争抢他人资源。

当然，如何能用好GaussDB 负载管理（WLM）的配置功能，不是一件一蹴而就的事情，业务是复杂的，一个组织/用户的运行作业是计算密集型还是存储密集型，往往通过猜得到的结果是背道而驰的。这也是本文存在的意义，希望读者能够通过GaussDB所提供的资源监视功能，将资源监视功能作为有效的度量工具，来衡量各组织/用户的资源争抢情况，进而通过负载管理功能做好计算/存储资源的划分，让你的数据库“聪明”起来。

资源监视功能介绍

对于用户而言，数据库负载不高的情况下，通常不会在意数据库里面跑了什么作业，通常当用户察觉到作业变慢的时候，才会开始琢磨作业为什么慢了，是不是数据库里面有别的作业影响到我了。此时，用户将会找到管理员，要求解决性能劣化的问题。而用户给管理员提供的信息会非常简单，在什么时间执行了一个什么语句，以前这个语句几分钟能够运行结束，现在要多长时间才能跑完。并且，劣化作业有可能因业务原因，不能随意执行，无法让管理员去复现定位。管理员只能等到数据库系统中，依据这简单的信息，期望能发现一些线索。GaussDB提供了完善的资源监视功能，能够帮助管理员在这两个信息的基础上分析历史某个时间点发生的问题。

总结一下，管理员现在拿到的信息：1) 作业执行起始时间；2) 用户名; 3) 作业的SQL语句。

下面，请跟随我以管理员的视角，在有限信息的情况下，来逐层递进分析，找到作业“慢”在哪。

功能一：历史TopSQL

GaussDB 提供了记录所有在数据库中执行SQL语句的功能，管理员可以通过打开enable_resource_track开关来启用这个功能，并且可以调整resource_track_duration参数来过滤掉执行时间较短的作业，着重于分析执行时长较长的作业。GaussDB 提供记录历史TopSQL这一功能的目的，就是为了方便用户做性能调优，TopSQL的数据表pgxc_wlm_session_history中详细记录了作业的执行时间、内存消耗、下盘量、CPU消耗、IO占用等信息，在业务变更、作业变更前后，可通过对比来分析SQL是否出现劣化。

数据表pgxc_wlm_session_history提供的关键信息简述如表格，管理员能够分析的可能现象也在表格中：

A1: block_time较大，而duration值并无明显变化，说明用户作业受其它作业影响，在真正开始执行前进行了较长时间的排队，下一步需要接着查看本数据表，统计起始时间小于start_time、结束时间大于finish_time的作业数量。

A2: block_time较小，而duration值较大，说明用户作业执行时间增加较大原因是自己导致，需要继续分析数据量的变化情况、各DN的执行时间变化。

abort_info

min_peak_memory

B1: 对于同一个查询，可对比前后几次的内存消耗情况，内存消耗平均值能够反映出数据表的数据量是否有变化，memory_skew_percent值能够侧面反映出相关数据表在各DN上的数据分布是否有倾斜。

并且，query_plan能够直接显示作业的执行计划，对比执行计划是否有变化。

max_peak_memory

average_peak_memory

语句执行过程中的内存使用平均值，单位MB。

memory_skew_percent

max_spill_size

average_spill_siz

spill_skew_percent

min_dn_time

max_dn_time

语句在所有DN上的平均执行时间，单位ms。

语句在各DN间的执行时间倾斜率。

min_cpu_time

max_cpu_time

total_cpu_time

语句在所有DN上的CPU总时间，单位ms。

min_peak_iops

max_peak_iops

average_peak_iops

iops_skew_percent

总结一下：

因数据量变化，导致作业执行时间增加，可以分析A2/B1/D1/G1，进而确认作业查询的数据表是否有明显的数据量增加；

因其它并发作业抢占，导致作业排队，从而导致作业执行时间增加，可以分析A1/B1/D1，进而查看作业执行的同时期是否有大量并发作业在执行；

因其它作业而产生的CPU抢占，导致作业执行时间增加，可以分析A2/D1/E1，进而查看作业执行的同时期是否有大量并发作业在执行；

因其它作业而产生的IO抢占，导致作业执行时间增加，可以分析A2/F1，进而查看作业执行的同时期是否有大量并发作业在执行；

值得注意的是，发生资源争抢时，可能会出现并发症，即CPU、IO抢占，作业排队现象都会发生，针对并发症问题，可以逐步分析解决，比如：第一步，调整作业执行顺序，减少并发作业数量，减少阻塞时间；第二步，定位出同时段执行的典型计算密集型、存储密集型作业，先移动到其它时间段执行，减少对本作业的影响；第三步，在无其他作业明显干预的情况下，做进一步分析，

功能二：历史用户资源占用

如果无其它作业影响，TopSQL一张数据表基本已经能够分析出性能劣化缘由；但如果分析出受其它作业影响，那么接下来就是查找可能造成影响的作业。除了在TopSQL中查询执行周期内的作业信息之外，还可以借助历史用户资源占用系统表GS_WLM_USER_RESOURCE_HISTORY，来搜索“可疑”用户。“可疑”用户通常对数据库性能优化没有太多理解，往往会出现“select *”查询，或者一次提交大批量作业。GS_WLM_USER_RESOURCE_HISTORY系统表记录了所有用户的历史资源占有情况，结合反馈性能劣化的用户名以及作业执行时间段，从历史用户资源占用表中或许可以分析出是否有“可疑”用户影响。

数据表GS_WLM_USER_RESOURCE_HISTORY提供的关键信息简述如表格，管理员能够分析的可能现象也在表格中：

历史用户资源占用数据表能够非常直观的看出哪个用户占用了资源，而且是占用了哪类资源，管理员可疑进一步分析这些资源占用是否合理，进而通过资源管理(WLM)的管控能力，做合理的用户资源划分。

功能三：历史实例资源监视

在TopSQL、用户资源占用的数据表的基础上，基本能够分析出劣化原因，从而能做出相应的措施。此外，有一类问题比较独特，危害较大，DN负载不均衡或者DN劣化(硬件缘由)，在数据表分布不均的情况下，可能会导致一系列SQL都会出现执行倾斜的情况，变相拉长所有作业的执行时间，TopSQL中相关SQL的倾斜值较大。针对此类问题，如果没有用户提出作业变慢的情况下，管理员如何能够提前预防呢？

GaussDB 提供了记录CN、DN资源使用量的能力，该类数据会保存到GS_WLM_INSTANCE_HISTORY数据表中，包含：CPU、内存、IO等信息。如下列表所示：

B1: io_util&io_await能够反应出磁盘的繁忙程度，disk_read&disk_write是发生的实际IO流量值，如果磁盘很繁忙，但实际IO流量值不高，可以进一步分析磁盘是否有坏道，是否有硬件故障。

B2: 如果磁盘很繁忙，实际IO流量也很高，但是process_read&process_write却较低，说明造成磁盘繁忙的原因并不是该GaussDB实例，可能是备机catchup或者其它运行在该磁盘上的程序消耗了大量IO，可做进一步定位。

B3: 通常情况下，logical_read/logical_write远大于process_read/process_write，这是因为磁盘预读+较好的缓存命中率导致的；如果两者相近，说明缓存命中率很低，进而分析是否需要vacuum或者数据表的定义是否符合查询的就近原则。

总结：

本文从用户提出作业变慢这一问题作为出发点，从管理员视角，对已经发生的问题做定位定界，GaussDB 具备将瞬息万变的负载情况记录下来，提供回看数据库系统内部资源负载情况的能力。本文的管理员从作业、用户、DN三个层次，自上而下的顺序层层分析性能劣化的缘由。当然，读者可以从任意视角、以任意顺序去分析系统负载情况。

本文重点是介绍了GaussDB 负载管理(WLM)提供的资源监视能力，结合所提供的监控项，能够分析出一些有趣的资源争抢现象，便于读者理解监控项的含义，方便读者对监控项的二次利用。那么，下一篇将会接着介绍负载管理(WLM)所提供的其它能力，如：存储空间管理、计算资源管理等，敬请期待，谢谢。

DWS EI企业智能

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。