Mysql线程池优化笔记

Mysql线程池优化我是总结了一个站长的3篇文章了，这里我整理到一块儿来本文章就分为三个优化段了，下面一块儿来看看。

 

Mysql线程池系列一(Thread pool FAQ)

首先介绍什么是mysql thread pool,干什么用的？
使用线程池主要能够达到如下两个目的：
一、在大并发的时候,性能不会由于过载而迅速降低。
二、减小性能抖动

thread pool的工做原理？
线程池使用分而治之的方法来限制和平衡并发性。与默认的thread_handling不一样,线程池将链接和线程划分开,因此链接数量和执行语句的线程数再也不是固定的关系,线程池能够经过
配置线程组来管理链接,而后再根据每一个语句的关键字来肯定是优先执行或者排队执行。

mysql thread pool和client端的connection pool的不一样之处？
client段的connection pool：链接池主要用来管理客户端的链接,避免重复的链接/断开操做,而是将空闲的链接缓存起来,能够复用。从而减小了链接mysql server/断开mysql server的开销与成本,从而提高性能。
可是mysql的connection pool不能获取mysql server的查询处理能力以及当前的负载状况。
thread pool:线程池的操做是在mysql server端,而且设计就是用来管理当前并发的链接和查询.

thread pool到底可以提高多少性能?
根据Oracle Mysql官方的性能测试
在并发达到128个链接之后.没有线程池的Mysql性能会迅速下降。使用线程池之后,性能不会出现波动,会一直保持在较好的状态运行。
在读写模式下,128个链接之后,有线程池的Mysql比没有线程池的Mysql性能高出60倍。
在只读模式下,512个链接之后,有线程池的Mysql比没有线程池的Mysql性能高出18倍。

何时能够考虑使用thread_pool？
* show global status like ‘%threads_running%’;的值是mysql server当前并发执行语句的数量轨迹,若是这个值一直保持在40左右的区间,那么能够考虑使用thread pool。
*若是你使用了innodb_thread_concurrency参数来控制并发的事物量,那么使用线程池将会得到更好的效果。
*若是你的工做是有不少短链接组成的,那么使用线程池是有益的。

说一下oracle mysql thread pool插件的限制：
一、Oracle Mysql enterprise 6.10版本添加的,也就是说小于这个版本的企业版不支持,目前全部的oracle mysql community版本也不支持。
二、若是是windows的系统,须要是vista或者之后的版本,若是是linux,须要2.6.9之后的内核。

 

Mysql线程池系列二(Oracle Mysql Thread pool的安装和原理)

thread pool的组件和安装
thread pool是以插件的方式存在的,安装thread pool插件之后,会增长一些information_schema表和相关参数变量。
information_schema表包含:
TP_THREAD_STATE
TP_THREAD_GROUP_STATE
TP_THREAD_GROUP_STATS

新增长的参数变量:
thread_handling增长了一个值,loaded-dynamically,当成功加载thread pool插件的时候就是这个值了。
thread_pool_algorithm:
thread_pool_high_priority_connection:
thread_pool_prio_kickup_timer:
thread_pool_max_unused_threads:
thread_pool_size：
thread_pool_stall_limit:
若是这些值设置的不正确,那么启动mysql的时候插件会初始化失败,插件将不能加载。
这些变量的具体设置方法,会在接下来的优化章节里面详细的介绍。

thread pool插件的对象库必须放在plugin_dir变量对应的目录里。为了使thread pool生效,能够在启动mysql的时候使用–plugin-load选项。或者修改my.cnf文件.在[mysqld]区段中添加以下信息
[mysqld]
plugin-load=thread_pool.so

thread pool的原理
thread pool包含数个thread groups,每一个thread group管理一组客户端链接。当链接创建之后,thread pool以轮询的方式分配他们到thread group.
thread group的数量是经过thread_pool_size配置获得的,默认是16个,最大64个,最小1个。
每一个thread group最大能够有4096个线程。

线程池把链接和线程分开了,因此链接和线程不是固定对应的,线程执行从connections收到的语句,这和默认的thread_handling模式不一样。

thread_handling参数
原来的版本里面有一个thread_handling参数,能够设置thread的工做模式,有两个值,
一个是no-threads,指任意时刻最多只有一个链接能够链接到mysql server,通常用于调试。另一个是one-thread-per-connection,是指针对每一个链接建立一个线程来处理这个链接的全部请求,直到链接断开,线程结束.这也是thread_handling的默认值。
因而可知,默认状况下,多少链接就会产生多少个线程,并发越大,线程越多,线程之间的资源竞争越激烈,性能越低。

thread pool插件提供另外的一种thread_handling方法,用来有效的管理执行线程与大量客户端链接,从而提升性能。
线程池解决的几个问题:
*高并发的多线程栈致使CPU的缓存几乎失效,线程池促进线程堆栈重用,减小CPU缓存量。
*太多的线程并发执行,上下文切换开销很高,这对操做系统的任务调度是一个很大的挑战,线程池能够把mysql活跃的并发线程控制在一个适合mysql server运行的水平。
*太多的事务并发执行会增长资源争用,在innodb引擎里,会增长获取central mutexes的时间,线程池能够控制事务的并发量。

thread pool尝试保证每一个thread group中的每一个thread尽可能执行更多的语句,可是有些时候容许更多的线程执行一些临时的任务来提升性能。算法的工做方式以下:
*每一个trhead group有一个listener,这个listener负责监听分配给thread group的statements,thread group有两种执行方案,一是当即执行,一种是排队执行。
*当即执行的条件是当前只收到一条statement,而且当前没有statements在执行。
*排队执行发生在不能当即执行的时候
*当当即执行发生的时候,是由listener线程执行的,也就是说listener在执行一些临时的statements,若是当即执行的statement很快执行完成,那么这个线程会变回listener线程,若是其余状况thread pool会考虑重新开启一个listener线程来代替它,是否须要建立listener线程是由thread pool的后台线程来监控和执行的。
当thread pool插件启动之后,每一个thread group会建立一个listener线程,加上background线程,其余线程根据是否须要而建立。

thread_pool_stall_limit系统变量的含义能够理解为完成一个statement须要的时间,默认认为stalled的时间是60ms,最大能够设置为6s。配置这个参数可让你平衡服务器的工做负载.这个值设置的越小线程启动越快,更小的值能够更好的避免死锁,更大的值一般在不少长查询的时候使用,为了不启动太多的线程。

thread pool的焦点在于限制并发的短查询语句的数量,在一个语句执行时间没有达到stall的时候,阻止其余statements开始执行,若是一个statement执行超过了stall time,它将会继续执行,可是不在阻止其余statement开始执行。用这种方法,thread pool尝试确保每一个thread group历来没有超过一个short-running statement,尽管会有多个long-running statement。让长时间执行的语句阻止其余语句的执行,这是不可取的,由于没有限制等待的最长时间.例如,在一个replication的master,一个线程一直发送binlog给slave。

一个statement由于I/O操做或者用户级别的锁被阻塞了,这个阻塞将会致使thread group无效,因此回调函数会通知thread pool确认,而且thread pool会立刻在这个thread group中启动一个新的线程执行其余的statement.当被阻塞的线程返回时,thrad pool容许立刻从新启动。

这里有两种队列(queue),一种是高优先级的队列(high-priority queue),和一种低优先级的队列(low-priority queue).事务中的第一个statement会被分配到低优先级的队列,剩下的statement将会被分配到高优先级的队列里(前提是这个事务已经开始执行了),或者被分配到低优先级队列。
队列的分配受到thread_pool_high_priority_connection系统变量影响,这个参数的默认值是0,表示同时使用低优先级队列和高优先级队列,若是值设置为1,全部queued statements都会被直接分配到高优先级的队列。

对于非事务的存储引擎的statements,或者是autocommit的存储引擎,都会被放入低优先级的queue处理,由于每一个statement都是一个事务。所以,使用innodb和myisam混合引擎的数据库,thread pool认为innodb的优先级高于myisam的优先级,除非innodb开启了autocommit。若是autocommit开启,那么全部的statements都属于低优先级。

当thread group选择一个queue中的statement执行的时候,它会优先在高优先级的queue中查找,而后才在低优先级的queue中查找,若是找到tatement,他就会从queue中删除这个statement,而后开始执行它。

若是一个statement在低优先级的queue中等待好久,它将被thread pool移动到高优先级的queue里.等待的时间由thread_pool_prio_kickup_timer决定。

thread pool对活跃线程的重用,能够更好的使用CPU caches.这个很小的调整对性能的提高却有很大帮助。

thread group分配多个线程执行statement的状况:
*一个线程开始执行一个statement,可是执行时间达到stalled之后,thread group容许其余线程开始执行其余statement,以前的线程继续执行以前的statement。
*一个线程开始执行一个statement,可是线程被阻塞了,报告给thread pool之后,thread group容许其余线程开始执行其余statement。
*一个线程开始执行一个statement,可是线程被阻塞了,因为阻塞不是发生在代码层,因此没有报告给thread pool。当阻塞时间达到stall之后,thread group容许其余线程执行其余statement。

线程的设计能够针对不断增长的链接具备扩展性,同时他的设计也能够经过限制并发的thread来尽可能避免死锁发生.可是要注意的是,阻塞的线程若是没有报告thread pool,那么thread pool就不会阻塞其余线程的运行,
这种状况可能会致使线程池死锁。
*长时间运行的statments,不多的statements将使用全部的资源,这将致使服务器拒绝全部其余的访问。
*binary log dump线程读取binlog,而后发送给slave,这是一种长时间运行的”statement”,他不会阻止其余的statements运行.
*statement能够被row级别、table级别的锁阻塞,也能够被sleep等其余缘由的锁阻塞,或者其余被阻塞的没有报告thread pool的thread阻塞了。

上面每种状况,都是为了防止死锁,没有快速执行完成的statement将被移动到stalled分类,因此thread group容许其余statement开始执行。因为这个设计,当线程在执行或者被阻塞的时间内,thread pool把这些线程
标记为stalled类型,而后余下的statement将会被执行,它没有拒绝其余statments的执行.

最大的线程数能够达到max_connections和thread_pool_size的和,这种状况只有在全部的链接都在同时执行,而且每一个thread group开启一个listen线程来监听新的statement。这种状况很难发生,可是理论上存在。

Mysql线程池系列三(Oracle Mysql Thread pool调优)

首先明确调优的目的是提升TPS。

thread_pool_size:
是一个很是重要的参数,控制thread pool的性能,具体表现为thread group的数量。只能在server启动以前设置,咱们测试thread pool的结果以下:
*若是主存储引擎是innodb,thread_pool_size设置在16至36之间,大多数状况设置在24到36,咱们尚未发现什么状况须要设置超过36，也只有一些特殊的环境须要设置小于16.
使用DBT2或者sysbench作测试的时候,innodb引擎下一般设置为36个,若是在一些写入特别多的环境,这个值能够设置的更小一些。
*若是主存储引擎是myisam,thread_pool_size须要设置的更低,咱们推荐的值是4到8,更高的值可能会对性能有负面影响。

thread_pool_stall_limit:
这个参数对于处理阻塞和长时间执行的语句很重要。这个时间是从一个statement从开始执行到执行完成总花费的时间,若是超过设置值就被认定为stalled,此时线程池也开始容许执行另外
一个statement。这个值的单位是10毫秒,默认值是6，也就是默认间隔是60ms,一个statement执行超过60ms,就被认为是stalled。最大值是600,也就是6秒。通常这个值设置为你99%的statement能够执行完的时间。好比我慢查询设置的
是0.1,那么这里就设置为10。另外能够经过
SELECT SUM(STALLED_QUERIES_EXECUTED) / SUM(QUERIES_EXECUTED) FROM information_schema.TP_THREAD_GROUP_STATS;来获取stalled的比例,这个值尽可能的小,为了不stall,能够调高thread_pool_stall_limit的值。

thread_pool_prio_kickup_timer:
这个值影响低优先级的statements的queue。参数值的单位是毫秒,低优先级的statement须要等到多少毫秒才能被移动到高优先级的queue.默认是1000,也就是1秒,值的范围是(0-4294967294)。

thread_pool_high_priority_connection:
这个参数主要决定新来的statements的执行优先级。默认值是0,表示同时使用low-prority queue和high-priority queue。若是设置为1,全部的statement都会分配到high-priority queue。

thread_pool_max_unused_threads:
这个参数限制thread pool中sleeping thread的最大数量。从而限制sleeping thread对内存的使用。
若是参数的值为0,也就是默认值,意味着对sleeping thread没有限制.假设值为N，当N大于0的时候,意味着1个consumer thread和N-1个 reserve thread。意思也就是说,当一个线程执行完一个statement,将要转为sleeping状态的时候,这时sleeping状态的
线程数量已经达到了容许的sleeping thread的最大数量,那么这个线程将会退出。
关于consumer thread:sleeping thread由consumer thread和reserve thread组成,thread pool容许sleeping thread中有一个consumer thread,一个thread要转变为sleepling thread的时候,若是没有consumer thread 存在,那么
这个thread将转变为consumer thread.当一个sleeping thread要被唤醒的时候,若是存在consumer thread,那么优先唤醒consumer thread,若是consumer thread不存在,那么唤醒reserve thread。

thread_pool_algorithm:此参数决定thread pool使用那种算法.默认值是0,表示使用较低的并发算法,在大多数测试和生产环境下效果很好。另一个值是1,更加积极的增长并发数量的算法,有时候会比最佳线程数量性能更好,可是随着链接的增长,性能会逐渐降低。因此这个参数主要用在实验环境。