hive hbase handler_handler:function_handlersocket(2)

%user和%system占用的CPU都相当高。

再看看oprofile统计出来的信息：

ps:这个工具不错,内核级别的。

samples % app name symbol name
259130 4.5199 mysqld MYSQLparse(void*)
196841 3.4334 mysqld my_pthread_fastmutex_lock
106439 1.8566 libc-2.5.so _int_malloc
94583 1.6498 bnx2 /bnx2
84550 1.4748 ha_innodb_plugin.so.0.0.0 ut_delay
67945 1.1851 mysqld _ZL20make_join_statistics
P4JOINP10TABLE_LISTP4ItemP16st_dynamic_array
63435 1.1065 mysqld JOIN::optimize()
55825 0.9737 vmlinux wakeup_stack_begin
55054 0.9603 mysqld MYSQLlex(void*, void*)
50833 0.8867 libpthread-2.5.so pthread_mutex_trylock
49602 0.8652 ha_innodb_plugin.so.0.0.0 row_search_for_mysql
47518 0.8288 libc-2.5.so memcpy
46957 0.8190 vmlinux .text.elf_core_dump
46499 0.8111 libc-2.5.so malloc

MYSQLparse是5.x版本中的，在4.x中是YYparse

MYSQLparse() 和 MYSQLlex()是在mysql解析sql语句的时候调用到的。

make_join_statistics()和JOIN::optimize() 是在query optimization（查询优化）阶段调用到的。

正是因为使用了SQL语句，才会有这些额外的负担。

从oprofile的输出可以得到如下结论：

SQL层严重影响到了mysql查询的性能。

与memcached和SQL比起来，mysql要额外做一些工作：

* Parsing SQL statements 解析sql语句

* Opening, locking tables 打开并锁定表

* Making SQL execution plans ???

* Unlocking, closing tables 解锁并关闭表

花荣注：使用mysqli 中的prepared statement API可以避免解析sql语句。

mysql还必须要做大量的并发控制，比如在发送/接收网络数据包的时候，fcntl()就要被调用很多很多次。

Global mutexes ：LOCK_open LOCK_thread_count 也被频繁地调用。

所以在oprofile的输出中，排在第二位的是my_pthread_fastmutex_lock()。并且%system占用的CPU相当高(28%)。

其实 mysql开发团队和一些的开发团体都了解大量并发控制对性能的影响，

他们在mysql 5.5中已经解决了某些问题。未来的mysql中，%system占用的cpu会越来越少。

但是，%user占用的60%cpu怎样处理呢？

Mutex contentions result in %system increase, not %user increase

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-27117-2.html