Chinaunix首页 | 论坛 | 认证专区 | 博客 登录 | 注册

王恒-Henryhengwang.blog.chinaunix.net

我的项目:https://github.com/HengWang/

  • 博客访问: 1072607
  • 博文数量: 112
  • 博客积分: 1715
  • 博客等级: 上尉
  • 技术积分: 3168
  • 用 户 组: 普通用户
  • 注册时间: 2012-04-18 18:42
个人简介

阿里巴巴DBA,原去哪儿网DBA。专注于MySQL源码研究、DBA运维、CGroup虚拟化及Linux Kernel源码研究等。 github:https://github.com/HengWang/ Email:king_wangheng@163.com 微博 :@王恒-Henry QQ :506437736

文章分类

全部博文(112)

文章存档

2014年(2)

2013年(39)

2012年(71)

微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

订阅
热词专题

分类: Mysql/postgreSQL


基于《MySQL学习分享--Thread pool》对Thread pool架构设计的详细了解,本文主要对Thread pool的实现进行分析,并根据MariadbPercona提供的开源实现,进行简单的比较和评估。

1、《The Thread Pool Plugin》

MySQL官方文档中,对Thread pool进行了详细的介绍,主要从实现和使用角度进行了说明。MySQL企业版实现通过插件方式实现,对源码逻辑没有侵入,是比较友好的方式。文档描述的实现机制方面,跟架构设计基本无出入。

其中,thread_pool_size控制线程组的大小,thread_pool_stall_limit标志sql执行异常的情况,thread_pool_prio_kickup_timer控制用户线程的优先级转化。

根据文档提供的信息,以及架构设计的思想,抽象出以下几种处理逻辑:

1.1 No executing and empty queue

在当前线程组内,既没有当前执行的sql语句,也没有等待的用户线程在队列中时,线程组内的监听线程立即执行当前用户请求的sql。具体逻辑如下图所示:

 

1.1 No executing and empty queue

图中是一个线程组内流程,每个线程组内有两个优先级队列(high/low priority queue),当前没有执行sql并且队列为空时,新的用户连接的请求,监听线程会立即执行sqlDB

1.2 Low priority queue

当前线程组内的高优先级队列为空,低优先级的队列不为空时,监听线程会从低优先级队列中取用户请求,执行sqlDB。具体处理逻辑如下图所示:

 

1.2 Low priority queue

特别的,如果一个事务有多条sql,当从低优先级队列中取第一条sql开始执行时,该事务的其他sql语句,全部进入高优先级队列。

1.3 High priority queue

在当前线程组内,如果高优先级队列中有用户请求,监听线程会优先从高优先级队列中取用户请求,优先执行sqlDB。高优先级队列执行完了,再从低优先级队列中取用户请求。

 

1.3 High priority queue

此外,参数thread_pool_high_priority_connection会将当前session中的所有sql迁移到高优先级队列中。

1.4 Priority kickup timer

在低优先级队列中的用户请求超过thread_pool_prio_kickup_timer时间时,会从低优先级队列中迁移到高优先队列中。具体的处理逻辑如下图所示:

 

1.4 Priority kickup timer

1.5 Stall limit

当监听线程由于大事务阻塞,超过thread_pool_stall_limit数限制时,监听线程继续执行,同时启动新的监听线程,从队列中继续往下执行。具体逻辑如下所示:

 

1.5 Stall limit

通过以上分析可知,thread_pool_stall_limitthread_pool_prio_kickup_timer参数是主要的性能优化参数。如果thread_pool_stall_limit设置与业务场景不匹配时,会导致单个线程组内有大量的执行线程,这样就会导致持续创建监听线程,并且大量的线程切换。而thread_pool_prio_kickup_timer参数设置不合理,将会导致频繁的从低优先级队列迁移到高优先级队列,消耗大量的系统资源。因此在性能优化时,需要根据业务模型和场景进行测试和设置。

2、《Thread pool in MariaDB 5.5》

MariaDB 5.5引入了Thread pool,设计思想与MySQL企业版设计几乎一致。MariaDB嵌入到Server层,而没有使用插件的方式,这是实现上的一个重大差别。MariaDB通过thread_handling设置线程类型实现线程池和one-to-one方式方式的转化。从实现角度来看,通过配置文件设置该参数,不能动态调整。

两者设计上都采用了线程组,但是MariaDB将实现进行了进一步的细化,增加了thread_pool_max_threads参数控制线程池的最大线程数。此外,针对不同的系统,采用不同的IO复用方式,提高性能。

两者都通过thread_pool_stall_limit参数避免大事务阻塞的问题。但是没有分Low/High priority queue,也没有thread_pool_prio_kickup_timer参数影响队列之间的转化。MariaDB通过thread_pool_stall_limit来避免大事务的阻塞,并且不限制线程的并发,因此也不需要优先级队列的方式,防止事务持续不被执行的饥饿问题。从这一点上来看,MySQL的设计更加合理一点,在大量大事务阻塞的时候,并发数较多,因抢占资源性能降低,而小事务由于阻塞会长时间得不到响应。

MariaDB引入extra-portextra-max-connections参数,用于防止在没有连接资源时,super用户可以登陆进行管理操作。

3、《Thread pool》

PerconaThread pool是基于MariaDB的实现,并参考了MySQL的设计思想,进行了优化和改进。

Percona参考MySQL的优先级队列思想,将队列分为高优先级队列和普通队列。引入thread_pool_high_prio_tickets参数,当满足一定条件时,用户请求会从普通队列中移到高优先级队列中。正是MariaDB中分析的,目标是降低用户连接的并发数。

结论

通过以上内容分析可知,Thread pool的实现来看,设计思想基本上一致。从实现来看,MySQL企业版实现采用Plugin的方式,可以动态操作,不影响正常逻辑。而MariaDBPercona采用buildin的方式,通过配置文件,不够灵活。从实现细节来看,MariaDB除了优先级队列之外,与MySQL企业版基本实现思想一致,但是在很多方面都进行了优化和精细。Percona基于MariaDB的实现,参考MySQL企业版的优先级队列,进行了优化和改进。

总体来看,PerconaThread pool作为开源的实现,与MySQL企业版的设计思想中提到的几个问题,也都很好的解决,应该是使用和了解Thread pool实现的最佳选择。

参考

1、《The thread pool plugin》:http://mikaelronstrom.blogspot.com/2011/10/mysql-thread-pool-problem-definition.html

2、《Thread pool operation》:http://mikaelronstrom.blogspot.com/2011/10/mysql-thread-pool-scalability-solution.html

3、《Thread pool tuning》:http://mikaelronstrom.blogspot.com/2011/10/mysql-thread-pool-limiting-number-of.html

4、《Thread pool in MariaDB 5.5》:http://mikaelronstrom.blogspot.com/2011/10/mysql-thread-pool-limiting-number-of_21.html

5、《Thread pool》:http://mikaelronstrom.blogspot.com/2011/10/mysql-thread-pool-when-to-use.html

阅读(12921) | 评论(2) | 转发(4) |
给主人留下些什么吧!~~

king_wangheng2013-12-31 22:14:50

yaodanlou:你好,王恒,关注你的文章有段时间了,我的建议是,你最好和CHINAUNIX社区的一些人一起出一本《MYSQL源代码分析》算了。为什么呢,因为现在有分析LINUX源代码的书,有分析APACHE源代码的书,还有分析各类开源源代码的书,但市面上唯独没有分析MYSQL源代码和分析PHP源代码的书(注意:我说的PHP源代码不是指用PHP写个网站的程序源代码,我是指构建PHP这门编程语言的源代码),你有这方面的天赋,建设你把你这些年的经验出书MYSQL源代码分析的书吧,我再来拜读。我不是出版社人,只是作为一个技术人员的一点小建议,你可以不同意,呵呵。等你回复。直接回复在下面好了。我会看到。

谢谢你的建议,一直以来都有这个打算了,但是现在工作比较忙,时间上可能不允许。等有时间允许,我会考虑将自己的东西串联起来,供大家批评指正。

回复 | 举报

yaodanlou2013-12-27 15:17:27

你好,王恒,关注你的文章有段时间了,我的建议是,你最好和CHINAUNIX社区的一些人一起出一本《MYSQL源代码分析》算了。为什么呢,因为现在有分析LINUX源代码的书,有分析APACHE源代码的书,还有分析各类开源源代码的书,但市面上唯独没有分析MYSQL源代码和分析PHP源代码的书(注意:我说的PHP源代码不是指用PHP写个网站的程序源代码,我是指构建PHP这门编程语言的源代码),你有这方面的天赋,建设你把你这些年的经验出书MYSQL源代码分析的书吧,我再来拜读。我不是出版社人,只是作为一个技术人员的一点小建议,你可以不同意,呵呵。等你回复。直接回复在下面好了。我会看到。

评论热议
请登录后评论。

登录 注册