MySQL · 特性分析 · 线程池

概述

MySQL 原有线程调度方式有每个连接一个线程(one-thread-per-connection)和所有连接一个线程(no-threads)。

no-threads一般用于调试,生产环境一般用one-thread-per-connection方式。one-thread-per-connection 适合于低并发长连接的环境,而在高并发或大量短连接环境下,大量创建和销毁线程,以及线程上下文切换,会严重影响性能。另外 one-thread-per-connection 对于大量连接数扩展也会影响性能。

为了解决上述问题,MariaDB、Percona、Oracle MySQL 都推出了线程池方案,它们的实现方式大体相似,这里以 Percona 为例来简略介绍实现原理,同时会介绍我们在其基础上的一些改进。

实现

线程池方案下,用户的每个连接不再对应一个线程。线程池由一系列 worker 线程组成,这些worker线程被分为thread_pool_size个group。用户的连接按 round-robin 的方式映射到相应的group 中,一个连接可以由一个group中的一个或多个worker线程来处理。

  1. listener 线程
    每个group中有一个listener线程,通过epoll的方式来监听本group中连接的事件。listener线程同时也是worker线程,listener线程不是固定的。
    listener线程监听到连接事件后会将事件放入优先级队列中,listener线程作为worker线程也处理一些连接事件,以减少上下文切换。
    listener线程会检查优先级队列是否为空,如果为空表示网络空闲,listener线程会作为worker线程处理第一个监听事件,其他事件仍然放入优先级队列中。
    另外,当没有活跃线时,listener会唤醒一个线程,如果没有线程可以唤醒,且当前group只有一个线程且为listener,则创建一个线程。
  2. 优先级队列
    分为高优先级队列和普通队列,已经开启的事务并且tickets不为0,放入高优先队列,否则放入普通队列。每个连接在thread_pool_high_prio_tickets次被放到优先队列中后,会移到普通队列中。worker线程先从高优先队列取event处理,只有当高优先队列为空时才从普通队列取event处理。
    通过优先级队列,可以让已经开启的事务或短事务得到优先处理,及时提交释放锁等资源。
  3. worker 线程
    worker线程负责从优先队列取事件处理。如果没有取到event,会尝试从epoll中取一个,如果没有取到再进入等待,如果等待超过thread_pool_idle_timeout worker线程会退出。
  4. timer 线程
    每隔thread_pool_stall_limit时间检查一次。

    • listener没有接收新的事件,listener正在等待时需调用wake_or_create_thread,重新创建listener;
    • 从上一次检查起,worker线程没有收到新的事件,并且队列不为空,则认为发生了stall,需唤醒或创建worker线程;
    • 检查net_wait_timeout是否超时,如果超时退出连接,而不是退出worker线程。
  5. 何时唤醒或创建worker线程
    • 从队列中取事件时发现没有活跃线程时;
    • worker线程发生等待且没有活跃线程时;
    • timer线程认为发生了stall;

重要参数解析

  1. thread_pool_oversubscribe
    一个group中活跃线程和等待中的线程超过thread_pool_oversubscribe时,不会创建新的线程。
    此参数可以控制系统的并发数,同时可以防止调度上的死锁,考虑如下情况,A、B、C三个事务,A、B 需等待C提交。A、B先得到调度,同时活跃线程数达到了thread_pool_max_threads上限,随后C继续执行提交,此时已经没有线程来处理C提交,从而导致A、B一直等待。thread_pool_oversubscribe控制group中活跃线程和等待中的线程总数,从而防止了上述情况。
  2. thread_pool_stall_limit
    timer线程检测间隔。此参数设置过小,会导致创建过多的线程,从而产生较多的线程上下文切换,但可以及时处理锁等待的场景,避免死锁。参数设置过大,对长语句有益,但会阻塞短语句的执行。参数设置需视具体情况而定,例如99%的语句10ms内可以完成,那么我们可以将就thread_pool_stall_limit设置为10ms

一些改进

  1. lock tables read 的处理
    对于声明 lock tables read 等明确声明表锁的事件,放入高优先级队列。
  2. binlog dump线程的处理
    binlog dump线程是典型的长事务场景,当多个binlog dump线程分配到同一个group中时,group中的线程很容易超过thread_pool_oversubscribe限制,从而导致性能下降。
    优化方法是修改binlog dump线程不受thread_pool_oversubscribe限制。
  3. 丰富诊断信息information_schema.thread_group_status
     show create table THREAD_GROUP_STATUS\G
     *************************** 1. row ***************************
            Table: THREAD_GROUP_STATUS
     Create Table: CREATE TEMPORARY TABLE `THREAD_GROUP_STATUS` (
       `ID` int(21) unsigned NOT NULL DEFAULT '0',
       `THREAD_COUNT` int(21) unsigned NOT NULL DEFAULT '0',
       `ACTIVE_THREAD_COUNT` int(21) unsigned NOT NULL DEFAULT '0',
       `CONNECTION_COUNT` int(21) unsigned NOT NULL DEFAULT '0',
       `WAITING_THREAD_COUNT` int(21) unsigned NOT NULL DEFAULT '0',
       `DUMP_COUNT` bigint(21) unsigned NOT NULL DEFAULT '0',
       `LOW_QUEUE_COUNT` bigint(21) unsigned NOT NULL DEFAULT '0',
       `HIGH_QUEUE_COUNT` bigint(21) unsigned NOT NULL DEFAULT '0'
     ) ENGINE=MEMORY DEFAULT CHARSET=utf8
    
  4. 线程池调度异常,无法连接的处理
    对于本地登录的用户,走老的one_thread_per_connection逻辑,从而解决无法连接的情况。

连接池和线程池的区别

最后说一点连接池和线程池的区别。连接池和线程池是两个独立的概念,连接池是在客户端的优化,缓存客户的连接,避免重复创建和销毁连接。而线程池是服务器端的优化。两者的优化角度不同,不相关,因此两种优化可以同时使用。

时间: 2024-10-24 04:09:27

MySQL · 特性分析 · 线程池的相关文章

MySQL · 特性分析 · 企业版特性一览

背景 MySQL 企业版由 Oracle 公司维护,当然也是收费的.其产品类别也基本和 Oracle 数据库一致,包括标准版.企业版.集群版等.标准版包括基本的特性,价格也会比企业版便宜很多.今天和小编一起来看下 MySQL Enterprise Edition 提供的一些功能,这些功能的源码当然是不开源的,也是企业版的卖点. 企业级备份恢复 备份 备份工具提供 InnoDB 的联机在线备份,同时 MyISAM 引擎的备份会阻塞写入.联机备份是否阻塞应用,还要根据引擎的特性来定.这点上,Perc

MySQL · 特性分析 · MDL 实现分析

前言 在MySQL中,DDL是不属于事务范畴的,如果事务和DDL并行执行,操作相关联的表的话,会出现各种意想不到问题,如事务特性被破坏.binlog顺序错乱等,为了解决类似这些问题,MySQL在5.5.3引入了MDL锁(Metadata Locking),关于其设计思路可以参考这两个worklog:WL#3726 和 WL#4284.本篇从代码实现角度对MDL进行分析. 重要数据结构 MDL 是在 MySQL server 层实现的一个模块,通过对外接口和server层其它模块进行交互,在sql

MySQL · 特性分析 · InnoDB transaction history

1. 背景 在写压力负载比较重的MySQL实例上, InnoDB可能积累了较长的没有被purge掉的transaction history,导致实例性能的衰减,或者空闲空间被耗尽,下面就来看看它是怎么产生的,或者有没有什么方法来减轻,避免这样的问题出现. 2. InnoDB purge概要 InnoDB是一个事务引擎,实现了MVCC特性,也就是在存储引擎里对行数据保存了多个版本.在对行数据进行delete或者update更改时,行数据的前映像会保留一段时间,直到可以被删除的时候. 在大部分OLT

MySQL · 特性分析 · MySQL 5.7 外部XA Replication实现及缺陷分析

MySQL 5.7 外部XA Replication实现及缺陷分析 MySQL 5.7增强了分布式事务的支持,解决了之前客户端退出或者服务器关闭后prepared的事务回滚和服务器宕机后binlog丢失的情况. 为了解决之前的问题,MySQL5.7将外部XA在binlog中的记录分成了两部分,使用两个GTID来记录.执行prepare的时候就记录一次binlog,执行commit/rollback再记录一次.由于XA是分成两部分记录,那么XA事务在binlog中就可能是交叉出现的.Slave端的

MySQL · 特性分析 ·MySQL 5.7新特性系列四

继上三期月报:MySQL 5.7新特性之一介绍了一些新特性及兼容性问题MySQL 5.7新特性之二介绍了临时表的优化和实现MySQL 5.7新特性之三介绍了undo表空间的truncate功能 这期我们一起来学习下MySQL 5.7的并行复制. 1. 背景 MySQL的master<->slave的部署结构,使用binlog日志保持数据的同步,全局有序的binlog在备库按照提交顺序进行回放. 由于新硬件的发展,SSD的引入和多core的CPU,master节点的并发处理能力持续提升,slav

MySQL · 特性分析 · innodb buffer pool相关特性

背景 innodb buffer pool做为innodb最重要的缓存,其缓存命中率的高低会直接影响数据库的性能.因此在数据库发生变更,比如重启.主备切换实例迁移等等,innodb buffer poll 需要一段时间预热,期间数据库的性能会受到明显影响. 另外mysql 5.7以前innodb buffer pool缓存大小修改不是动态的,重启才能生效.因此innodb buffer pool的预热和innodb buffer pool大小的动态修改,对性能要求较高的应用来说是不错的特性,下面

MySQL · 特性分析 · 优化器 MRR &amp; BKA

上一篇文章咱们对 ICP 进行了一次全面的分析,本篇文章小编继续为大家分析优化器的另外两个选项: MRR & batched_key_access(BKA) ,分析一下他们的作用.原理.相互关系.源码实现以及使用范围. 什么是 MRR MRR 的全称是 Multi-Range Read Optimization,是优化器将随机 IO 转化为顺序 IO 以降低查询过程中 IO 开销的一种手段,咱们对比一下 mrr=on & mrr=off 时的执行计划: 其中表结构如下: mysql>

MySQL · 特性分析 ·MySQL 5.7新特性系列三

继上两期月报,MySQL5.7新特性之一介绍了一些新特性及兼容性问题,MySQL 5.7新特性之二介绍了临时表的优化和实现. 这期我们一起来学习下undo空间管理,重点介绍truncate功能. 1. 背景 InnoDB存储引擎中,undo在完成事务回滚和MVCC之后,就可以purge掉了,但undo在事务执行过程中,进行的空间分配如何回收,就变成了一个问题. 我们亲历用户的小实例,因为一个大事务,导致ibdata file到800G大小. 我们先大致看下InnoDB的undo在不同的版本上的一

MySQL · 特性分析 · LOGICAL_CLOCK 并行复制原理及实现分析

在MySQL5.7 引入基于Logical clock的并行复制方案前,MySQL使用基于Schema的并行复制,使不同db下的DML操作可以在备库并发回放.在优化后,可以做到不同表table下并发.但是如果业务在Master端高并发写入一个库(或者优化后的表),那么slave端就会出现较大的延迟.基于schema的并行复制,Slave作为只读实例提供读取功能时候可以保证同schema下事务的因果序(Causal Consistency,本文讨论Consistency的时候均假设Slave端为只