- 论坛徽章:
- 0
|
全脚本测试
执行时间
Concurrency=1
Concurrency=10
Concurrency=20
Icc编译的mysql
230.34s
736.70s
1614.49s
Gcc编译的mysql
197.34s
623.70s
1334.76s
Icc较gcc的优势
-16.7%
-18.1%
-21.0%
表3
全脚本测试
Concurrency=1
Concurrency=10
Concurrency=20
Cpu%
Mem%
Cpu%
Mem%
Cpu%
Mem%
us
sy
Id
Us
sy
Id
us
sy
id
Icc-mysql
9.9
2.0
71.9
7.7
61.7
9.0
25.3
7.5
66.4
17.2
15.1
7.5
Gcc-mysql
10.1
1.2
72.6
10.7
60.6
3.1
30.3
11.3
80.1
7.2
10.6
11.5
表4
表4是icc编译的mysql和gcc编译的mysql在测试过程中资源使用情况的对比。从表中数据可以看出，icc编译的mysql在cpu，内存开销上较gcc编译的mysql要小。同时需要注意的是在cpu花在系统kernel内的时间上，icc编译的mysql明显多于gcc编译的mysql。怀疑底层系统由gcc编译和上层icc编译的应用程序配合有问题。在全脚本测试的过程中，通过iostat观察IO负载情况，发现磁盘利用率大部分时间保持在50%以上，一部分时间会在90%以上。说明这种情况下，IO负载是比较大的。
4.2.1.2 特定的3个SQL测试结果及分析
在做完整个全脚本测试比较之后，我分析了脚本中包含的SQL。把它们归纳归类，然后对每一种类型的SQL进行对比测试。从每种SQL的执行计划、执行过程来分析该SQL在icc编译的mysql和gcc编译的mysql表现出来的不同执行时间。从这些信息分析icc编译的mysql性能具有优势的方面。下面对3种具有代表性的SQL的测试结果。
SQL1：update tst_report_orderinfo_stat t,tst_userposmap_info t1,tst_postree_info t2 set t.posid=t2.posid where t.submitor_id=t1.ucid and t1.posid=t2.posid and t1.dataowner=1 and t2.postype=3 and t.finance_arr_date=t1.stat_date and t2.stat_date=t1.stat_date ;qq分组
SQL1
执行时间
Concurrency=1
Concurrency=5
Concurrency=10
Icc编译的mysql
35.06s
95.05s
168.87s
Gcc编译的mysql
34.59s
100.18s
179.13s
Icc较gcc的优势
-1%
5.1%
5.7%
表5
将上述SQL稍微改造一下，以获得该SQL的执行计划（该执行计划和上面update操作相似）：
select t.posid，t2.posid from tst_report_orderinfo_stat t,tst_userposmap_info t1,tst_postree_info t2 where t.submitor_id=t1.ucid and t1.posid=t2.posid and t1.dataowner=1 and t2.postype=3 and t.finance_arr_date=t1.stat_date and t2.stat_date=t1.stat_date ;
获得的执行计划：
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t1
type: ALL
possible_keys: PRIMARY,tst_userposmap_info_stat_date_idx
key: NULL
key_len: NULL
ref: NULL
rows: 1157224
Extra: Using where
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: t2
type: eq_ref
possible_keys: PRIMARY,tst_postree_info_stat_date_idx
key: PRIMARY
key_len: 7
ref: xxx.t1.posid,xxx.t1.stat_date
rows: 1
Extra: Using where
*************************** 3. row ***************************
id: 1
select_type: SIMPLE
table: t
type: ref
possible_keys: index_report_finance_arr_date_idx,index_report_submiter_id
key: index_report_submiter_id
key_len: 4
ref: xxx.t1.ucid
rows: 16
Extra: Using where
3 rows in set (0.00 sec)
从执行计划上可以看出，驱动表采取的全表扫描的方式取得数据，而不是通过索引。即使是Innodb也要加表锁，所以在增加concurrency后，mysql也只能串行处理这些请求。这样在第一次执行该SQL时需要从磁盘上取得相关数据，而在第一次以后再执行该SQL时，就不需要从磁盘上取得数据（数据会被缓存）。后续的SQL执行消耗的是CPU资源，从测试结果来看，icc编译的mysql在concurrency=1没有优势；但是在concurrency>1后，逐渐显现出优势，并且优势随着concurrency增加而增加。可以看出icc编译出的mysql在CPU运算方面的优势。
SQL2：select blacklist_id, company_name from td_blacklist where company_name like '%xxx%' and del_flag= 0;
SQL2
执行时间
Concurrency=10
Concurrency=50
Concurrency=100
Icc编译的mysql
0.228s
0.265s
0.337s
Gcc编译的mysql
0.227s
0.287s
0.365s
Icc较gcc的提升
-0.4%
8%
8%
表6
本SQL的执行计划为：
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: td_blacklist
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 1589
Extra: Using where
从上述执行计划可以看出该操作使用全表扫描过滤数据，这种方式是顺序读操作，并且涉及的行数只有1589行。IO操作的压力不大，这要消耗应是CPU相关操作。从本条SQL的测试结果上看，在InnoDB引擎下，对于全表扫描的操作，icc编译的mysql较gcc编译的mysql没有劣势；在高并发下，icc编译的mysql还有优势。
SQL3：update tb_cust_app tc left join (select count(distinct f.cust_id) num, follow_id from tb_follow_assign f, tb_customer c where f.cust_id=c.cust_id and c.cust_stat_1<>5 group by follow_id) tf on tc.user_id = tf.follow_id set tc.ownered_size=ifnull(tf.num,0) ;
SQL3
执行时间
Concurrency=1
Concurrency=10
Concurrency=50
Icc编译的mysql
52.30s
79.37s
557.23s
Gcc编译的mysql
50.81s
77.30s
452.49s
Icc较gcc的提升
-3%
-2.7%
-23.1%
表7
将上述SQL稍微改造一下，以获得该SQL的执行计划：
select tc.ownered_size,ifnull(tf.num,0) from tb_cust_app tc left join (select count(distinct f.cust_id) num, follow_id from tb_follow_assignf, tb_customer c where f.cust_id=c.cust_id and c.cust_stat_1<>5 group by follow_id) tf on tc.user_id = tf.follow_id;
相关的执行计划：
*************************** 1. row ***************************
id: 1
select_type: PRIMARY
table: tc
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 4386
Extra:
*************************** 2. row ***************************
id: 1
select_type: PRIMARY
table: <derived2>
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 2655
Extra:
*************************** 3. row ***************************
id: 2
select_type: DERIVED
table: f
type: index
possible_keys: Index_follow_assign_cust_id
key: Index_follow_assign_follow_id
key_len: 5
ref: NULL
rows: 362615
Extra:
*************************** 4. row ***************************
id: 2
select_type: DERIVED
table: c
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: xxx.f.cust_id
rows: 1
Extra: Using where
4 rows in set (3.00 sec)
从上述执行计划可以看出，table f是按照索引顺序进行全表的索引树扫描，这就会造成很多的随机读（使用的索引不是primary key）。大量的随机读会造成比较大的IO压力。从测试结果上看，icc编译出的mysql与gcc编译出的mysql相比，在执行时间存在一定的劣势。前面的全脚本测试中存在比较多的这种SQL，因此全脚本回放测试中icc编译出的mysql执行时间上比gcc编译的mysql多。从本条SQL的执行计划和测试结果上看，在InooDB引擎下，使用辅助索引，icc编译出的mysql很可能出现劣势，这和sql-bench测试结果一致。YY频道设计
4.2.2 使用某数据库数据，MyISAM引擎测试结果及分析
本节将数据库中一些表的存储引擎改成了MyISAM，测试使用的SQL依然来自使用的SQL。本节希望获得在MyISAM引擎基础上，基于某数据库数据，icc编译的mysql对一些典型SQL的优化效果。
SQL1：(select customerd, customername, companyname, realcompanyname from tb_shifen_customerwhere urldomain like "%.cn" and status=3 and accountm>0 limit 10) union (select customerd, customername, companyname, realcompanyname from tb_shifen_customer where urldomain like "%.cn" and status in (1,4,6) and status=3 and accountm<=0 and invalidate>=date_sub(curdate(),interval ? day) limit 10) union (select customerd, customername, companyname, realcompanyname from tb_shifen_customer where urldomain like "%.cn" and status in (1,4,6) and accountm>0 limit 10) union (select customerd, customername, companyname, realcompanyname from tb_shifen_customer where urldomain like "%.cn" and status=2 limit 10);
SQL1
执行时间
Concurrency=1
Concurrency=10
Concurrency=100
Icc编译的mysql
36.01s
31.20s
162.78s
Gcc编译的mysql
41.02s
40.30s
181.83s
Icc较gcc的提升
12.6%
22.0%
10.5%
表8
SQL2：select count(*) from tb_customer where urldomain like "%.cn";
SQL2
执行时间
Concurrency=1
Concurrency=10
Concurrency=100
Icc编译的mysql
0.014s
0.014s
0.029s
Gcc编译的mysql
0.026s
0.027s
0.035s
Icc较gcc的提升
41.2%
48.1%
17.1%
表9
SQL3：select cust.cust_id,cust.cust_stat_1,cust.cust_stat_2,cust.cust_name, cust.cust_branch_name,cust.cust_input_type,cust.add_time,cust.cust_follow_num, cust.cust_trade_1,cust.cust_trade_2,dis.distribute_time from tb_customer cust left join tb_cust_distribute dis on cust.cust_id=dis.cust_id and dis.state=1 where cust.cust_id>0 and cust.cust_stat_1 in( and cust.pose_id=157 order by cust.cust_id desc limit 1170 , 15;
SQL2
执行时间
Concurrency=1
Concurrency=10
Concurrency=100
Icc编译的mysql
2.839s
3.631s
9.554s
Gcc编译的mysql
2.828s
3.740s
10.867s
Icc较gcc的提升
-0.3%
2.91%
12.1%
表10
上述3个类型的SQL是从测试库上执行的读操作中挑选出来的，相应的表的引擎改成了MyISAM引擎。这3个SQL涉及了扫表，索引扫描，排序等操作。从测试的结果上看，icc编译的mysql对MyISAM引擎读操作的优化效果明显。从执行时间上看（QPS）减少大概在10%-20%之间（QPS增加10%-20%）。
SQL4：update tb_cust_app tc left join (select count(distinct f.cust_id) num, follow_id from tb_follow_assignf, tb_customer c where f.cust_id=c.cust_id and c.cust_stat_1<>5 group by follow_id) tf on tc.user_id = tf.follow_id set tc.ownered_size=ifnull(tf.num,0) ;
SQL2
执行时间
Concurrency=1
Concurrency=10
Concurrency=100
Icc编译的mysql
31.279s
42.290s
342.80s
Gcc编译的mysql
33.274s
53.731s
566.374s
Icc较gcc的提升
6.0%
21.23%
39.5%
表11
SQL4同上一节的SQL3。在上一节InnoDB引擎下，icc编译的mysql对于此SQL在执行时间上明显慢于gcc编译的mysql，也主要是因为该SQL导致innodb全脚本测试icc编译的mysql慢于gcc编译的mysql。但是对于MyISAM引擎，从测试结果上看，icc编译的mysql明显优于gcc编译的mysql。从测试可以看出icc编译的mysql对MyISAM写操作也有优化效果，从执行时间上看（QPS）减少大概在10%-20%之间（QPS增加10%-20%）。
5 测试结论
从两个维度上总结测试结论：1存储引擎维度；2CPU，IO负载。
从存储引擎维度：对于MyISAM引擎，从sql-bench，mysqlslap使用某数据库数据测试结果上看，icc编译的mysql无论从读操作还是写操作都有优化效果，SQL执行时间平均减少10%-20%。对于一些比较消耗CPU的SQL（比如排序等，执行时间较长的SQL）,在一定的并发下优化效果更明显。
对于InnoDB引擎，从sql-bench，mysqlslap使用全脚本测试结果上看，icc编译的mysql较gcc编译的mysql从QPS（SQL执行时间）没有优势，甚至是劣势。同时从sql-bench，全脚本中的逐个SQL分析来看：对于利用primary key或者全表扫描的SQL，icc编译的mysql有一些优化效果；对于利用辅助索引的SQL，icc编译的mysql在执行时间上比gcc编译的mysql慢。分析原因，InnoDB使用聚簇索引存储数据，利用辅助索引时，还需要走一遍primary key，这中间会有比较多的随机读等操作。
从IO，CPU负载维度：通过测试中对于资源的统计和对比，icc编译的mysql在用户态cpu开销上较gcc编译的mysql小（相差不大）；在内核态cpu开销要比gcc编译的mysql多；在内存上开销上icc编译的mysql稍小。Icc对于CPU密集，IO负载不重的场景，优化效果明显；对于IO负载较重的场景，icc编译的mysql优化效果可能不明显。
综上所述：icc编译的mysql用于MyISAM引擎，较gcc编译的mysql优化效果明显。对于InnoDB引擎，使用辅助索引等操作，icc编译的mysql比gcc编译的mysql在执行时间上要慢，存在劣势。对于使用全表扫描、primary key的InnoDB操作，在低并发下，icc编译的mysql在执行时间上不会慢，在高并发下icc编译的mysql具有优势。同时业务类型是CPU密集型，而不是IO密集型，有助于发挥icc编译器的优化效果 |
|
免费注册
发表于 2011-04-02 10:08