MySQL多线程并发调优

本文涉及的产品
对象存储 OSS,20GB 3个月
云备份 Cloud Backup,100GB 3个月
阿里云盘企业版 CDE,企业版用户数5人 500GB空间
简介:

前言

学习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

相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
17天前
|
缓存 安全 算法
Java面试题:如何通过JVM参数调整GC行为以优化应用性能?如何使用synchronized和volatile关键字解决并发问题?如何使用ConcurrentHashMap实现线程安全的缓存?
Java面试题:如何通过JVM参数调整GC行为以优化应用性能?如何使用synchronized和volatile关键字解决并发问题?如何使用ConcurrentHashMap实现线程安全的缓存?
13 0
|
10天前
|
SQL 关系型数据库 MySQL
MySQL服务器性能调优的顶级策略14
【7月更文挑战第14天】MySQL服务器性能调优的顶级策略
32 12
|
3天前
|
SQL 关系型数据库 MySQL
mysql性能调优:EXPLAIN命令21
【7月更文挑战第21天】掌握SQL性能调优:深入解析EXPLAIN命令的神奇用法!
14 1
|
8天前
|
安全 算法 Java
Java 中的并发控制:锁与线程安全
在 Java 的并发编程领域,理解并正确使用锁机制是实现线程安全的关键。本文深入探讨了 Java 中各种锁的概念、用途以及它们如何帮助开发者管理并发状态。从内置的同步关键字到显式的 Lock 接口,再到原子变量和并发集合,本文旨在为读者提供一个全面的锁和线程安全的知识框架。通过具体示例和最佳实践,我们展示了如何在多线程环境中保持数据的一致性和完整性,同时避免常见的并发问题,如死锁和竞态条件。无论你是 Java 并发编程的新手还是有经验的开发者,这篇文章都将帮助你更好地理解和应用 Java 的并发控制机制。
|
17天前
|
设计模式 安全 Java
Java面试题:设计模式如单例模式、工厂模式、观察者模式等在多线程环境下线程安全问题,Java内存模型定义了线程如何与内存交互,包括原子性、可见性、有序性,并发框架提供了更高层次的并发任务处理能力
Java面试题:设计模式如单例模式、工厂模式、观察者模式等在多线程环境下线程安全问题,Java内存模型定义了线程如何与内存交互,包括原子性、可见性、有序性,并发框架提供了更高层次的并发任务处理能力
33 1
|
17天前
|
设计模式 安全 Java
Java面试题:请解释Java中的线程池以及为什么要使用线程池?请解释Java中的内存模型以及如何避免内存泄漏?请解释Java中的并发工具包以及如何实现一个简单的线程安全队列?
Java面试题:请解释Java中的线程池以及为什么要使用线程池?请解释Java中的内存模型以及如何避免内存泄漏?请解释Java中的并发工具包以及如何实现一个简单的线程安全队列?
20 1
|
17天前
|
设计模式 缓存 安全
Java面试题:工厂模式与内存泄漏防范?线程安全与volatile关键字的适用性?并发集合与线程池管理问题
Java面试题:工厂模式与内存泄漏防范?线程安全与volatile关键字的适用性?并发集合与线程池管理问题
24 1
|
12天前
|
负载均衡 关系型数据库 MySQL
MySQL PXC集群多个节点同时大量并发update同一行
如本文标题,MySQL PXC集群多个节点同时大量并发update同一行数据,会怎样? 为此,本人做了一个测试,来验证到底会怎样!
17 0
|
17天前
|
设计模式 存储 缓存
Java面试题:结合设计模式与并发工具包实现高效缓存;多线程与内存管理优化实践;并发框架与设计模式在复杂系统中的应用
Java面试题:结合设计模式与并发工具包实现高效缓存;多线程与内存管理优化实践;并发框架与设计模式在复杂系统中的应用
22 0
|
17天前
|
设计模式 安全 NoSQL
Java面试题:设计一个线程安全的单例模式,并解释其内存占用和垃圾回收机制;使用生产者消费者模式实现一个并发安全的队列;设计一个支持高并发的分布式锁
Java面试题:设计一个线程安全的单例模式,并解释其内存占用和垃圾回收机制;使用生产者消费者模式实现一个并发安全的队列;设计一个支持高并发的分布式锁
25 0