MSSQL · 实现分析 · Extend Event实现审计日志对SQL Server性能影响

  • 时间:
  • 浏览:2



将以上文字描述的数字出理 做成一3个多直观的图形,大伙发现在开启Extend Event实现审计日志功能时,对于单条句子查询性能的影响最大约为0.01%;而对于单句子查询吞吐量的影响不超过0.01%。

使用主键范围查找的千查询迭代次数做图如下:



可靠性

测试环境详情截图如下:

背景

从你你是什么数量级别来看,Extend Event实现审计日志功能平均每天吞吐量可不时要达到4亿5千万条审计日志记录;生成457.92GB审计日志文件,完正可不时要满足大伙的业务要求吞吐量了。

使用系统提供的函数sys.fn_xe_file_target_read_file读取Extend Event生成的审计日文件记录总数,展示也是3189637条,你你是什么记录总数和SQL Profiler抓取到的记录数是恰好吻合。



首先,时要说明一下测试环境,我的所有测试数据量化结果也有基于我的测试环境的而得出来的。肯能用户测试环境的配置不同,肯能会得到不同的测试量化数据。我的测试环境介绍如下。

测试并且,对测试数据的定性分析逻辑是:

Extend Event Session对象创建

使用Create Event Session On Server句子创建基于实例级别的Extended Event。句子如下:

使用SQLTest,在开启不同数量的并发查询应用任务管理器请况下,获取到的千查询平均时间消耗数据统计如下: 千查询平均耗时统计数据表格

主键范围千查询

千查询迭代次数总结

同样,大伙可不时要直观的发现以下规律:

从你你是什么图,大伙可不时要做如下总结:

从你你是什么图,大伙可不时要做如下总结:

对SQL Server性能影响

千查询测试句子:可是我针对某个查询句子循环4000次。

你你是什么小节从另外一3个多深度1来看Extend Event对SQL Server性能的影响,让大伙来看看在单位时间内(1分钟内)千查询迭代次数。千查询迭代次数统计表格

在上一篇月报分享中,大伙介绍了SQL Server实现审计日志功能的某种措施,最终的结论是使用Extend Event(中文叫扩展事件)实现审计日志措施是最优选择,详情参见MSSQL · 实现分析 · SQL Server实现审计日志的方案探索。这麼,使用Extend Event实现审计日志的方案会面对如下问题图片:

测试措施:使用SQLTest,分别测试在1、2、4、8、16、33个多并发应用任务管理器请况下,单位时间内(1分钟)千查询的平均迭代次数和时间消耗。

可靠性测试是保证Extend Event在抓取审计日志时的稳定性和功能健壮性,简单讲可是我“不丢数据”,而吞吐量的测试是要回答“Extend Event到底在多大的查询吞吐量时,依然都都都可否工作良好?”。就可靠性测试的大伙来简单推算一下:10分钟的测试,共执行3189637条查询,生成了3.18GB的审计日志文件,以此来推算每秒,每分钟,每小时,每天可不时要抓取到的查询记录数和产生的日志文件大小,如下图计算所示:

主机: Mac OS X 10.11.6系统上VM主机 CPU:i7-4770 2.2GHz 4 Cores 4 Logical Processor Memory: 5GB Storage: SSD SQL Server:SQL Server 4008R2 测试工具:SQLTest 1.0.45.0 SQL Server哪有几个关键的配置:max degree of parallelism和max server memory (MB)均采用默认值。



单主键千查询

测试环境介绍

为了测试Extend Event对用户SQL Server实例的性能影响,大伙的思路是在停止和启用Extend Event Session的场景下,统计一千条相同查询(简称千查询)在不同数量并发应用任务管理器请况下时间消耗和单位时间内(以1分钟为单位)的迭代次数,最终以得到的测试数据做为标准。

在选择使用Extend Event实现审计日志功能的出理 方案并且,该技术方案可行性和吞吐量直接关系到产品的稳定性和功能延续性,哪哪有几个形状对于审计日志功能都非常重要,大伙时要经过严格的可靠性和吞吐量测试,以确保Extend Event技术方案满足这两方面的要求的并肩,又不想对SQL Server某种性能和吞吐量造成大的影响(假设条句子性能和吞吐量影响超过5%定义为大的影响)。

其中:



根据以上对千查询迭代次数数据和做图,总结如下: 无论是基于主键的单值查询句子,还是主键的范围查询句子,禁用和启用Extend Event Session,千查询的迭代次数差异不想说大,在并发应用任务管理器为4的并且,差异达到最小值;千查询迭代次数差异为85和8次,启用Extend Event Session后,对千查询在主键查找和主键范围查找场景下,迭代次数影响为9.47%和5.63%;单查询平均迭代次数影响分别为0.00947%和0.00563%。

定性分析

千查询平均耗时



建立测试对象表:创建测试表tab72,并初始化20万条数据。

使用单主键查找的千查询平均时间消耗图

可靠性测试的措施是,大伙使用SQLTest工具开3个多并发应用任务管理器执行查询句子,持续运行10分钟时间,并肩,使用Profiler抓取SQL:stmtCompleted事件(功能和Extend Event事件sql_statement_completed功能相同),来校验Extend Event抓取的记录数,肯能两者的记录数相同说明Extend Event满足可靠性要求。在测试的短短10分钟左右时间内,查看Profiler抓取到的记录数为3189637,总共310多万条记录,参见如下截图:

根据以上对千查询平均耗时统计数据和做图,总结如下: 无论是基于主键的单值查询句子,还是主键的范围查询句子,禁用和启用Extend Event Session,对于千查询的平均耗时差异不大,在并发应用任务管理器为4的并且,差异最小;千查询平均耗时差异为29毫秒和58毫秒,性能影响为10.74%和3.39%;单句子查询平均耗影响分别为0.01074%和0.00339%。

在启用了Extend Event Session抓取审计日志并且,对用户SQL Server实例性能影响的量化分析总结如下:

从你你是什么量化分析的总结来看,Extend Event对用户SQL Server性能影响是,千查询句子的性能影响在3% ~ 10%之间;单条句子查询性能和吞吐量损失均在0.01%小幅波动,你你是什么影响相对于Profiler肯能非常小了。怎么让 ,方案可行,怎么让 影响在可控的范围内。

从测试的结果来看,Extend Event实现审计日志功能可靠性有保证,在10分钟310多万条句子执行的压力下,依然可不时要工作良好。 

其中,表格每行数据表示千查询迭代次数,第一列与千查询平均时间消耗表达含义相似,这里不再累述。

Extended Event Session对象创建完毕后,时要启动你你是什么session对象,措施如下:



平均耗时总结

使用单主键千查询在单位时间内的迭代次数统计数据,做图如下:

测试措施





使用主键范围查找的千查询平均时间消耗图

千查询迭代次数



而,Extend Event总共生成了34一3个多审计日志文件,每个日志文件最大大小为10MB(这里调整了最多的文件数量为4000,以满足测试产生的数据要求),总共大小为近3.18GB。

环境配置

从图表直观反映,大伙可不时要发现如下规律:

这篇文章可是我围绕这哪有几个问题图片的量化分析来展开的。

主键范围千查询

性能影响总结

可靠性和吞吐量测试

将“千查询平均耗时统计数据表格”数据,做成EChart图,我直观的来看看平均时间消耗差异。