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：信息詳盡，但是性能在高並發時很大的損耗。不具備線上使用的條件。