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

從測試的數據能夠發現：

一、數據庫的audit插件的使用，確實損耗了必定的數據庫性能，若是以最佳壓測性能的128個線程併發的數據來看，有audit功能的數據庫在同等壓測時間下，事務數佔比少了30%以上，響應時間延長了1倍。

二、數據庫性能並不是同併發線程數呈線性關係，在併發數達到128時，事務數和響應時間均爲最佳，接下來再繼續增長併發，性能反而降低。

三、這裏測試數據sync_binlog和innodb_flush_log_at_trx_commit爲雙1的時候，性能反而最高。這裏應該是參數調整or壓測時間不足致使。至少innodb_buffer_pool_size應該調整爲內存的80%。因此這份測試數據也僅僅做爲參考，須要再繼續調整參數後再進行壓測才能獲得更爲準確的數值。