阿里巴巴DBA,原去哪儿网DBA。专注于MySQL源码研究、DBA运维、CGroup虚拟化及Linux Kernel源码研究等。 github:https://github.com/HengWang/ Email:king_wangheng@163.com 微博 :@王恒-Henry QQ :506437736
分类: LINUX
2013-05-09 23:10:57
基于之前《cgroup的cpu.shares测试(2)》,为了进一步了解当某个MySQL实例CPU资源消耗异常时,对其他MySQL实例正常操作的影响,进行测试,验证cpu.shares对CPU资源隔离的有效性。
1、在MySQL的3306端口实例上,设计复杂、消耗大量CPU资源的SQL查询,测试执行时间(多次信息统计)。
2、通过sysbench压力测试MySQL的3606端口的实例,在3306端口实例上执行同样的复杂SQL查询,测试执行时间(多次信息统计)。
设计测试测试语句如下所示:
select sql_no_cache count(a.id) from sbtest a,sbtest b where a.pad=b.pad and a.id < 100 and a.pad like '%www%' |
在MySQL的3306端口实例进行测试,执行测试SQL语句20次,统计执行时间,如下所示:
I |
Time(sec) |
1 |
5.805102 |
2 |
5.81315375 |
3 |
5.80112725 |
4 |
5.79869225 |
5 |
5.7850675 |
6 |
5.91673075 |
7 |
5.786145 |
8 |
5.85159725 |
9 |
5.774666 |
10 |
5.78381475 |
11 |
5.79729725 |
12 |
5.8091065 |
13 |
5.76944225 |
14 |
5.74195125 |
15 |
5.79900225 |
16 |
6.03366525 |
17 |
5.9597845 |
18 |
5.774477 |
19 |
5.7725285 |
20 |
5.949358 |
根据统计信息,计算整体统计信息如下所示:
Name |
Time |
total execute time |
116.52270925 |
max execute time |
6.03366525 |
min execute time |
5.74195125 |
average execute time |
5.82613546 |
sysbench压力测试3606端口实例,然后执行测试SQL语句20次,统计执行时间,具体如下所示:
I |
Time(sec) |
1 |
5.7300415 |
2 |
5.680989 |
3 |
5.9939615 |
4 |
6.23474125 |
5 |
5.837156 |
6 |
5.76189475 |
7 |
5.84244525 |
8 |
5.87290075 |
9 |
5.7052105 |
10 |
5.76841325 |
11 |
5.7852 |
12 |
5.71719 |
13 |
5.908228 |
14 |
5.809332 |
15 |
6.20727075 |
16 |
5.8664525 |
17 |
5.68960825 |
18 |
5.87733275 |
19 |
5.754067 |
20 |
5.757749 |
根据统计信息,计算整体统计信息如下所示:
Name |
Time |
total execute time |
116.800184 |
max execute time |
6.23474125 |
min execute time |
5.680989 |
average execute time |
5.8400092 |
通过测试以上结果可知,MySQL的3306端口实例的SQL执行时间,没有因sysbench压力测试MySQL的3606端口实例,而出现明显的查询延迟。
为了更进一步的查看当前具体实例的CPU利用情况,使用cgmonitor.py进行监控,并进行分析CPU的system和user的利用率,具体如图所示:
从上图中可知,在MySQL的3306端口执行复杂SQL时,3606端口的MySQL实例的CPU利用率明显降低。
通过测试可知,通过cpu.shares对MySQL实例进行CPU资源限制时,当某个实例压力过大时(3606),其他实例(3306)的正常查询业务没有受到严重的影响。因此,cpu.shares进行CPU资源限制,符合预期效果。