Percona线程池介绍 - saviochen/mysql_docs GitHub Wiki

1 背景

社区版的MySQL的连接处理方法默认是为每个连接创建一个工作线程的one-thread-per-connection（Per_thread）模式。这种模式下，由于系统的资源是有限的，随着连接数的增加，资源的竞争也增加，连接的响应时间也随之增加，如response time图所示。对于数据库整体吞吐而言，则是在资源未耗尽时随着连接数增加，一旦连接数超过了某个耗尽系统资源的临界点，数据库整体吞吐就会各连接的资源争抢而下降，如下图所示。

如何避免在连接数暴增时，因资源竞争而导致系统吞吐下降的问题呢？MariaDB&&Percona中给出了简洁的答案：线程池。线程池的原理在博客中有生动的介绍，其大致可类比为早高峰期间大量汽车想通过一座大桥，如果采用one-thread-per-connection的方式则放任汽车自由行驶，由于桥面宽度有限，最终将导致所有汽车寸步难行。线程池的解决方案是限制同时行驶的汽车数，让桥面时刻保持最大吞吐，尽快让所有汽车抵达对岸。回归到数据库本身，线程池的思路即为限制同时运行的线程数，减少线程间上下文切换和热锁争用，从而对OLTP工作负载（CPU消耗较少的查询）产生积极影响。当连接数上升时，在线程池的帮助下数据库整体吞吐维持在一个较高水准，如右上图所示。

2 Percona线程池实现

线程池的基本原理为：预先创建一定数量的工作线程（worker线程）。在线程池监听线程（listener线程）从现有连接中监听到新请求时，从工作线程中分配一个线程来提供服务。工作线程在服务结束之后不销毁线程，而是保留在线程池中继续等待下一个请求来临。下面我们将从线程池架构、新连接的创建与分配、listener线程、worker线程、timer线程等几个方面来介绍percona线程池的实现。

2.1 线程池的架构

线程池由有多个线程组（thread group）组成和timer线程组成，如下图所示。线程组的数量是线程池并发的上限，通常而言线程组的数量需要配置成数据库实例的CPU数量，从而充分利用CPU。线程池中还有一个服务于所有线程组的timer线程，负责周期性检查线程组是否处于阻塞状态。当检测到阻塞的线程组时，timer线程会通过唤醒或创建新的工作线程来让线程组恢复工作。

线程组内部由多个worker线程、0或1个listener线程、高低优先级事件队列（由网络事件event构成）、mutex、epollfd、统计信息等组成。如下图所示：

2.2 新连接的创建与分配

新连接接入时，线程池按照新连接的线程id取模线程组个数来确定新连接归属的线程组（thd→thread_id() % group_count）。这样的分配逻辑非常简洁，但由于没有充分考虑连接的负载情况，繁忙的连接可能会恰巧被分配到相同的线程组，从而导致负载不均衡的现象，这是percona线程池值得被优化的点。

选定新连接归属的线程组后，新连接申请被被作为事件放入低优先级队列中，等待线程组中worker线程将高优先级事件队列处理完后，就会处理低优先级的队列中的请求。

2.3 listener线程

listener线程是负责监听连接请求的线程，每个线程组都有一个listener线程。percona线程池的listener采用epoll实现。当epoll监听到请求事件时，listener会根据请求事件的类型来决定将其放入哪个优先级事件队列。将事件放入高优先级队列的条件如下，只需要满足其一即可：

当前线程池的工作模式为高优先级模式，在此模式下只启用高优先级队列。（mode == TP_HIGH_PRIO_MODE_STATEMENTS）
当前线程池的工作模式为高优先级事务模式，在此模式下每个连接的event最多被放入高优先级队列threadpool_high_prio_tickets次。超过threadpool_high_prio_tickets次后，该连接的的请求事件只能被放入低优先级。（mode == TP_HIGH_PRIO_MODE_TRANSACTIONS）
该连接持有表锁
连接持有mdl锁
连接持有全局读锁
接持有backup锁

被放入高优先级事件队列的事件可以优先被worker线程处理。只有当高优先级队列为空，并且当前线程组不繁忙的时候才处理低优先级队列中的事件。线程组繁忙（too_many_busy_threads）的判断条件是当前组内活跃工作线程数+组内处于等待状态的线程数大于线程组工作线程额定值（thread_pool_oversubscribe+1）。这样的设计可能带来的问题是在高优先级队列不为空或者线程组繁忙时低优先级队列中的事件迟迟得不到响应，这同样也是percona线程池值得被优化的一个点。listener线程将事件放入高低优先级队列后，如果线程组的活跃worker数量为0，则唤醒或创建新的worker线程来处理事件。

percona的线程池中listener线程和worker线程是可以互相切换的，详细的切换逻辑会在worker线程模块介绍。epoll监听到请求事件时，如果高低优先级事件队列都为空，意味着此时线程组非常空闲，大概率不存在活跃的worker线程。listener在此情况下会将除第一个事件外的所有事件按前述规则放入高低优先级事件队列，然后退出监听任务，亲自处理第一个事件。这样设计的好处在于当线程组非常空闲时，可以避免listener线程将事件放入队列，唤醒或创建worker线程来处理事件的开销，提高工作效率。

2.4 worker线程

worker线程是线程池中真正干活的线程，正常情况下，每个线程组都会有一个活跃的worker线程。worker在理想状态下，可以高效运转并且快速处理完高低优先级队列中的事件。但是在实际场景中，worker经常会遭遇IO、锁等待等情况而难以高效完成任务，此时任凭worker线程等待将使得在队列中的事件迟迟得不到处理、甚至可能出现长时间没有listener线程监听新请求的情况。为此，每当worker遭遇IO、锁等待等情况，如果此时线程组中没有listener线程或者高低优先级事件队列非空，并且没有过多活跃worker，则会尝试唤醒或者创建一个worker。为了避免短时间内创建大量worker，带来系统吞吐波动，线程池创建worker线程时有一个控制单位时间创建worker线程上限的逻辑，线程组内连接数越多则创建下一个线程需要等待的时间越长。

当线程组活跃worker线程数量大于等于too_many_active_threads+1时，认为线程组的活跃worker数量过多。此时需要对worker数量进行适当收敛，首先判断当前线程组是否有listener线程，如果没有则将当前worker线程转化为listener线程。如果当前有listener线程，则在进入休眠前尝试通过epoll_wait获取一个尚未进入队列的事件，成功获取到后立刻处理该事件，否则进入休眠等待被唤醒，等待threadpool_idle_timeout时间后仍未被唤醒则销毁该worker线程。

worker线程与listener线程的切换如下图所示：

2.5 timer线程

timer线程每隔threadpool_stall_limit时间进行一次所有线程组的扫描（check_stall）。当线程组高低优先级队列中存在事件，并且自上次检查至今没有新的事件被worker消费则认为线程组处于停滞状态。停滞的主要原因可能是长时间执行的非阻塞请求，也可能发生于线程正在等待但 wait_begin/wait_end （尝试唤醒或创建新的worker线程）被上层函数忘记调用的场景。timer线程会通过唤醒或创建新的worker线程来让停滞的线程组恢复工作。timer线程为了尽量减少对正常工作的线程组的影响，在check_stall时采用的是try_lock的方式，如果加不上锁则认为线程组运转良好，不再去打扰。

timer线程除上述工作外，还负责终止空闲时间超过 wait_timeout 秒的客户端。

3 优化方向

3.1 动态线程池

线程池采用一定数量的工作线程来处理用户连接请求，通常比较适应于OLTP工作负载的场景。但线程池并不是万能的，线程池的不足在于当用户请求偏向于慢查询时，工作线程阻塞在高时延操作上，难以快速响应新的用户请求，导致系统吞吐量反而相较于Per_thread模式更低。

Per_thread模式与Thread_pool模式各有优缺点，系统需要根据用户的业务类型灵活地进行切换。遗憾的是，当前两种模式的切换必须重启服务器才能完成。通常而言，两种模式相互转换的需求都是出现在业务高峰时段，此时强制重启服务器将对用户业务造成严重影响。线程池的优化方向之一为实现Per_thread模式与Thread_pool模式间的灵活切换。

3.2 线程池负载均衡

新连接按照线程id取模线程组个数来确定新连接归属的线程组（thd→thread_id() % group_count）。这样的分配方式在未能将各线程组的实际负载考虑在内，因此可能将繁忙的连接分配到相同的线程组，使得线程池出现负载不均衡的现象。线程池的优化方向之二为从队列长度、队列内平均等待时间、worker线程工作效率等多个维度考核，提供一种能根据实例负载情况自动均衡连接压力的方案。

3.3 线程池监听优化

线程池采用epoll来处理网络事件。当epoll监听到网络事件时，listener会将网络事件放入事件队列或自己处理，此时相应用户连接不会被epoll监听。percona线程池需要等到请求处理结束之后才会使用epoll重新监听用户连接的新网络事件。percona线程池这样的设计通常不会带来问题，因为用户连接在请求未被处理时，也不会有发送新请求的需求。但特殊情况下，如果用户连接在重新被epoll监听前自行退出了，此时用户连接发出的断连信号无法被epoll捕捉，因此在mysql服务器端无法及时退出该用户连接。这样带来的影响主要有两点：

用户连接客户端虽已退出，但mysql服务器端却仍在运行该连接，继续消耗CPU、内存资源，甚至可能继续持有锁，只有等到连接超时才能退出；
由于用户连接在mysql服务器端未及时退出，连接数也并未清理，如果用户业务连接数较多，可能导致用户新连接数触达最大连接数上限，用户无法连接数据库，严重影响业务。

4 线程池参数介绍

参数名	参数说明	默认值	有效值范围
thread_pool_idle_timeout	worker线程在没有需要处理的网络事件时，最多等待此时间（单位秒）后销毁	60	（1，UINT_MAX）
thread_pool_oversubscribe	在一个工作组中最多允许多少个worker	3	（1，1000）
thread_pool_size	线程组个数	物理机CPU个数	（1，1000）
thread_pool_stall_limit	每间隔此时间（单位毫秒）timer线程负责遍历检查一次所有线程组。当线程组没有listener、高低优先级队列非空并且没有新增的IO网络事件时认为线程组处于stall状态，timer线程负责唤醒或创建新的worker线程来缓解该线程组的压力。	500	（10，UINT_MAX）
thread_pool_max_threads	线程池中所有worker线程的总数	100000	（1，100000）
thread_pool_high_prio_mode	高优先级队列工作模式，包括三种：transactions：只有一个已经开启了事务的SQL，并且thread_pool_high_prio_tickets不为0，才会进入到高优先级队列中，每个连接在thread_pool_high_prio_tickets次被放到优先队列中后，会移到普通队列中；statement：所有连接都被放入高优先级队列中；none：与statement相反，所有连接都被放入低优先级队列中。	transactions	transactions/statement/none
thread_pool_high_prio_tickets	transactions工作模式下，给每个连接的授予的tickets大小	UINT_MAX	（0，UINT_MAX）
threadpool_workaround_epoll_bug	是否绕过linux2.x中的epoll bug，该bug在linux 3中修复	no	no/yes

5 总结

本文从背景、原理、架构、实现、优化方向、参数状态等方面介绍了percona-线程池。此外，还简单介绍了线程池的动态启停、负载均衡以及监听优化等的优化方向。