MySQL审计插件(Audit Plugin)性能测试对比

背景：

 

卖咖啡在5月份推出了MySQL Audit Plugin，经过几个月的更新，目前已经是1.0.2版本。

Oracle在收购MySQL以后，同样也在5.5的Audit API基础上推出了 MySQL Audit Plugin。

本次测试就是基于这两款产品进行的。

 

正文：

 

技术对比：

	Oracle	McAfee
试用版本	5.5 or higher	5.1 or higher
是否免费	charge	free
是否动态开关	yes	yes

 

 

原理对比：

由于 Oracle的Audit Plugin是基于 5.5新推出的  Audit API ，日志的内容受制于API提供的信息。同时也必须基于5.5及更高版本。

由于 McAfee的Audit Plugin是基于THD的offset，从内存对象中直接获取信息，因此日志可以获取更多的内核信息。同时，只要能够得到offset，理论上就能够支持所有mysql版本（即其他branch版本）

 

 

日志格式：

Oracle：XML格式，信息仅限于connection_id ，如果需要具体的用户名信息，需要反查日志获取connection event 得到IP和用户。

总体来说非常鸡肋，日志内容基本和general log 没有差别

  <AUDIT_RECORD TIMESTAMP="2012-11-07T03:04:08" NAME="Query" CONNECTION_ID="1" STATUS="0" SQLTEXT="show global variables like '%audit%'"/>

 

MaCfee： json格式，显示的记录了用户名和IP，以及涉及的表名。 由于是json格式，也能够方便的把日志导入 Mongo等其他NoSQL进行分析

能够比较直接的看到操作信息，也便于分析

{"msg-type":"activity","date":"1352258108848","thread-id":"1","query-id":"6","user":"root","priv_user":"root","host":"localhost","cmd":"show_variables","objects":[{"db":"information_schema","name":"/tmp/#sql_2e54_0","obj_type":"TABLE"}],"query":"show global variables like '%audit%'"}

 

 

日志体积：

Oracle：  1659269行  日志大小 292M = 每一千行日志 = 0.180K   团购每天Questions = 163330688 句 = 28G

MaCfee：1419020行  日志大小 431M = 每一千行日志 = 0.311K   团购每天Questions = 163330688 句 = 48G

 

Oracle由于记录的信息较少，因此文件体积也较小

 

 

 

性能比较：

MaCfee：基于percona 5.1.66

Oracle：  基于5.5.28-enterprise-commercial-advanced-log

Slowlog：基于percona 5.1.66 ， long_query_time =0 时，用于比较plugin相较slowlog之间的性能差异

测试方法：AutoPerformanceTest脚本，CPU-Bound 模式

测试结果：见下表，单位是QPS。 Base表示没有开启Audit时的基准性能； 红色数字表示开启后，相较基准的性能百分比。

 

Concurrency	MaCfee Base	Slow log		MaCfee Audit		Oracle Base	Oracle Audit
1	489.79	438.03	89%	307.43	63%	428.65	414.99	97%
2	876.68	870.44	99%	774.27	88%	874.26	858.64	98%
3	1396.44	1266.13	91%	1119.77	80%	1321.3	1272.78	96%
4	1830.44	1644.84	90%	1389.28	76%	1719.58	1650.44	96%
5	2297.53	1965	86%	1699.57	74%	2142.41	2030.47	95%
6	2703.67	2293.4	85%	1744.2	65%	2575.47	2388.21	93%
7	3114.53	2521.79	81%	1548.47	50%	2964.08	2653.88	90%
8	3539.27	2737.86	77%	1479.03	42%	3338.17	3044.49	91%
9	3919.51	2875.65	73%	1475.47	38%	3748.98	3253.33	87%
10	4330.8	2887.48	67%	1491.87	34%	4136.68	3428.16	83%
11	4672.05	2670.53	57%	1484.56	32%	4488.6	3576.04	80%
12	4971.3	2335.08	47%	1375.84	28%	4777.9	3969.61	83%
13	4976.72	2138.46	43%	1301.13	26%	4802.9	4072.96	85%

当long_query_time = 0时，开启slowlog会对并发性能产生较大影响。在9并发时达到吞吐量极限。猜测是slowlog内部有一个排他的mutex，导致了并发性能无法上升。

MaCfee在开启Audit后，性能下降了 74%左右，并在6并发时就达到了极限。可见该Plugin对于CPU的损耗非常大。 原因应该和slowlog一致。

Oracle相比之下就稍好，性能下降在85%-90%之间。

测试期间，两个plugin的IO util都在5%左右，可见日志的buffered sequence write并不是目前的瓶颈。

 

 

总结：
Oracle的Audit Plugin：功能较弱，基本等同于general log，不便于分析。居然还要收费，比较吭爹。
MaCfee的Audit Plugin：信息详尽，但是性能在高并发时很大的损耗。不具备线上使用的条件。

转载于:https://www.cnblogs.com/cenalulu/archive/2012/11/12/mysql_audit_plugin_test.html