MySQL审计插件性能测试对比_MySQL

bitsCN.com

背景：

乾坤圈新媒体矩阵管家

新媒体账号、门店矩阵智能管理系统

下载

 卖咖啡在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 没有差别

 

 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 句 = 28GMaCfee：1419020行  日志大小 431M = 每一千行日志 = 0.311K   团购每天Questions = 163330688 句 = 48G Oracle由于记录的信息较少，因此文件体积也较小   性能比较：MaCfee：基于percona 5.1.66Oracle：  基于5.5.28-enterprise-commercial-advanced-logSlowlog：基于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：信息详尽，但是性能在高并发时很大的损耗。不具备线上使用的条件。