终于解决了mysql参数thread_concurrency的设置问题

   已经在一个非常奇怪的数据库问题上卡了很久,slow log里面全是一些非常基本的sql语句,主键查询或者根据主键更新简单字段,本来应该是毫秒级返回结果的sql,居然总是超时。innodb分明是行级锁,本来这些单行操作是innodb的优势项目,应该毫无压力的,居然成为了瓶颈。

   反复调整参数,并且请教了专家之后仍然没有很好地解决,之前增加了

innodb_purge_threads = 32 # 5.6之后才支持大于1, 5.5上会自动变成1

   让每隔10秒的purge操作开独立的进程有一定的改善,但是仍然还是有很多阻塞的情况和很多slow log。

   今天在安装一台新mysql的时候看到这样一段错误消息

[Warning] option 'thread_concurrency': unsigned value 0 adjusted to 1

   我非常惊讶,因为我一直以为thread_concurrency=0的意思是不设置thread_concurrency,即无限。如果thread_concurrency=1,那就意味着mysql始终只能有一个并发thread,这显然会造成阻塞,严重影响性能。

   把这个参数改成16(cpu总线程数)之后,这个阻塞的问题彻底解决了。在top里经常能看到mysqlCPU占用率超过200%以上的瞬间,而原来mysql很少能超过200%。slow log里面也不再出现那些简单查询的日志了。

   查了一下相关信息,众说纷纭,有很多人包括官方文档说这个参数没有意义,仅仅针对solaris才有效。

   percona的博客上有人写了一篇文章说thread_concurrency不是你想的那样,修改这个参数是浪费时间。我谨慎表示认同。

   http://www.mysqlperformanceblog.com/2012/06/04/thread_concurrency-doesnt-do-what-you-expect/

   并且还说这个参数在5.6.1之后会被废弃。

   还有一些中文文章也认为这个参数没有意义

   http://blog.chinaunix.net/uid-167175-id-3484871.html

   至少经过我实践,这个参数在linux下面是有效的。默认是10,我改成0并被系统强制变成1之后,造成了经常阻塞的问题。目前我设置的是16,等于CPU线程数。

   我为什么会蛋疼地以为把这个参数改成0会有效呢,大概是因为受了innodb_thread_concurrency的影响,innodb_thread_concurrency是可以并且推荐改成0的。

   在我看来这个参数似乎除了坑人之外真的没有什么别的作用了,默认thread_concurrency=10就已经足够可用了,确实不需要修改。早一点升级到5.6告别这个参数吧。

觉得文章有用?立即: 和朋友一起 共学习 共进步!

猜想失败,您看看下面的文章有用吗?

4 thoughts on “终于解决了mysql参数thread_concurrency的设置问题

  1. 自从2009年测试MySQL Cluster 7.0之后,就没怎么关注过它,发展实在太慢了,还有很多不靠谱的地方。前阵子退出7.2.7版本后,看了看新特性介绍

发表评论

电子邮件地址不会被公开。 必填项已用 * 标注

*

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>