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