MySQL多线程并发调优

简介:

前言

学习MySQL数据库技术,一个非常重要的技能就是性能调优。通常情况下,都是自下而上的调优方法,主要包括运行环境、配置参数、SQL性能和系统架构设计调优等。

本文从多线程并发的角度进行的思考,简单描述MySQL并发参数及其调优。

MySQL并发模型

架构

mysql_arch

Innodb用自己的线程调度机制来控制线程如何进入innodb内核工作,并执行相关的操作。

  • 当一个线程需要进入到Innodb存储引擎层(以下简称Innodb),Innodb会检查已经进入到Innodb存储引擎层的线程总数是否超过innodb_thread_concurrency;
    • 如果超过了,则该线程需要等待innodb_thread_sleep_delay毫秒再次进行尝试;
    • 如果尝试仍然失败,该线程将会进入到FIFO的队列中进行等待唤醒(此时状态为sleeping)。
  • 一旦该thread进入到INNODB中,该线程将会获得innodb_concurrency_tickets次通行证,即该线程在接下来的innodb_concurrency_tickets次进入到INNODB中都不需要再进行检查,可直接进入。
  • 线程尝试两次进入INNODB存储引擎层的目的是,减少等待线程的数量以及减少上下文切换。

Innodb的这种两阶段的机制减少了操作系统因为线程之间的上下文切换带来的开销。

Innodb concurrency相关参数

  • innodb_thread_concurrency

    • 同一时刻能够进入innodb层并发执行的线程数量。如果超过CPU核数,某些线程就会处于就绪状态;若Server层线程数超过这个数值,多余的线程会被放到wait queue队列中等待;
    • 默认值:0,表示不限制线程并发执行的数量,所有请求都会被认为是可调度的。此时,innodb_thread_sleep_delay的值会被忽略
    • 范围:0 ~ 1000
  • innodb_commit_concurrency

    • 同一时刻允许同时commit的线程数量
    • 默认值:0,即不限制
    • 范围:0 ~ 1000
    • 如果 innodb_thread_concurrency 设置的有点大innodb_commit_concurrency应该做出相应的调整,否则会造成大量线程阻塞。
  • innodb_concurrency_tickets

    • thread进入INNODB中,会获得innodb_concurrency_tickets次通行,该线程在接下来的innodb_concurrency_tickets次进入到INNODB中不需要再进行检查,可直接进入。
    • 默认值:5000
    • 范围:0 ~ 4294967295
  • innodb_thread_sleep_delay

    • 线程未能进入INNODB存储引擎,需要等待innodb_thread_sleep_delay毫秒再次尝试进入;即进入wait queue前sleep的时间;
    • 单位:微妙
    • 默认值:10000

建议值

如下建议来自MySQL官网。详情请参考https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_thread_concurrency

  • 如果一个工作负载中,并发用户线程的数量小于64,建议设置innodb_thread_concurrency=0;
  • 如果工作负载一直较为严重甚至偶尔达到顶峰,建议先设置innodb_thread_concurrency=128,并通过不断的降低这个参数,96, 80, 64等等,直到发现能够提供最佳性能的线程数。
    • 例如,假设系统通常有40到50个用户,但定期的数量增加至60,70,甚至200。你会发现,性能在80个并发用户设置时表现稳定,如果高于这个数,性能反而下降。在这种情况下,建议设置innodb_thread_concurrency参数为80,以避免影响性能。
  • 如果你不希望InnoDB使用的虚拟CPU数量比用户线程使用的虚拟CPU更多(比如20个虚拟CPU),建议通过设置innodb_thread_concurrency 参数为这个值(也可能更低,这取决于性能体现),如果你的目标是将MySQL与其他应用隔离,你可以考虑绑定mysqld进程到专有的虚拟CPU。
    • 但是需要注意的是,这种绑定,在myslqd进程一直不是很忙的情况下,可能会导致非最优的硬件使用率。在这种情况下,你可能会设置mysqld进程绑定的虚拟CPU,允许其他应用程序使用虚拟CPU的一部分或全部。
  • 在某些情况下,最佳的innodb_thread_concurrency参数设置可以比虚拟CPU的数量小。
  • 定期检测和分析系统,负载量、用户数或者工作环境的改变可能都需要对innodb_thread_concurrency参数的设置进行调整。

观察

可以通过如下命令观察参数及状态。

mysql> show variables like '%concurrency%';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| innodb_commit_concurrency  | 0     |
| innodb_concurrency_tickets | 5000  |
| innodb_thread_concurrency  | 0     |
| thread_concurrency         | 10    |
+----------------------------+-------+
4 rows in set (0.00 sec)
mysql> select trx_id,trx_state,trx_query,trx_operation_state,trx_concurrency_tickets from information_schema.innodb_trx ;
+----------+-----------+--------------------------------------+---------------------+-------------------------+
| trx_id   | trx_state | trx_query                            | trx_operation_state | trx_concurrency_tickets |
+----------+-----------+--------------------------------------+---------------------+-------------------------+
| 45956096 | RUNNING   | select count(*) from tb_test         | committing          |                       0 |
+----------+-----------+--------------------------------------+---------------------+-------------------------+
1 row in set (0.38 sec)
mysql> show engine innodb status \G;
*************************** 1. row ***************************
  Type: InnoDB
  Name:
Status:
=====================================
180612 11:27:51 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 4 seconds
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 40092798, signal count 27800089
Mutex spin waits 0, rounds 1448336939, OS waits 27203399
RW-shared spins 5866534, OS waits 2555867; RW-excl spins 16147805, OS waits 6633709
------------
TRANSACTIONS
------------
Trx id counter 0 918627542
Purge done for trx's n:o < 0 918627313 undo n:o < 0 0
History list length 63
LIST OF TRANSACTIONS FOR EACH SESSION:
...
---TRANSACTION 0 918627501, not started, process no 13429, OS thread id 1191389504
MySQL thread id 29134175, query id 378160830 ...

...

---TRANSACTION 0 918627539, not started, process no 13429, OS thread id 1075824960
MySQL thread id 29133262, query id 378160869 localhost 127.0.0.1 apsara
--------
FILE I/O
--------
I/O thread 0 state: waiting for i/o request (insert buffer thread)
I/O thread 1 state: waiting for i/o request (log thread)
I/O thread 2 state: waiting for i/o request (read thread)
I/O thread 3 state: waiting for i/o request (write thread)
Pending normal aio reads: 0, aio writes: 0,
 ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
18053159 OS file reads, 61697040 OS file writes, 34602915 OS fsyncs
2.75 reads/s, 16384 avg bytes/read, 4.75 writes/s, 4.75 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 5, seg size 7,
664776 inserts, 664776 merged recs, 13693 merges
Hash table size 17393, node heap has 22 buffer(s)
37.99 hash searches/s, 36.74 non-hash searches/s
---
LOG
---
Log sequence number 21 621309414
Log flushed up to   21 621309414
Last checkpoint at  21 621282806
0 pending log writes, 0 pending chkp writes
32082113 log i/o's done, 4.75 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 21774746; in additional pool allocated 1044224
Dictionary memory allocated 639320
Buffer pool size   512
Free buffers       0
Database pages     490
Modified db pages  52
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages read 70252515, created 255750, written 41909328
2.75 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 991 / 1000
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread process no. 13429, id 1167427904, state: sleeping
Number of rows inserted 372775, updated 74210855, deleted 4797, read 3912463894
0.00 inserts/s, 12.75 updates/s, 0.00 deletes/s, 134.72 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================

1 row in set (0.00 sec)

ERROR:
No query specified

Reference

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
目录
相关文章
|
3月前
|
设计模式 缓存 安全
【JUC】(6)带你了解共享模型之 享元和不可变 模型并初步带你了解并发工具 线程池Pool,文章内还有饥饿问题、设计模式之工作线程的解决于实现
JUC专栏第六篇,本文带你了解两个共享模型:享元和不可变 模型,并初步带你了解并发工具 线程池Pool,文章中还有解决饥饿问题、设计模式之工作线程的实现
245 2
|
6月前
|
Java API 调度
从阻塞到畅通:Java虚拟线程开启并发新纪元
从阻塞到畅通:Java虚拟线程开启并发新纪元
394 83
|
6月前
|
存储 Java 调度
Java虚拟线程:轻量级并发的革命性突破
Java虚拟线程:轻量级并发的革命性突破
398 83
|
8月前
|
机器学习/深度学习 消息中间件 存储
【高薪程序员必看】万字长文拆解Java并发编程!(9-2):并发工具-线程池
🌟 ​大家好,我是摘星!​ 🌟今天为大家带来的是并发编程中的强力并发工具-线程池,废话不多说让我们直接开始。
323 0
|
8月前
|
设计模式 运维 监控
并发设计模式实战系列(4):线程池
需要建立持续的性能剖析(Profiling)和调优机制。通过以上十二个维度的系统化扩展,构建了一个从。设置合理队列容量/拒绝策略。动态扩容/优化任务处理速度。检查线程栈定位热点代码。调整最大用户进程数限制。CPU占用率100%
554 0
|
缓存 关系型数据库 MySQL
MySQL索引策略与查询性能调优实战
在实际应用中,需要根据具体的业务需求和查询模式,综合运用索引策略和查询性能调优方法,不断地测试和优化,以提高MySQL数据库的查询性能。
647 66
|
8月前
|
存储 缓存 安全
JUC并发—11.线程池源码分析
本文主要介绍了线程池的优势和JUC提供的线程池、ThreadPoolExecutor和Excutors创建的线程池、如何设计一个线程池、ThreadPoolExecutor线程池的执行流程、ThreadPoolExecutor的源码分析、如何合理设置线程池参数 + 定制线程池。
JUC并发—11.线程池源码分析
|
9月前
|
SQL 关系型数据库 MySQL
大数据新视界--大数据大厂之MySQL数据库课程设计:MySQL 数据库 SQL 语句调优方法详解(2-1)
本文深入介绍 MySQL 数据库 SQL 语句调优方法。涵盖分析查询执行计划,如使用 EXPLAIN 命令及理解关键指标;优化查询语句结构,包括避免子查询、减少函数使用、合理用索引列及避免 “OR”。还介绍了索引类型知识,如 B 树索引、哈希索引等。结合与 MySQL 数据库课程设计相关文章,强调 SQL 语句调优重要性。为提升数据库性能提供实用方法,适合数据库管理员和开发人员。
|
SQL 安全 关系型数据库
【MySQL基础篇】事务(事务操作、事务四大特性、并发事务问题、事务隔离级别)
事务是MySQL中一组不可分割的操作集合,确保所有操作要么全部成功,要么全部失败。本文利用SQL演示并总结了事务操作、事务四大特性、并发事务问题、事务隔离级别。
5256 56
【MySQL基础篇】事务(事务操作、事务四大特性、并发事务问题、事务隔离级别)

推荐镜像

更多