【走进RDS】之SQL Server性能诊断案例分析

本文涉及的产品
云数据库 RDS SQL Server,基础系列 2核4GB
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云原生数据库 PolarDB 分布式版,标准版 2核8GB
简介: 数据库性能诊断不仅对其数据库技能要求较高,而且需要大量的前期准备工作,如收集各种性能基线、性能指标和慢SQL日志等,尤其是面对多数据库性能调优时,往往事倍功半。

客户的困扰

前几天某程序员小王向阿里云咨询他的SQL Server数据库整体负载较高,是否有优化的方法?前几天另外一个工单则是需要阿里云工程师帮忙定位某一个时刻的数据库性能尖刺的问题。


这些都是常见的性能诊断工单,其实数据库性能诊断不仅对其数据库技能要求较高,而且需要大量的前期准备工作,如收集各种性能基线、性能指标和慢SQL日志等,尤其是面对多数据库性能调优时,往往事倍功半。


如何评估数据库负载情况?如何评估数据库

当问到,如何评估数据库负载时,不同角色可能想到不同的方法,例如以下几种:


  • QPS/TPS
  • 资源使用: IOPS CPU 内存
  • SQL执行时间
  • 并发量
  • Application业务反馈


上述每一种评价方法都较为片面且作为对实际调优的参考也较为困难。


通常情况下,我们评价数据库资源负载是一个较为复杂的事情,需要我们对关系数据库有一个较为全面的理解才行,但作为数据库的使用者,大多数人不需要对数据库进行深入学习,因此,我们倾向于简化指标。


比如说,我们会只看CPU、IO、内存等指标看数据库是否存在问题,这些指标适用于监控大多数应用,但对于数据库来说可能并不能够较为正确的反映数据库内发生了什么,以及我们该如何处理。我们还要结合很多数据库特有的指标综合判断,比如各种SQL Server专用的性能计数器、DMV、等待类型、长事务、网络、活动连接等等。但这些信息需要我们对数据库自身有一个高级的了解,这使得评估数据库的负载成为一个较高门槛的工作。


下面我们不妨换一个思路,关系数据库本身是一个同步调用的过程,也就是说,从应用程序发起SQL,到数据库返回结果,是同步的,数据库不完成该请求,那么应用程序无法收到结果,在此期间应用程序与数据库之间的Session就是所谓的“Active”状态,因此我们可以尝试不再从资源使用的角度出发评估数据库负载,而简化为一个简单的指标-AAS(Average Active Session),也就是活跃会话数量。


什么是AAS概念?

设想一下,当你开车去一个目的地时,你更关注的是什么?目的地的距离?路上是否堵车?到目的地是否有停车位置?等等


你会关心汽车状态吗?或许会,但你需要了解发动机原理、汽车的相关原理才能正确判断车的状态是否正常吗?我们只需通过仪表盘几个简单的指标和报警灯做一个简单的判断即可。


数据库也是一样,绝大多数用户的场景并不需要理解数据库引擎底层原理,而是更多关注如何使用数据库,当然发烧友另说。


我们通过使用AAS的概念,提供了一种简单、抽象的评估方法,也就是数据库的活动连接数来衡量数据库的总体负载,以及每种SQL对负载的贡献,把数据库各种metric汇总为一个简单的指标----AAS。


从而使得用户使用该抽象的概念评估数据库负载,用户仅需要对比AAS与CPU核数来评估当前负载是否超出当前实例的能力,这极大的降低了用户需要对数据库技能的要求,用户可以花更多精力在业务逻辑而不是数据库技术细节上。优化器、执行计划、执行引擎,Buffer Pool,这些数据库的技术细节我们都可以减少了解。


一个AAS概念简单的图形示例如图1所示:

image.png

图1.简单的性能洞察示例


横轴Time为时间,假设有3个长连接(也就是上图中的User),每个连接根据应用负载向数据库发送SQL请求,当时间为1时,User1连接正在执行SQL,并使用CPU资源,User2正在等待锁资源,User3没有负载,因此时间1的AAS值为2,时间2的AAS值为3,以此类推。


那么AAS的值是2还是3究竟是高还是低?这取决于当前数据库所拥有的CPU Core数量,每一个Core维护一个完整的SQL执行周期,如图2所示:

image.png

图2.SQL执行时每个CPU的调度状态


当AAS值<=CPU核数时,通常来讲数据库的负载没有额外等待,当前负载不需要额外等待其他CPU的调度,是AAS比较理想的状态。


设想一个场景,你作为数据库的运维人员,开发或业务方找到你说,嗨,数据库出问题了。通过AAS,你可以简单的根据AAS一个指标,初步缩小排查范围,确定问题是否真正的出在数据库。


一个简单的AAS与实例核数的对比关系如下:


  • AAS ≈0   数据库无明显负载,异常在应用侧
  • AAS < 1   数据库无阻塞
  • AAS< Max CPUs  有空余CPU核,但可能存在单个Session打满或资源(OLAP)
  • AAS> Max CPUs 可能存在性能问题,但存在特殊情况
  • AAS>> Max CPUs 存在严重性能问题,但存在特殊情况


案例解决

通过图3我们可以看到性能洞察功能的UI,该功能的入口如图

image.png

图3.性能洞察的一个典型UI


上下两部分,上部分是按时间序列展示每个时间段的AAS负载情况,下部分是按照不同维度由高到底展示不同维度资源所占的负载,默认以SQL维度为主。


上部分可以看到各时间段负载,每种资源所占比例,比如图中蓝色展示的是CPU,其中重要的是当前实例规格的核数(max Vcores: 32),如果AAS值超过实例所拥有的CPU核数,我们就知道当前实例负载处于超标状态,图3所示负载一直处于10左右,低于Max Vcores 32,可以知道数据库整体负载处于健康水位。


那从哪知道这些负载的来源?可以通过图3下面的部分看到对应的SQL,以及每个SQL所贡献的AAS比例,例如图中可以看到第一条SQL全部为橙色,值为1.7056,该值说明在给定时间段内,该语句存在的平均会话是1.7次。而主要是等待Lock资源,这说明该语句的瓶颈在于锁。


因此我们注意到第一个语句AAS贡献最高,且等待瓶颈在于锁,根据图4数据库调优的抽象方法论,就解决了两个问题“缩小范围”和“定位瓶颈”两个问题:

image.png

图4.性能调优4个步骤


通俗点说,也就是解决了下面两个问题:

  • 哪些SQL在特定时间对实例的负载影响最大
  • 这些SQL为什么慢


而具体如何实施优化,以及如何验证优化效果,会在后续文章中进行讲述。


USE CASE1:快速优化整体负载情况

80 20法则同样适用于数据库,80%的负载都是由20%的 SQL产生,也就是说只要优化这20%的SQL就已经完成了80%的优化工作,进一步想,如果20%中的20%,也就是4%,优化这部分岂不是就可以完成80%*80%=64%的工作。因此很多场景下,优化头部的几个SQL就能完成绝大多数优化工作。

image.png

图5.CPU 100%问题定位


图4我们可以看到,示例CPU使用率一直100%,在发生阻塞时会瞬间跌到个位数。我们观察一个小时的AAS数据,看到下面单个Select的SQL的平均AAS为78,远远超过实例8C的规格,因此只要优化这一个SQL,该实例的问题基本就能够得到解决。


通过图4的SQL“分析”功能,我们能够快速根据执行计划发现常见SQL慢的原因,包括索引缺失、参数类型转换、统计信息不准确等问题。


USE CASE2:找到特定时间段内数据库响应时间变慢的原因


这类场景也是一个经典场景,数据库整体可能较长时间处于健康水平,但在业务高峰或特定时间段,存在数据库负载压力较大,业务侧SQL较慢的场景。通常情况下,大多数数据库仅存在一些指标维度的监控,比如通用的CPU、网络、IO。或者引擎侧的指标,通常通过这些指标我们能猜测出大概范围,但难以定位到具体语句,通过AAS,我们可以通过查看特定时间段的高负载定位到导致特定时间数据库问题的语句,如图6所示:

image.png

图6.特定时间负载高


通过图6,我们可以看到在特定2分钟内有性能突发的毛刺,我们通过鼠标拖拽放大该时间范围,得到如图7所示结果

image.png

图7.拖拽后明显看到两个导致高AAS的语句


通过图7,我们可以快速定位到两个产生性能毛刺的语句,并且注意到等待类型分别为Lock与Tran Log IO,由此根据图4的调优理论,我们可以初步判断是大量的更新操作产生的日志IO负载,并由于这些语句之间的锁阻塞导致锁等待。这可以极大的降低调优成本。


回顾

通过上面的案例分析,我们最终成功帮助客户解决了问题。


今天数据库早已迈入云时代,借助阿里云RDS for SQL Server Clouddba这一免费工具,可以快速准确地降低阿里云RDS for SQL Server数据库负载优化成本与操作人员技能水平要求,从而达到将更多精力用于实现业务本身的,而不是数据库上实现细节。使用性能洞察,在云上我们可以做到不用任何额外成本,快速查看整体负载,查看负载细节,以及定位不同负载对应的SQL,从而可以帮我们在云上快速解决数据库性能问题、并定期调优整体负载。


作者信息

宋沄剑(沄迹) RDS产品部SQL Server产品线技术专家,负责SQL Server产品相关开发工作,善于分析各类疑难杂症。

关于SQL Server问题,欢迎邮箱咨询:vogts.wangt@alibaba-inc.com

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
相关文章
|
12天前
|
SQL 容灾 安全
云时代SQL Server的终极答案:阿里云 RDS SQL Server如何用异地容灾重构系统可靠性
在数字化转型的浪潮中,数据库的高可用性已成为系统稳定性的生命线。作为经历过多次生产事故的资深开发者,肯定深知传统自建SQL Server架构的脆弱性——直到遇见阿里云 RDS SQL Server,其革命性的异地容灾架构彻底改写了游戏规则。
|
4月前
|
SQL 数据采集 关系型数据库
实现MySQL与SQL Server之间数据迁移的有效方法
总的来说,从MySQL到SQL Server的数据迁移是一个涉及到很多步骤的过程,可能会遇到各种问题和挑战。但只要精心规划、仔细执行,这个任务是完全可以完成的。
256 18
|
7月前
|
SQL 关系型数据库 MySQL
基于SQL Server / MySQL进行百万条数据过滤优化方案
对百万级别数据进行高效过滤查询,需要综合使用索引、查询优化、表分区、统计信息和视图等技术手段。通过合理的数据库设计和查询优化,可以显著提升查询性能,确保系统的高效稳定运行。
231 9
|
9月前
|
SQL 存储 关系型数据库
MySQL/SqlServer跨服务器增删改查(CRUD)的一种方法
通过上述方法,MySQL和SQL Server均能够实现跨服务器的增删改查操作。MySQL通过联邦存储引擎提供了直接的跨服务器表访问,而SQL Server通过链接服务器和分布式查询实现了灵活的跨服务器数据操作。这些技术为分布式数据库管理提供了强大的支持,能够满足复杂的数据操作需求。
426 12
|
10月前
|
SQL 开发框架 .NET
突破T-SQL限制:利用CLR集成扩展RDS SQL Server的功能边界
CLR集成为SQL Server提供了强大的扩展能力,突破了T-SQL的限制,极大地拓展了SQL 的应用场景,如:复杂字符串处理、高性能计算、图像处理、机器学习集成、自定义加密解密等,使开发人员能够利用 .NET Framework的丰富功能来处理复杂的数据库任务。
|
10月前
|
监控 关系型数据库 MySQL
如何监控和诊断 MySQL 数据库的性能问题?
【10月更文挑战第28天】监控和诊断MySQL数据库的性能问题是确保数据库高效稳定运行的关键
1160 1
|
12月前
|
SQL 关系型数据库 MySQL
创建包含MySQL和SQLServer数据库所有字段类型的表的方法
创建一个既包含MySQL又包含SQL Server所有字段类型的表是一个复杂的任务,需要仔细地比较和转换数据类型。通过上述方法,可以在两个数据库系统之间建立起相互兼容的数据结构,为数据迁移和同步提供便利。这一过程不仅要考虑数据类型的直接对应,还要注意特定数据类型在不同系统中的表现差异,确保数据的一致性和完整性。
176 4
|
12月前
|
关系型数据库 MySQL 网络安全
5-10Can't connect to MySQL server on 'sh-cynosl-grp-fcs50xoa.sql.tencentcdb.com' (110)")
5-10Can't connect to MySQL server on 'sh-cynosl-grp-fcs50xoa.sql.tencentcdb.com' (110)")
|
SQL 关系型数据库 MySQL
【超全整理】SQL日期与时间函数大汇总会:MySQL与SQL Server双轨对比教学,助你轻松搞定时间数据处理难题!
【8月更文挑战第31天】本文介绍了在不同SQL数据库系统(如MySQL、SQL Server、Oracle)中常用的日期与时间函数,包括DATE、NOW()、EXTRACT()、DATE_ADD()、TIMESTAMPDIFF()及日期格式化等,并提供了具体示例。通过对比这些函数在各系统中的使用方法,帮助开发者更高效地处理日期时间数据,满足多种应用场景需求。
1451 1
|
SQL 关系型数据库 数据库
数据库空间之谜:彻底解决RDS for SQL Server的空间难题
【8月更文挑战第16天】在管理阿里云RDS for SQL Server时,合理排查与解决空间问题是确保数据库性能稳定的关键。常见问题包括数据文件增长、日志文件膨胀及索引碎片累积。利用SQL Server的动态管理视图(DMV)可有效监测文件使用情况、日志空间及索引碎片化程度。例如,使用`sp_spaceused`检查文件使用量,`sys.dm_db_log_space_usage`监控日志空间,`sys.dm_db_index_physical_stats`识别索引碎片。同时,合理的备份策略和文件组设置也有助于优化空间使用,确保数据库高效运行。
279 2

相关产品

  • 云数据库 RDS MySQL 版
  • 云数据库 RDS
  • 推荐镜像

    更多