注册 登录
龙盟编程论坛 返回首页

栋栋的个人空间 http://www.1sohu.com/bbs/?267 [收藏] [复制] [分享] [RSS]

日志

MySQL审计插件性能测试对比

已有 2524 次阅读2012-11-23 13:35 |

背景:

 
卖咖啡在5月份推出了MySQL Audit Plugin,经过几个月的更新,目前已经是1.0.2版本。
Oracle在收购MySQL以后,同样也在5.5的Audit API基础上推出了 MySQL Audit Plugin。
本次测试就是基于这两款产品进行的。
 
正文:
 
技术对比:
 OracleMcAfee
试用版本5.5 or higher5.1 or higher
是否免费chargefree
是否动态开关yesyes
 
 
原理对比:
由于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时的基准性能; 红色数字表示开启后,相较基准的性能百分比。
 
ConcurrencyMaCfee BaseSlow log MaCfee Audit Oracle BaseOracle Audit 
1489.79438.0389%307.4363%428.65414.9997%
2876.68870.4499%774.2788%874.26858.6498%
31396.441266.1391%1119.7780%1321.31272.7896%
41830.441644.8490%1389.2876%1719.581650.4496%
52297.53196586%1699.5774%2142.412030.4795%
62703.672293.485%1744.265%2575.472388.2193%
73114.532521.7981%1548.4750%2964.082653.8890%
83539.272737.8677%1479.0342%3338.173044.4991%
93919.512875.6573%1475.4738%3748.983253.3387%
104330.82887.4867%1491.8734%4136.683428.1683%
114672.052670.5357%1484.5632%4488.63576.0480%
124971.32335.0847%1375.8428%4777.93969.6183%
134976.722138.4643%1301.1326%4802.94072.9685%

当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:信息详尽,但是性能在高并发时很大的损耗。不具备线上使用的条件。

本文链接

评论 (0 个评论)

facelist doodle 涂鸦板

您需要登录后才可以评论 登录 | 注册

小黑屋|手机版|Archiver|龙盟编程网    

GMT+8, 2018-4-20 07:20 , Processed in 0.029578 second(s), 8 queries , Memcache On.

Powered by Discuz! X3.1

© 2001-2013 Comsenz Inc.

返回顶部