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%。所以这份测试数据也仅仅作为参考,需要再继续调整参数后再进行压测才能得到更为准确的数值。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Vbs 清理备份数据-保留数据量
Vbs 清理备份数据-保留数据量 我们前面文章介绍了,通过vbs脚本对文件进行压缩备份,但是通过计划任务备份的话,备份的数据会越来越多,对于我们的磁盘空间利用来说比较浪费,所以我们又通过以下 脚本进行判断,将多余的备份数据清理, 我们需要将D盘下的backup目录下的备份数据只保留3份,其他的删除。 备份数据脚本见上一篇文章。 Setdic=CreateObject("scripting.dictionary") setfso=CreateObject("Scripting.FileSystemObject") dest="c:\test\" Lcount=2 filecount(dest) dicdelete(Lcount) Subdicdelete(fcount) DoWhile(dic.Count>Lcount) keys=dic.Keys old=keys(0) ForEachkeyInkeys Ifold<keyThen old=key EndIf Next file=dic.Item(old) fso.DeleteFiledic.Item(old) dic.Re...
- 下一篇
一个无线网卡引发的血案
经常听说一个馒头引发血案,今天我要说的是一个无线网卡的故事...... 最近有同事反应无线网卡连接公司网络无法正常连接,但是连接家里的网络是OK了,于是让桌面支持的同事检测了一下,结果他们把系统重新安装了也还是不能够正常连接,为此只能自己出马了; 1、更新驱动至最新版 查看了一下网卡型号为Intel wireless-N 1030 ,于是下载了一个最新的网卡驱动给其安装了Wifi_Intel_Win7_32_VER15312.zip 2、开启无线事件记录功能 采集日志发现以下错误: #Event,Source,Time,Error Severity,Domain,User,Description 1,S24EvMon,05/05/2016 10:22:04,Information,General,SYSTEM,DeviceIoCtrlS24NDIS: (2) Failed to send OID 0xff100055 to driver. Error - 31 2,S24EvMon,05/05/2016 10:22:04,Information,General,SYSTEM,D...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- MySQL8.0.19开启GTID主从同步CentOS8
- Mario游戏-低调大师作品
- Linux系统CentOS6、CentOS7手动修改IP地址
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7安装Docker,走上虚拟化容器引擎之路
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题