mysql5.6加载percona版audit.log插件性能损耗压测

由于mysql5.6社区版没有企业版特有的audit审计插件,最近需要对生产的mysql数据库增加审计功能,在考虑了percona、maridb和macfee3个版本的audit,最终选择了较为熟悉的percona版。

这里注意下,最好采用同一子版本的PXC的audit_log.so文件,即下载PXC的二进制包文件并直接copy其内置的audit_log.so插件即可。

启用了audit审计功能,对数据库的性能存在一定的损耗,具体是多少,需要通过测试验证。在虚拟机上做了一个测试如下:

测试虚拟机环境:

主机:

CPU:Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz 4核

内存:1G

磁盘:SCSI硬盘 10G

数据库:

版本:5.6.34

参数: innodb_buffer_pool_size = 128M、 innodb_io_capacity = 2000

以下是我的测试脚本:cat for_sysbench.sh

#!/bin/sh
time=3600
#0.0
for thread in {16,32,64,128,256}
do
echo "now the number of theads is $thread"
echo "============================================================================================================================================"
/bin/sh /home/linzj/shell/mysql.sh restart
sleep 30
sysbench --test=oltp --mysql-host=192.168.110.100 --mysql-port=3306 --mysql-user=root --mysql-password=root --mysql-db=sbtest1 --oltp-num-tables=10 --oltp-table-size=500000 --report-interval=10  --max-requests=0 --oltp-test-mode=nontrx --oltp-nontrx-mode=select --oltp-read-only=off --max-time=$time --num-threads=$thread run
echo "============================================================================================================================================"
done >> /tmp/sysbench.log.0.0
#1.1
sed -i ‘s/sync_relay_log=0/sync_relay_log=1/g‘ /etc/my.cnf 
sed -i ‘s/sync_binlog=0/sync_binlog=1/g‘ /etc/my.cnf  
sed -i ‘s/innodb_flush_log_at_trx_commit = 0/innodb_flush_log_at_trx_commit = 1/g‘ /etc/my.cnf  
for thread in {32,256}
do
echo "now the number of theads is $thread"
echo "============================================================================================================================================"
/bin/sh /home/linzj/shell/mysql.sh restart
sleep 30
sysbench --test=oltp --mysql-host=192.168.110.100 --mysql-port=3306 --mysql-user=root --mysql-password=root --mysql-db=sbtest1 --oltp-num-tables=10 --oltp-table-size=500000 --report-interval=10  --max-requests=0 --oltp-test-mode=nontrx --oltp-nontrx-mode=select --oltp-read-only=off --max-time=$time --num-threads=$thread run
echo "============================================================================================================================================"
done >> /tmp/sysbench.log.1.1
#100.2
sed -i ‘s/sync_relay_log=1/sync_relay_log=100/g‘ /etc/my.cnf
sed -i ‘s/sync_binlog=1/sync_binlog=100/g‘ /etc/my.cnf
sed -i ‘s/innodb_flush_log_at_trx_commit = 1/innodb_flush_log_at_trx_commit = 2/g‘ /etc/my.cnf
for thread in {32,256}
do
echo "now the number of theads is $thread"
echo "============================================================================================================================================"
/bin/sh /home/linzj/shell/mysql.sh restart
sleep 30
sysbench --test=oltp --mysql-host=192.168.110.100 --mysql-port=3306 --mysql-user=root --mysql-password=root --mysql-db=sbtest1 --oltp-num-tables=10 --oltp-table-size=500000 --report-interval=10  --max-requests=0 --oltp-test-mode=nontrx --oltp-nontrx-mode=select --oltp-read-only=off --max-time=$time --num-threads=$thread run
echo "============================================================================================================================================"
done >> /tmp/sysbench.log.100.2

其实这里测试时间不应该只有3600s,表个数和行数也不是太大,如果要获得更为准确的压测值,建议调大测试时间、表的行数和线程并发数。

测试出来的数据如下:

not  audit_log.so sync_binlog=0  innodb_flush_log_at_trx_commit=0 innodb_io_capacity = 2000  innodb_buffer_pool_size = 128M sync_binlog=1  innodb_flush_log_at_trx_commit=1 innodb_io_capacity = 2000  innodb_buffer_pool_size = 128M sync_binlog=100  innodb_flush_log_at_trx_commit=2 innodb_io_capacity = 2000  innodb_buffer_pool_size = 128M
thread number transactions 95% response time transactions 95% response time transactions 95% response time
16 32213495 0.25ms 29410504 0.25ms 30523665 0.35ms
32 26159190 0.98ms 27709880 0.66ms 26933062 0.68ms
64 83298987 0.23ms 86423634 0.23ms 77157030 0.27ms
128 88715124 0.34ms 90817420 0.35ms 81349362 0.41ms
256 66369520 2.19ms 69010422 1.98ms 71505144 1.81ms
audit_log.so sync_binlog=0  innodb_flush_log_at_trx_commit=0 innodb_io_capacity = 2000  innodb_buffer_pool_size = 128M sync_binlog=1  innodb_flush_log_at_trx_commit=1 innodb_io_capacity = 2000  innodb_buffer_pool_size = 128M sync_binlog=100  innodb_flush_log_at_trx_commit=2 innodb_io_capacity = 2000  innodb_buffer_pool_size = 128M
thread number transactions 95% response time transactions 95% response time transactions 95% response time
16 28692966 0.50ms 30227040 0.44ms 30635231 0.43ms
32 26350208 0.69ms 26789217 0.64ms 26515925 0.66ms
64 58260078 0.45ms 60129266 0.41ms 62635925 0.37ms
128 61384728 0.69ms 62435697 0.67ms 64455354 0.59ms
256 55560177 2.83ms 55683833 2.87ms 56068342 2.79ms

从测试的数据可以发现:

1、数据库的audit插件的使用,确实损耗了一定的数据库性能,如果以最佳压测性能的128个线程并发的数据来看,有audit功能的数据库在同等压测时间下,事务数占比少了30%以上,响应时间延长了1倍。

2、数据库性能并非同并发线程数呈线性关系,在并发数达到128时,事务数和响应时间均为最佳,接下来再继续增加并发,性能反而下降。

3、这里测试数据sync_binlog和innodb_flush_log_at_trx_commit为双1的时候,性能反而最高。这里应该是参数调整or压测时间不足导致。至少innodb_buffer_pool_size应该调整为内存的80%。所以这份测试数据也仅仅作为参考,需要再继续调整参数后再进行压测才能得到更为准确的数值。

时间: 2024-10-26 23:35:15

mysql5.6加载percona版audit.log插件性能损耗压测的相关文章

点点点游戏之 点灯游戏   加载图片版

 /************************** http://www.592xyx.com/gameplay/14193/index.shtml 关灯游戏3 没想到会于这游戏再结缘 会的东西,不应该只是说说而已-- 纸上谈兵过后的具体实现 理论为心  技术为要 第一阶段产生地图的思考   类似而已 还是有区别的 本程序练习图像化 地图是要加载图片 更方便操作 特别地可以用到:::链表 连线本身是一个问题 **************************/   import java

CSS响应式:根据分辨路加载不同CSS的几个方法,亲测可用

有时候你需要把同一个页面在手机和pc同时打开,其中有一个办法就是判断不同分辨路加载不同的css 小编总结了几种分别加载css的方法: 1.比较复杂的使用js判断加载不同css (亲测可用) 但是这种方法只有最开始的时候会判断,如果你拖动浏览器大小是不会发生改变的(当然如果喜欢拖着玩的话) 1 <link rel="stylesheet" type="text/css" id="links" href="../css/m_wuqin

怎样在谷歌浏览器上加载金山词霸的取词插件?

1.在金山词霸的安装目录下找到XDictExtension.crx文件,例如:C:\Program Files\Kingsoft\PowerWordDict\plugin\Chrome\XDictExtension.crx:2.打开google浏览器,在右上角有个设置图标,点击进入后在菜单栏中选择:工具——扩展程序:3.将XDictExtension.crx文件直接拖到扩展程序页面中,在弹出的对话框中点击“添加”:4.重新启动google浏览器即可.

AngularJS ui-router 用resolve、service预先加载数据写法,属于优化性能方面吧

AngularJS的service怎么声明此处就不再赘述,下面的例子是ui-router中使用service的实现代码 $stateProvider.state('myState', { url: "/itemDetail/:itemId", templateUrl:"view/item.detail.html", resolve:{ //你没有看错,myData1的值是个字符串 //但是必须是个已经被声明了的service myData1: "mySer

Android-高效加载图片经验分享

int maxMemory = (int)(Runtime.getRuntime().maxMemory() / 1024); Log.d("TAG", "Max memory is" + maxMemory + "KB"); 因此在展示高分辨率图片的时候,最好先将图片进行压缩.压缩后的图片大小应该和用来展示它的控件大小相近,在一个很小的ImageView上显示一张超大的图片不会带来任何视觉上的好处,但却会占用我们相当多宝贵的内存,而且在性能上还

Android高效加载大图、多图解决方案,有效避免程序OOM(转)

本篇文章主要内容来自于Android Doc,我翻译之后又做了些加工,英文好的朋友也可以直接去读原文. http://developer.android.com/training/displaying-bitmaps/index.html 高效加载大图片 我们在编写Android程序的时候经常要用到许多图片,不同图片总是会有不同的形状.不同的大小,但在大多数情况下,这些图片都会大于我们程序所需要的大小.比如说系统图片库里展示的图片大都是用手机摄像头拍出来的,这些图片的分辨率会比我们手机屏幕的分辨

Android 大图片加载 避免OOM

文章来自郭大神:======= 转载请注明出处:http://blog.csdn.net/guolin_blog/article/details/9316683 本篇文章主要内容来自于Android Doc,我翻译之后又做了些加工,英文好的朋友也可以直接去读原文. http://developer.android.com/training/displaying-bitmaps/index.html 高效加载大图片 我们在编写Android程序的时候经常要用到许多图片,不同图片总是会有不同的形状.

Android 高效加载大图,多图解决方案,有效避免程序OOM

高效加载大图片 我们在编写Android程序的时候经常要用到许多图片,不同图片总是会有不同的形状.不同的大小,但在大多数情况下,这些图片都会大于我们程序所需要的大小.比如说系统图片库里展示的图片大都是用手机摄像头拍出来的,这些图片的分辨率会比我们手机屏幕的分辨率高得多.大家应该知道,我们编写的应用程序都是有一定内存限制的,程序占用了过高的内存就容易出现OOM(OutOfMemory)异常.我们可以通过下面的代码看出每个应用程序最高可用内存是多少. [java] view plaincopy in

android ListView的上部下拉刷新下部点击加载更多具体实现及拓展

转自:http://blog.csdn.net/jj120522/article/details/8229423 这次就不上图了,例子太多太多了,想必大家都见过.这个功能的实现,简直是开发者必备的. 我也不过多介绍了,网上详细介绍的博客太多太多了,若想深入了解,请参考网上其他博文. 在这里,我只是按照自己的理解,模拟实现了一个,顺便代码贡献出来. 我对之详细标明的注释,想必如果不懂的同学们,看注释也应该明白,前提是,你要耐心看,因为代码有点多,但是我整理过了,还算清晰. 详细代码: [java]