mysql请求阻塞问题解析
背景
我们提供了容器化的mysql给业务组使用， 容器化的意义在于技术栈统一，提供了标准的账号权限体系、配置文件优化、定时备份、主从切换、指标监控、异常告警。
这次的问题就出在配置文件优化上，以下是我们提供在2核4G环境下的一个模板，参考了一些mysql调优的案例和文章
[mysqld]
character_set_server = utf8mb4
datadir = /var/lib/mysql
expire_logs_days = 1
explicit_defaults_for_timestamp = 1
general_log = ON
general_log_file = /var/log/mysql/general_log_file.log
innodb_buffer_pool_size = 2G
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
innodb_flush_neighbors = 0
innodb_io_capacity = 1000
innodb_io_capacity_max = 2000
innodb_large_prefix = 1
innodb_lock_wait_timeout = 30
innodb_print_all_deadlocks = 1
innodb_thread_concurrency = 4
join_buffer_size = 20M
log-error = /var/log/mysql/error.log
log_queries_not_using_indexes = 0
log_slow_admin_statements = 1
log_slow_slave_statements = 1
log_timestamps = system
long_query_time = 10
max_connect_errors = 10
pid-file = /var/run/mysqld/mysqld.pid
read_rnd_buffer_size = 8388608
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow_query_log_file.log
socket = /var/run/mysqld/mysqld.sock
sort_buffer_size = 4194304
tmp_table_size = 67108864
wait_timeout = 600
binlog-ignore-db = mysql
enforce-gtid-consistency = ON
gtid-mode = ON
log-bin = mysql-bin
log-slave-updates = ON
innodb_log_file_size = 256M
lower_case_table_names = 1
max_connections = 512
server-id = 1
问题描述
原来的数据库在虚拟机上运行，8核16G，需要迁移到容器上来， 在迁移测试的过程中， 突然发现所有的表都打不开了，执行 show full processlist发现有四个视图语句在执行，询问得知数仓会在这个时间抽数，并发执行这几个视图语句，但是之前在虚拟机上跑是没问题的
排查
磁盘
刚开始以为是磁盘的问题，容器化的mysql，磁盘是挂载的pv、pvc，用的ceph的这一套分布式存储，通过ceph的性能测试和控制面板看起来是没有任何问题的，我们每天上亿的日志采集走的也是ceph，但是为了宁杀错不放过，将容器化的mysql磁盘挂载到了虚拟机上的固态硬盘， 还是没有解决这个问题
网络
磁盘没有问题，从网络入手，视图的查询，走的是k8s的nodeport，怀疑可能是网络传输过程中丢包导致的，于是将视图的查询搬到了容器内，走容器内部的service网络，结果还是没有解决
cpu、内存
磁盘和网络都没有问题，怀疑可能是docker的cpu和内存的资源加载的不及时？这是之前的配置
resources:
limits:
cpu: '4'
memory: 4000Mi
requests:
cpu: 100m
memory: 1000Mi于是将request和limit调整一致，均为4核4G，结果还是没有解决
mysql指标
连接数、锁表都很正常
mysql性能分析
好吧，从mysql自身入手， 通过开启show profiles，观察下一个简单的查询语句是阻塞到哪里了，结果是sending data
当执行一个查询时，MySQL会按照查询计划逐步执行不同的阶段。当MySQL完成了读取数据的阶段（例如扫描表、使用索引等），并且需要将结果发送给客户端时，就会出现"Sending data"阶段
好吧，到这无果了，对比一下和迁移前的差距，问题可能还是在配置文件上，于是去逐个阅读配置文件背后的原理，终于找到了一条可疑的配置
innodb_thread_concurrency=4
这个配置大概意思是限制了innodb并发的线程为4，当有四个线程正在并发执行查询或者事务的时候，其他的sql想要执行，就会放到一个等待队列，等待前面的线程释放资源后，才会获得一个执行线程去执行，等待队列按照FIFO的策略来执行， 这一点和java的线程池倒是设计的一样
之前为什么可以？
之前是使用的默认值，默认值为0
当innodb_thread_concurrency参数设置为0时，表示未启用并发度限制，InnoDB存储引擎会根据系统负载和资源情况自动评估并发度。
InnoDB会根据以下几个因素来评估并发度：
硬件资源：InnoDB会检测系统的硬件资源情况，包括CPU核心数、内存大小和磁盘I/O能力。根据可用的资源情况，它会决定是否创建新的执行线程。
系统负载：InnoDB会监视当前的系统负载，包括并发查询和事务数量。如果系统负载较低，InnoDB可能会创建更多的执行线程来并发执行查询和事务。反之，如果系统负载较高，InnoDB可能会推迟或拒绝创建新的执行线程，以避免资源争用和性能下降。
动态调整：InnoDB会根据实时的负载情况和资源利用率进行动态调整。它会监控执行线程的活动情况，并根据需要增加或减少执行线程的数量，以适应系统负载的变化。
通过这些评估和动态调整，InnoDB能够自动优化并发度，以最大程度地利用系统资源并提高性能。然而，由于每个系统的配置和负载模式都不同，最佳的并发度可能会因情况而异。因此，对于特定的系统，可能需要根据实际情况进行调整和优化。
为什么设置为4
对mysql了解不足， 这个值最早大家的建议都是设置为cpu的核数
应该怎么做？
依据percona.com的文档给出的合理值应该是活跃用户线程小于64的时候使用默认值， 大于64的时候设置为128，然后根据测试情况逐步下调或上涨
到此这篇关于mysql请求阻塞的文章就介绍到这了,更多相关mysql请求阻塞内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！
相关文章
有许多朋友经常需要修改mysql修改用户密码，今天提供图文并茂来解决此类问题，需要的朋友可以参考下2012-11-11
这篇文章主要介绍了mysql5.6.19下子查询为什么无法使用索引,需要的朋友可以参考下2014-08-08
数据库的数据量达到一定程度之后，为避免带来系统性能上的瓶颈。需要进行数据的处理，采用的手段是分区、分片、分库、分表，这里就为大家介绍一下,需要的朋友可以参考下2020-02-02
对于一些数据量较大的系统，数据库面临的问题除了查询效率低下，还有就是数据入库时间长。下面这篇文章主要给大家介绍了关于MySQL优化insert性能的相关资料，文中通过示例代码介绍的非常详细，需要的朋友可以参考下2018-06-06
这篇文章主要给大家介绍了关于mysql去除重复数据只保留一条数据的相关资料,在使用MySQL时,有时需要查询出某个字段不重复的记录,文中通过示例代码介绍的非常详细,需要的朋友可以参考下2023-08-08
这篇文章主要给大家介绍了关于MySQL中sum函数使用的相关资料，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧2021-03-03
这篇文章主要给大家介绍了关于mysql.help_topic的作用以及使用方法,mysql.help_topic表是MySQL数据库中的一个系统表,它存储了MySQL数据库中所有可用的帮助主题的信息,需要的朋友可以参考下2023-11-11
本篇文章我们将了解ORDER BY语句的优化，在文中给大家提到了mysql中的两种排序方式，需要的朋友参考下吧2018-08-08
开启MYSQL远程连接权限的方法，大家参考使用吧2013-12-12
这篇文章详细给大家介绍了MySQL-SQL存储函数以及触发器，文中有详细的代码示例，对我们学习MySQL有一定的帮助，感兴趣的朋友可以参考阅读下2023-06-06
最新评论