当前位置: 首页 > 分布式系统 > 正文

HandlerSocket和Mysql

关键字:
1 星2 星3 星4 星5 星 (1 次投票, 评分: 5.00, 总分: 5)
Loading ... Loading ...
baidu_share

引子

发现MySQL性能降低的原因主要在SQL层,而不是存储层。”SQL层的功能包括解析SQL语句、打开/锁定/解锁/关闭表、解决并发问题等”,Percona的同学在MySQL Performance Blog中给出了更加详细的分析,欢迎收看《走进科学》栏目,让MySQL同学们亲自带我们深入底层,看一下MySQL到底“瓶颈”在哪里,只有找到系统瓶颈我们才可能有针对性的进行优化,对一个大型复杂的系统而言更是如此。对于NoSQL开发者而言,因为大部分NoSQL都不提供完备的SQL支持,也可以更加清晰的认识和数据库相比的性能优势在哪里。

走进科学

接下来的实验部分像CCAV某频道一样,要分为上下两集来介绍,以凸显工作的阶段性和丰硕的成果,虽然并没什么更值得期待的内容,或者下集的内容多数是重复的。

上集

上集来自DeNA(看过上篇的同学一定不会诧异这是什么公司)的Akira Higuchi同学给出了libmysql和 libhsclient两者的Profiling对比结果,结论是MySQL的Parse太耗CPU和时间了,第一次发现热点和瓶颈。

libmysql (Akira’s Numbers)
samples	%	symbol name
748022	7.7355	MYSQLParse(void*)
219702	2.2720	my_pthread_fastmutex_lock
205606	2.1262	make_join_statistics()
198234	2.0500	btr_search_guess_on_hash
180731	1.8690	JOIN::optimize()
177120	1.8317	row_search_for_mysql
171185	1.7703	lex_one_token(void*,void*)
162683	1.6824	alloc_root
131823	1.3632	read_view_open_now
122795	1.2699	mysql_select()
- Parsing SQL is slow
 
HandlerSocket (Akira’s Numbers)
samples	%	symbol name
119684	14.7394	btr_search_guess_on_hash
58202	7.1678	row_search_for_mysql
46946	5.7815	mutex_delay
38617	4.7558	my_pthread_fastmutex_lock
37707	4.6437	buf_page_get_known_nowait
36528	4.4985	rec_get_offsets_func
34625	4.2642	build_template()
20024	2.4660	row_sel_store_mysql_rec
19347	2.3826	btr_cur_search_to_nth_level
16701	2.0568	row_sel_convert_mysql_key_to_innobase
- Most CPU timeis spent inside InnoDB

下集

下集来自Percona Server的Ryan Lowe,他应其他同学的要求针对Prepared Statements Querey进行了补充。

libmysql (5.1.56) (Ryan’s Numbers)
samples	%	symbol name
57390	2.4548	MYSQLparse(void*)
42091	1.8004	String::copy()
32543	1.3920	__read_nocancel
30536	1.3062	btr_search_guess_on_hash
24630	1.0535	my_wc_mb_latin1
24407	1.0440	memcpy
23911	1.0228	MYSQLlex(void*, void*)
22392	0.9578	pthread_mutex_lock
21973	0.9399	fcntl
20529	0.8781	my_utf8_uni

本文固定链接: http://www.chepoo.com/handler-socket-mysql-slowly-1.html | IT技术精华网

HandlerSocket和Mysql:等您坐沙发呢!

发表评论