【Mysql】Mysql负载过大，app访问延迟

此处)折叠或打开

1. top命令
2. [yejr@imysql.com:~ ]# top top - 11:53:04 up 702 days, 56 min, 1 user, load average: 7.18, 6.70, 6.47 Tasks: 576 total, 1 running, 575 sleeping, 0 stopped, 0 zombie Cpu(s): 7.7%us, 3.4%sy, 0.0%ni, 77.6%id, 11.0%wa, 0.0%hi, 0.3%si, 0.0%st ----%us 和 %wa 的值较高，表示当前比较大的瓶颈可能是在用户进程消耗的CPU以及磁盘I/O等待上。
3. Mem: 49374024k total, 32018844k used, 17355180k free, 115416k buffers Swap: 16777208k total, 117612k used, 16659596k free, 5689020k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 14165 mysql 20 0 8822m 3.1g 4672 S 162.3 6.6 89839:59 mysqld 40610 mysql 20 0 25.6g 14g 8336 S 121.7 31.5 282809:08 mysqld 49023 mysql 20 0 16.9g 5.1g 4772 S 4.6 10.8 34940:09 mysqld
   

如果%us过高

1. 1：有大量的排序工作
   
2. 2：sql索引不合理
3. 查看慢日志，分析优化SQL

如果%sy过高

1. [root@HaoDai_App_DB01 ~]# iostat -x -m 2
   Linux 2.6.32-504.16.2.el6.x86_64 (HaoDai_App_DB01)      03/18/2016      _x86_64_        (40 CPU)
   
   
   avg-cpu:  %user   %nice %system %iowait  %steal   %idle
              4.29    0.00    0.20    0.05    0.00   95.46
   
   
   Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
   sda               0.00     2.97    0.04    0.48     0.00     0.01    72.81     0.00    0.49   0.28   0.01
   sdb               0.00   143.43    0.00  131.67     0.00     1.04    16.10     0.01    0.10   0.07   0.91
   
   
   avg-cpu:  %user   %nice %system %iowait  %steal   %idle
             12.54    0.00    0.38    0.03    0.00   87.06
   
   
   Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
   sda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
   sdb               0.00   174.00    0.00  137.50     0.00     1.17    17.40     0.03    0.19   0.14   1.95
   
   
2. 如果，吞吐量（rMB/s+wMB/s)过低，但是util过高表示：随机io特别的严重（可用pt-ioprofile去定位导致问题出现的表）
3. IOPS=R/s+W/s

再利用 iotop 确认到底哪些进程消耗的磁盘I/O资源最多：

一次请求读写的数据量太大，导致磁盘I/O读写值较大，例如一个SQL里要读取或更新几万行数据甚至更多，这种最好是想办法减少一次读写的数据量；

SQL查询中没有适当的索引可以用来完成条件过滤、排序（ORDER BY）、分组（GROUP BY）、数据聚合（MIN/MAX/COUNT/AVG等），添加索引或者进行SQL改写吧；

瞬间突发有大量请求，这种一般只要能扛过峰值就好，保险起见还是要适当提高服务器的配置，万一峰值抗不过去就可能发生雪崩效应；

因为某些定时任务引起的负载升高，比如做数据统计分析和备份，这种对CPU、内存、磁盘I/O消耗都很大，最好放在独立的slave服务器上执行；

服务器自身的节能策略发现负载较低时会让CPU降频，当发现负载升高时再自动升频，但通常不是那么及时，结果导致CPU性能不足，抗不过突发的请求；

使用raid卡的时候，通常配备BBU（cache模块的备用电池），早期一般采用锂电池技术，需要定期充放电（DELL服务器90天一次，IBM是30天），我们可以通过监控在下一次充放电的时间前在业务低谷时提前对其进行放电，不过新一代服务器大多采用电容式电池，也就不存在这个问题了。

文件系统采用ext4甚至ext3，而不是xfs，在高I/O压力时，很可能导致%util已经跑到100%了，但iops却无法再提升，换成xfs一般可获得大幅提升；

内核的io scheduler策略采用cfq而非deadline或noop，可以在线直接调整，也可获得大幅提升。

基本如果%us使用过高 或者 %us和%iowait都高，一般都是并发时的sql写的不好导致的

用这个思路来分析一下我们生产上157负载高的原因（19:00持续到19:05）

SELECT COUNT_STAR, SUM_TIMER_WAIT, AVG_TIMER_WAIT, EVENT_NAME FROM performance_schema.events_waits_summary_global_by_event_name where COUNT_STAR > 0 and EVENT_NAME like 'wait/synch/%' order by SUM_TIMER_WAIT desc limit 10; +------------+------------------+----------------+--------------------------------------------+ | COUNT_STAR | SUM_TIMER_WAIT | AVG_TIMER_WAIT | EVENT_NAME | +------------+------------------+----------------+--------------------------------------------+ | 36847781 | 1052968694795446 | 28575867 | wait/synch/mutex/innodb/lock_mutex | | 8096 | 81663413514785 | 10086883818 | wait/synch/cond/threadpool/timer_cond | | 19 | 3219754571347 | 169460766775 | wait/synch/cond/threadpool/worker_cond | | 12318491 | 1928008466219 | 156446 | wait/synch/mutex/innodb/trx_sys_mutex | | 36481800 | 1294486175099 | 35397 | wait/synch/mutex/innodb/trx_mutex | | 14792965 | 459532479943 | 31027 | wait/synch/mutex/innodb/os_mutex | | 2457971 | 62564589052 | 25346 | wait/synch/mutex/innodb/mutex_list_mutex | | 2457939 | 62188866940 | 24909 | wait/synch/mutex/innodb/rw_lock_list_mutex | | 201370 | 32882813144 | 163001 | wait/synch/rwlock/innodb/hash_table_locks | | 1555 | 15321632528 | 9853039 | wait/synch/mutex/innodb/dict_sys_mutex | +------------+------------------+----------------+--------------------------------------------+ 10 rows in set (0.01 sec)

从上面的表可以确认，lock_mutex（在MySQL源码里对应的是lock_sys->mutex）的锁等待累积时间最长（SUM_TIMER_WAIT）。lock_sys表示全局的InnoDB锁系统，在源码里看到InnoDB加/解某个记录锁的时候（这个case里是X锁），同时需要维护lock_sys，这时会请求lock_sys->mutex。

在这个case里，因为在Searching rows for update的阶段频繁地加/解X锁，就会频繁请求lock_sys->mutex，导致lock_sys->mutex锁总等待时间过长，同时在等待的时候消耗了大量CPU。

向AI问一下细节

推荐阅读：

1. MySQL 5.7 延迟复制
2. mysql主从延迟设置

免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。

mysql app 延迟

• 上一篇新闻：
  Eclipse插件使用links目录
• 下一篇新闻：
  server2003 sp1预览与演示

猜你喜欢

• Spark中的DAG是指什么
• c++中fabs函数的作用是什么
• oracle字符怎么转换成数字
• Spark中的资源管理器的功能及其优势
• 什么是Spark中的累加器
• 在Spark中，什么是数据分区
• Spark中的广播变量是用来做什么的
• Spark中的Executor是什么
• Spark中的DAG调度器是什么
• Spark中的Shuffle操作是什么

最新资讯

• hbase nosql怎样增强查询稳定性哟
• hbase nosql如何实施优化方法呀
• hbase nosql支持哪些数据查询优化方法呀
• hbase nosql怎样提高恢复成功率哟
• hbase nosql如何运用最佳实践呀
• hbase nosql有哪些数据恢复最佳实践呢
• hbase nosql怎样确保备份可用性哟
• hbase nosql如何制定备份策略呀
• hbase nosql支持哪些数据备份策略呀
• hbase nosql怎样避免迁移问题哟

相关推荐

• 网站访问慢-MySQL负载高（实战）
• MySQL - 主从同步延迟
• Mysql如何实现主从延迟监控
• MySQL中如何优化Slave延迟
• mysql占用资源过大如何解决
• MySQL同步延迟如何解决
• MySQL中CPU消耗过大如何解决
• 怎么用mysql减少主从延迟
• mysql的.ibd文件过大如何处理
• MySQL占用内存过大如何解决

相关标签

-mysql mysql- mysql workbench mysql-python mysql innodb mysql存储过程 mysql基本查询示例 mysql视频教程 mysql数据备份 mysql视图 python mysql mysql函数 mysql5.7.21 mysql 8.0.17 mysql 8 mysql-5.5 mysql-mmm mysqlshow mysql8.x mysql版本号