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

来源：互联网发布：微信抢红包透视软件编辑：程序博客网时间：2024/06/11 09:44

由于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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
#!/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.sosync_binlog=0 innodb_flush_log_at_trx_commit=0 innodb_io_capacity = 2000 innodb_buffer_pool_size = 128Msync_binlog=1 innodb_flush_log_at_trx_commit=1 innodb_io_capacity = 2000 innodb_buffer_pool_size = 128Msync_binlog=100 innodb_flush_log_at_trx_commit=2 innodb_io_capacity = 2000 innodb_buffer_pool_size = 128Mthread numbertransactions95% response timetransactions95% response timetransactions95% response time16322134950.25ms294105040.25ms305236650.35ms32261591900.98ms277098800.66ms269330620.68ms64832989870.23ms864236340.23ms771570300.27ms128887151240.34ms908174200.35ms813493620.41ms256663695202.19ms690104221.98ms715051441.81ms

audit_log.sosync_binlog=0 innodb_flush_log_at_trx_commit=0 innodb_io_capacity = 2000 innodb_buffer_pool_size = 128Msync_binlog=1 innodb_flush_log_at_trx_commit=1 innodb_io_capacity = 2000 innodb_buffer_pool_size = 128Msync_binlog=100 innodb_flush_log_at_trx_commit=2 innodb_io_capacity = 2000 innodb_buffer_pool_size = 128Mthread numbertransactions95% response timetransactions95% response timetransactions95% response time16286929660.50ms302270400.44ms306352310.43ms32263502080.69ms267892170.64ms265159250.66ms64582600780.45ms601292660.41ms626359250.37ms128613847280.69ms624356970.67ms644553540.59ms256555601772.83ms556838332.87ms560683422.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%。所以这份测试数据也仅仅作为参考，需要再继续调整参数后再进行压测才能得到更为准确的数值。

0 0