ITPub博客

首页 > 数据库 > MySQL > Mysql技术理解

Mysql技术理解

原创 MySQL 作者:wzgchen 时间:2015-08-30 21:01:16 0 删除 编辑
线程池技术:

当线程数过多时,如果其中大部分线程都处于活动状态,将会导致频繁的上下文切换,从而造成巨大的系统开销。

上下文切换:

什么是线程上下文切换

上下文切换的精确定义可以参考: http://www.linfo.org/context_switch.html。多任务系统往往需要同时执行多道作业。作业数往往大于机器的CPU数,然而一颗CPU同时只能执行一项任务,为了让用户感觉这些任务正在同时进行,操作系统的设计者巧妙地利用了时间片轮转的方式,CPU给每个任务都服务一定的时间,然后把当前任务的状态保存下来,在加载下一任务的状态后,继续服务下一任务。任务的状态保存及再加载,这段过程就叫做上下文切换。时间片轮转的方式使多个任务在同一颗CPU上执行变成了可能,但同时也带来了保存现场和加载现场的直接消耗。(Note. 更精确地说, 上下文切换会带来直接和间接两种因素影响程序性能的消耗. 直接消耗包括: CPU寄存器需要保存和加载, 系统调度器的代码需要执行, TLB实例需要重新加载, CPU 的pipeline需要刷掉; 间接消耗指的是多核的cache之间得共享数据, 间接消耗对于程序的影响要看线程工作区操作数据的大小).

context-switch

根据上面上下文切换的定义,我们做出下面的假设:

  1. 之所以TwoThreadSwitchTester执行速度最慢,因为线程上下文切换的次数最多,时间主要消耗在上下文切换了,两个线程交替计数,每计数一次就要做一次线程切换。
  2. “Multi Threads - 100 Threads”比“Multi Threads - 2 Threads”开的线程数量要多,导致线程切换次数也比后者多,执行时间也比后者长。

干活的其实是CPU,而不是线程

再想想原来学过的知识,之前一直以为线程多干活就快,简直是把学过的计算机原理都还给老师了。真正干活的不是线程,而是CPU。线程越多,干活不一定越快。

那么高并发的情况下什么时候适合单线程,什么时候适合多线程呢?

适合单线程的场景:单个线程的工作逻辑简单,而且速度非常快,比如从内存中读取某个值,或者从Hash表根据key获得某个value。Redis和Node.js这类程序都是单线程,适合单个线程简单快速的场景。

适合多线程的场景:单个线程的工作逻辑复杂,等待时间较长或者需要消耗大量系统运算资源,比如需要从多个远程服务获得数据并计算,或者图像处理。


InnoDB使用操作系统线程来处理用户事务请求,它是这样工作的:当InnoDB收到一个用户的请求时,如果已经超过innodb_thread_concurrency预先设置的并发线程数量,那么就会按照innodb_thread_sleep_delay预先设定的值休眠N秒,之后再次尝试连接,重试两次的机制是为了减少CPU上下文切换的次数,以降低CPU消耗。如果请求被接受了,则会获得一个innodb_concurrency_tickets默认500次的通行证,在这些次数用完之前,该线程重新请求时无须再进行前面所说的innodb_thread_concurrency的检查。如果还没有被接受,那么就会进入队列中,直到最终被处理掉。

从MySQL5.5.X版本开始,innodb_thread_concurrency被默认设置为0,表示不限制并发数,表1-2中是该参数的历史默认值。


线程池技术:就是线程复用,多个连接共享线程


binlog group commit技术

在开启binlog的情况下,为了保证主库和从库之间数据的一致性,mariadb/mysq使用了事务的2阶段提交协议,在这种情况下,为了满足数据的持久化需求,一个事务的提交最多会导致3次fsync操作。
为了提高mariadb/mysql在开启binlog的情况下单位时间内的事务提交数,就必须减少每个事务提交过程上导致的fsync的调用次数。binlog gorup commit的基本思想是多个并发提交的事务之间共用一次fsync操作来实现事务对binlog修改的持久化。


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/91975/viewspace-1786814/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2015-05-01

  • 博文量
    383
  • 访问量
    178613