MySQL内核月报 2014.09-MySQL· 参数故事·thread_concurrency

<b>提要</b>

　　thread_concurrency参数用于向操作系统建议期望的并发线程数，参数在mysqld启动的时候使用。但mysql 5.6 从源码中删除了这个参数，不再使用。

<b>参数背景</b>

　　源码：

　　可以看到thread_concurrency的限制：

<dl><dd><dl></dl></dd></dl>

<dd>1. thread_concurrency不能用在gnu/linux平台上，而只能在old solaris versions &lt; 9才能work。</dd>

<dd>2. os层面只提供了hint建议，并不能提供足够的信息，控制和诊断都不够灵活。</dd>

<dd>3. os无法获得mysql层面提供的所有线程的状态，包括语句的执行，阻塞，当前事务状态等信息，所以os终究不能根据事务型软件系统量身定制并发控制。</dd>

　　一句话，os层面无法把并发控制做精细，所以放弃使用。

　　那么并发控制究竟在什么地方进行控制最好，控制为多少合适呢?

<b>并发控制</b>

　　<b>并发控制点：</b>

<dl><dd><dl><dd>并发控制的目的是最大化提高系统的资源利用率，并减少管理和调度开销。在mysql实例中，主要处理sql请求，所以期望系统资源最大化提供给sql的执行过程。</dd></dl></dd></dl>

　　sql的执行牵涉到server层和引擎层：

<dd>1. server层：比如cost计算，生成sql执行计划的过程</dd>

<dd>2. innodb层：比如根据执行计划，查找和更新数据page的过程</dd>

　　所以在mysql实例中，有两个最佳的并发控制点：

<dd>1. server层：sql开始执行时。 mysql在5.6后，在server层引入了thread pool进行并发控制</dd>

<dd>2. innodb层：记录查找和记录更新时。 innodb存储引擎，使用innodb_thread_concurrency参数进行并发控制</dd>

<b>并发控制大小：</b>

<dd>设置过大：造成系统调度消耗过大</dd>

<dd>设置过小：不能完全的使用系统资源，造成资源浪费</dd>

　　经验值：# try number of cpu's*2 for thread_concurrency

　　但还需要配合具体的平台和业务系统进行测试，才能找到最佳值。

<b>innodb并发控制</b>

　　innodb使用参数innodb_thread_concurrency控制并发线程的个数，源码中使用一对函数：

<dd>innodb_srv_conc_enter_innodb</dd>

<dd>innodb_srv_conc_exit_innodb</dd>

　　innodb实现语句级的并发控制，在语句执行结束，stmt commit的时候，强制释放资源。

<b>权衡和优化</b>

<dl></dl>

<dd>1. 一方面进行并发控制，提高资源利用率，</dd>

<dd>2. 另一方还需要控制调度公平，防饿死等。</dd>

　　innodb引入了n_tickets_to_enter_innodb参数，sql进入innodb执行时进行初始化，默认值500。

　　在执行过程中，依次进行递减，递减到0时，强制退出并发线程，重新抢占。

　　好处：

<dl><dd></dd></dl>

<dd>1. 一方面单条sql可能写入或者更新多条记录，节省每次enter innodb的线程抢占代价。</dd>

<dd>2. 另一方面防止单条sql过多的长时间占用并发线程，导致其它线程饿死的情况。</dd>