Backport MariaDB thread pool to MySQL

1. MySQL高并发下线程调度问题
希羽hickey

2. MySQL高并发下线程调度问题
• 背景
– 调度策略的问题及优化方法
• 测试
– 原版和线程池版本的性能对比
• 原理
– 线程池的优化篇原理
• 实战
– 适用的场景及存在的问题，以及推荐的配置

3. 背景
• trunk-5.5版本在一定并发压力下(1000)，查询
不同商品不会受到更新减库存的压力影响。而
达到一定并发后(2000)，查询开始变慢
– 1474线程被suspend
– 52线程写binlog
– 33线程在提交事务
– 查询全部堵在分配读视图(trx_assign_read_view)上
• 普通查询也会trx_start, 分配事务id等。慢的原
因是事务获取kernel mutex时竞争很大。

4. 背景
• MySQL层的线程调度策略
– one-thread (适用于嵌入式系统)
– thread-per-connection (默认)
• 带来的问题
– 并发更新热点记录： http://hickey.in/?p=275
– MySQL层线程管理及调度的额外开销
• 优化的策略
– 在大并发场景下，减少MySQL层真正干活的线程数
量，达到Server层和InnoDB层整体性能最优的目的
– MariaDB线程池：
https://kb.askmonty.org/en/threadpool-in-55/9511/

5. 测试(数据源自IC业务,仅供参考)

6. 线程调度策略对比

7. 线程池--线程池在MySQL中的位置
线程池在MySQL中的位置

8. 线程池—worker线程周期
• 每个工作线程
的运行过程如右
更多参考：
http://hickey.in/?p=288

9. 线程池适用场景及线上运行情况
• 测试的基本结论
• 线上应用场景
核心业务的2备中的一备库，经过双12的实战考验

10. 线程池的参数配置推荐
• thread_pool_oversubscribe 设置较大可以提
高线程同时工作的个数，减少不必要的等
待、唤醒操作。推荐3；
• threadpool_stall_limit ，减少此值可以提高
睡眠线程的工作效率，推荐100
• Thread_pool_size ，建议设置成CPU的个数
• thread_pool_max_threads ，推荐最大连接
数，避免线程池调度上引发的死锁