MySQL高并发下线程调度问题

希羽hickey

MySQL高并发下线程调度问题

• 背景

– 调度策略的问题及优化方法

• 测试

– 原版和线程池版本的性能对比

• 原理

– 线程池的优化篇原理

• 实战

– 适用的场景及存在的问题，以及推荐的配置

背景

• trunk-5.5版本在一定并发压力下(1000)，查询

不同商品不会受到更新减库存的压力影响。而达到一定并发后(2000)，查询开始变慢

– 1474线程被suspend

– 52线程写binlog

– 33线程在提交事务

– 查询全部堵在分配读视图(trx_assign_read_view)上

• 普通查询也会trx_start, 分配事务id等。慢的原因是事务获取kernel mutex时竞争很大。

背景

• 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/

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

线程调度策略对比

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

线程池在MySQL中的位置

线程池—worker线程周期

• 每个工作线程

的运行过程如右

更多参考：

http://hickey.in/?p=288

线程池适用场景及线上运行情况

• 测试的基本结论

• 线上应用场景 核心业务的2备中的一备库，经过双12的实战考验

线程池的参数配置推荐

• thread_pool_oversubscribe 设置较大可以提

高线程同时工作的个数，减少不必要的等待、唤醒操作。推荐3；

• threadpool_stall_limit ，减少此值可以提高睡眠线程的工作效率，推荐100

• Thread_pool_size ，建议设置成CPU的个数

• thread_pool_max_threads ，推荐最大连接数，避免线程池调度上引发的死锁