文章给大家介绍在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才有效.
并且还说这个参数在5.6.1之后会被废弃,还有一些中文文章也认为这个参数没有意义.
注意:这个参数是针对Solaris系统的,如果使用Linux系统,也就不需要设置这个参数,除非你使用Solaris系统.//phpfensi.com
至少经过我实践,这个参数在linux下面是有效的,默认是10,我改成0并被系统强制变成1之后,造成了经常阻塞的问题,目前我设置的是16,等于CPU线程数.
我为什么会蛋疼地以为把这个参数改成0会有效呢,大概是因为受了innodb_thread_concurrency的影响,innodb_thread_concurrency是可以并且推荐改成0的.
在我看来这个参数似乎除了坑人之外真的没有什么别的作用了,默认thread_concurrency=10就已经足够可用了,确实不需要修改,早一点升级到5.6告别这个参数吧. |
