handler handlemessage_handlersocket_乐视2crashhandler停止(2)

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

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

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

samples %app namesymbol name259130 4.5199 mysqldMYSQLparse(void*)196841 3.4334 mysqldmy_pthread_fastmutex_lock106439 1.8566 libc-2.5.so_int_malloc945831.6498 bnx2/bnx2845501.4748 ha_innodb_plugin.so.0.0.0 ut_delay679451.1851 mysqld_ZL20make_join_statisticsP4JOINP10TABLE_LISTP4ItemP16st_dynamic_array634351.1065 mysqldJOIN::optimize()558250.9737 vmlinuxwakeup_stack_begin550540.9603 mysqldMYSQLlex(void*, void*)508330.8867 libpthread-2.5.sopthread_mutex_trylock496020.8652 ha_innodb_plugin.so.0.0.0 row_search_for_mysql475180.8288 libc-2.5.somemcpy469570.8190 vmlinux.text.elf_core_dump464990.8111 libc-2.5.somalloc

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-27116-2.html