这篇文章主要讲解了“分析数据库实例性能调优利器Performance Insights”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“分析数据库实例性能调优利器Performance Insights”吧！
阿里云RDS Performance Insights是RDS CloudDBA产品一项专注于用户数据库实例性能调优、负载监控和关联分析的利器，以简单直观的方式帮助用户迅速评估数据库负载，资源等待的源头和对应SQL查询语句，以此来指导用户在何时、何处、采取何种行动进行数据性能优化。
Performance Insights：中文翻译过来叫性能洞察。
Active Session （AS）：RDS数据库系统中，活跃的会话数量。
Average Active Session （AAS）：一段时间内，RDS数据库中平均活跃会话数量。
Max Vcores：RDS数据库实例大可以使用到的CPU Cores数量。
AAS和MaxVcores来量化系统瓶颈
在文章开始，我们希望能够把一个非常重要的问题解释清楚：为什么可以使用AAS （平均活跃会话数）与RDS数据库实例MaxVcores量化对比来作为系统瓶颈的判断依据？我们的理由是：
首先，RDS数据库系统中，我们认为最为重要的资源是CPU资源，因为其他所有资源都需要CPU来调度。
其次，CPU的并发处理能力，与CPU Cores的数量相关。假设在相当小的一个时间切片上，CPU对活跃会话（AS）处理能力瓶颈就是CPU Cores数量。即：CPU最多同时能够处理与Cores数量均等的活跃会话数。
因此，我们可以用RDS数据库系统中，平均活跃会话（AAS）数与MaxVcores数的量化对比，做为判定系统是否存在瓶颈的重要依据。
阿里云RDS Performance Insights能够帮助我们的用户快速方便、直接了当的发现数据库实例负载，以及导致性能问题的SQL语句。目前Performance Insights页面以三个方面承载我们的产品思路：
关键性能指标趋势图：关键资源利用率变化趋势图。
实时AAS变化趋势图：数据库实例中平均活跃会话（Average Active Sessions）实时变化趋势。
多维负载信息：展示多维度实例负载信息。
关键资源利用率趋势图
阿里云RDS Performance Insights关键性能指标的趋势图，可以从宏观的角度帮助客户发现实例负载的来源，比如：到底是CPU资源吃紧，IOPS过高？还是网络开销过大，又或是活跃连接数打满？
实时AAS变化趋势图
从关键资源利用率趋势图部分，我们已经大致清楚了实例负载的来源。接下来，带着这个问题，我们去看看目前实例中活跃会话的资源等待情况。那么，此时我们可以来到页面的第二个部分：实时AAS变化趋势图。
从Performance Insights中的实时AAS变化趋势图中，我们可以非常清晰的发现RDS实例中的资源等待情况。比如上图，我们可以分析出以下重要信息：
时间10:25 - 10:57之间，平均活跃会话远远大于实例CPU Cores数量24（几个点低于CPU Cores），说明数据库已经面临比较大的系统瓶颈。
从AAS变化趋势图来看，几乎是在等待蓝色标示的资源，即CPU资源。
由此可见，我们使用Performance Insights中的实时AAS变化趋势图，可以非常清晰简单，直接了当的找到用户RDS实例负载来源，资源等待于何时、何处，以及变化规律。
多维度负载详情
通Performance Insights中的实时AAS变化趋势图，掌握了实例负载来源，资源等待及变化规律，接下来用户理所应当最关心的一个问题便是：到底导致这些实例负载的具体查询语句是什么？哪个用户导致的？哪个连接主机客户端？哪个应用数据库？这一系列的问题我们可以使用多维负载信息部分来解答。
从以上截图的下半部分，我们可以方便的找出与AAS变化趋势关联的负载对应的SQL查询语句，以及每个语句对AAS的贡献的对比情况。当然，您也可以根据自己的需要切换为Waits，Users，Hosts，Commands，Databases和Status，分别表示资源等待，用户，客户端主机，命令类型，数据库，进程状态等维度查看。
Performance Insights架构
了解阿里云RDS Performance Insights能够做什么以后，让我们来看Performance Insights的设计架构图，简要概括为五个字：四层两链路。
四层架构
RDS Performance Insights四层架构从上往下，依次为：
应用层：前端用户可见，承载着我们产品的思路和逻辑，是终端用户可见的产品呈现。
服务层：各系统API协调工作，为应用层提供应用数据服务，我们产品主要的业务逻辑处理层。
数据层：数据实时处理平台，统计汇总，数据扁平化，实时计算，最终持久化到元数据库中，为服务层提供数据。
采集层：从RDS实例中，采集有价值的基础数据，为数据层输入数据。
两条链路
从数据链路来看Performance Insights，有两条链路：
访问链路：数据至上而下请求访问，至下而上的数据返回。
采集链路：数据从生产到消费，从统计汇总到最终落库整个生命过程。
典型案例
以下两个典型案例，来看看Performance Insights如何一目了然，一针见血的帮助我们诊断分析数据库系统瓶颈，资源等待和SQL查询语句。
为什么CPU 100%了
XXX时间点SQL查询变慢了
为什么CPU 100%了？
在我们多年的专家服务过程中， 遇到最多的用户问题便是“为什么我的CPU 100%了”，来看看Performance Insights是如何庖丁解牛这个问题。
Performance Insights截图
以下是该RDS实例，Performance Insights页面截图。
分析
我们从Performance Insights页面截图分析出以下几个问题：
从资源利用率中CPU使用率和活跃会话数量来看：大概在 09:59 - 10:05，均有大幅上升。CPU使用率达到了100%，活跃会话（Active Sessions）达到了400+；
AAS变化趋势中发现，这段时间内，系统瓶颈主要集中在CPU和Lock两资源的等待，总的Active Sessions数远远超过CPU Cores（实例的CPU Cores为16），存在严重的系统瓶颈。
SQL语句详情部分：非常清晰的看到排在第一位的SQL查询语句是等待CPU资源，达到了96个活跃会话；第二位是Lock资源等待，达到了79个会话，可以点击SQL语句，查看详情。
XXX时间点SQL查询变慢了
另外，用户经常遇到的一个问题是“为什么我的SQL查询语句突然变慢了”？
Performance Insights截图
某RDS实例用户反馈在16:05左右，原本执行很快的Update语句，突然变得很慢，16:08左右恢复正常，以下是该RDS实例
从Performance Insights，我们可以分析出：
从AAS变化趋势图中，发现大约从16:05:50秒开始，系统出现了大量等待Lock资源的活跃会话（图中橙色颜色区域），达到了33个，远超CPU Cores数。
从截图最下部分SQL查询中，发现等待Lock资源的SQL语句（第一条，橙色标示），恰巧是用户抱怨变慢的Update操作语句。于是我们可以很快断定，这个Update变慢的原因是资源被锁住，导致等待锁资源释放时间过长，拉长了执行时间，即Update语句变慢了。
从AAS变化趋势图中，发现大约在16:07:20左右，等待锁资源的活跃进程消失了，Update语句性能恢复正常，说明锁资源已经释放。
以上，我们从两个特定的用户案例可以看到Performance Insights可以简单直观，轻松愉悦的帮助用户诊断问题，关联分析系统瓶颈，资源等待和SQL查询，取得了非常好的效果。
伴随阿里云RDS Performance Insights第一期发布，我们已经可以帮助用户快速发现RDS实例性能问题，以及导致性能问题的具体SQL查询。但是，这远远不够，我们还需要更深入的帮助我们的客户自动化、智能化解决问题。
当前，用户通过阿里云RDS Performance Insights找到了导致性能问题的具体查询SQL语句后，接下来很自然的一个问题是，为什么这个查询语句会导致性能问题？是缺失必要的索引？统计信息数据倾斜？查询数据类型转换？Non-SARG查询等等？接下来，我们需要深入探索为什么SQL会导致性能问题。
当用户知道了SQL语句为什么有性能问题以后，接下来的问题便是：我该怎么做才能解决性能问题？我们需要明确告诉用户怎么办就能够解决性能问题。
随着用户能够解决SQL语句性能问题以后，用户接下来最为迫切的需求便是：阿里云能否帮我们预先发现、智能化、自动化处理解决这些类似的问题？
感谢各位的阅读，以上就是“分析数据库实例性能调优利器Performance Insights”的内容了，经过本文的学习后，相信大家对分析数据库实例性能调优利器Performance Insights这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是创新互联，小编将为大家推送更多相关知识点的文章，欢迎关注！
