实例解析:MySQL性能瓶颈排查定位,实现毫秒级完成180秒的任务
摘要:从一个现场说起,全程解析如何定位性能瓶颈。
排查过程
收到线上某业务后端的MySQL实例负载比较高的告警信息,于是登入服务器检查确认。
1. 首先我们进行OS层面的检查确认
登入服务器后,我们的目的是首先要确认当前到底是哪些进程引起的负载高,以及这些进程卡在什么地方,瓶颈是什么。
通常来说,服务器上最容易成为瓶颈的是磁盘I/O子系统,因为它的读写速度通常是最慢的。即便是现在的PCIe SSD,其随机I/O读写速度也是不如内存来得快。当然了,引起磁盘I/O慢得原因也有多种,需要确认哪种引起的。
第一步,我们一般先看整体负载如何,负载高的话,肯定所有的进程跑起来都慢。
可以执行指令 w 或者 sar -q 1 来查看负载数据,例如(横版查看):
[yejr@imysql.com:~ ]# w11:52:58 up 702 days, 56 min, 1 user, load average: 7.20, 6.70, 6.47
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root pts/0 1.xx.xx.xx 11:51 0.00s 0.03s 0.00s w
或者 sar -q 的观察结果(横版查看):
[yejr@imysql.com:~ ]# sar -q 1
Linux 2.6.32-431.el6.x86_64 (yejr.imysql.com) 01/13/2016 _x86_64_ (24 CPU)
02:51:18 PM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 blocked
02:51:19 PM 4 2305 6.41 6.98 7.12 3
02:51:20 PM 2 2301 6.41 6.98 7.12 4
02:51:21 PM 0 2300 6.41 6.98 7.12 5
02:51:22 PM 6 2301 6.41 6.98 7.12 8
02:51:23 PM 2 2290 6.41 6.98 7.12 8
load average大意表示当前CPU中有多少任务在排队等待,等待越多说明负载越高,跑数据库的服务器上,一般load值超过5的话,已经算是比较高的了。
引起load高的原因也可能有多种:
某些进程/服务消耗更多CPU资源(服务响应更多请求或存在某些应用瓶颈);
发生比较严重的swap(可用物理内存不足);
发生比较严重的中断(因为SSD或网络的原因发生中断);
磁盘I/O比较慢(会导致CPU一直等待磁盘I/O请求);
这时我们可以执行下面的命令来判断到底瓶颈在哪个子系统(横版查看):
[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
Mem: 49374024k total, 32018844k used, 17355180k free, 115416k buffers
Swap: 16777208k total, 117612k used, 16659596k free, 5689020k cachedPID 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
很明显是前面两个mysqld进程导致整体负载较高。
而且,从 Cpu(s) 这行的统计结果也能看的出来,%us 和 %wa 的值较高,表示当前比较大的瓶颈可能是在用户进程消耗的CPU以及磁盘I/O等待上。
我们先分析下磁盘I/O的情况。
执行 sar -d 确认磁盘I/O是否真的较大(横版查看):
[yejr@imysql.com:~ ]# sar -d 1Linux 2.6.32-431.el6.x86_64 (yejr.imysql.com) 01/13/2016 _x86_64_ (24 CPU)11:54:32 AM dev8-0 5338.00 162784.00 1394.00 30.76 5.24 0.98 0.19 100.0011:54:33 AM dev8-0 5134.00 148032.00 32365.00 35.14 6.93 1.34 0.19 100.1011:54:34 AM dev8-0 5233.00 161376.00 996.00 31.03 9.77 1.88 0.19 100.0011:54:35 AM dev8-0 4566.00 139232.00 1166.00 30.75 5.37 1.18 0.22 100.0011:54:36 AM dev8-0 4665.00 145920.00 630.00 31.41 5.94 1.27 0.21 100.0011:54:37 AM dev8-0 4994.00 156544.00 546.00 31.46 7.07 1.42 0.20 100.00
再利用 iotop 确认到底哪些进程消耗的磁盘I/O资源最多(横版查看):
[yejr@imysql.com:~ ]# iotopTotal DISK READ: 60.38 M/s | Total DISK WRITE: 640.34 K/sTID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND16397 be/4 mysql 8.92 M/s 0.00 B/s 0.00 % 94.77 % mysqld --basedir=/usr/local/m~og_3320/mysql.sock --port=33207295 be/4 mysql 10.98 M/s 0.00 B/s 0.00 % 93.59 % mysqld --basedir=/usr/local/m~og_3320/mysql.sock --port=332014295 be/4 mysql 10.50 M/s 0.00 B/s 0.00 % 93.57 % mysqld --basedir=/usr/local/m~og_3320/mysql.sock --port=332014288 be/4 mysql 14.30 M/s 0.00 B/s 0.00 % 91.86 % mysqld --basedir=/usr/local/m~og_3320/mysql.sock --port=332014292 be/4 mysql 14.37 M/s 0.00 B/s 0.00 % 91.23 % mysqld --basedir=/usr/local/m~og_3320/mysql.sock --port=3320
可以看到,端口号是3320的实例消耗的磁盘I/O资源比较多,那就看看这个实例里都有什么查询在跑吧。
2. MySQL层面检查确认
首先看下当前都有哪些查询在运行(横版查看):
[yejr@imysql.com(db)]> mysqladmin pr|grep -v Sleep+----+----+----------+----+-------+-----+--------------+-----------------------------------------------------------------------------------------------+| Id |User| Host | db |Command|Time | State | Info |+----+----+----------+----+-------+-----+--------------+-----------------------------------------------------------------------------------------------+| 25 | x | 10.x:8519 | db | Query | 68 | Sending data | select max(Fvideoid) from (select Fvideoid from t where Fvideoid>404612 order by Fvideoid) t1 || 26 | x | 10.x:8520 | db | Query | 65 | Sending data | select max(Fvideoid) from (select Fvideoid from t where Fvideoid>484915 order by Fvideoid) t1 || 28 | x | 10.x:8522 | db | Query | 130 | Sending data | select max(Fvideoid) from (select Fvideoid from t where Fvideoid>404641 order by Fvideoid) t1 || 27 | x | 10.x:8521 | db | Query | 167 | Sending data | select max(Fvideoid) from (select Fvideoid from t where Fvideoid>324157 order by Fvideoid) t1 || 36 | x | 10.x:8727 | db | Query | 174 | Sending data | select max(Fvideoid) from (select Fvideoid from t where Fvideoid>324346 order by Fvideoid) t1 |+----+----+----------+----+-------+-----+--------------+-----------------------------------------------------------------------------------------------+
可以看到有不少慢查询还未完成,从slow query log中也能发现,这类SQL发生的频率很高。
这是一个非常低效的SQL写法,导致需要对整个主键进行扫描,但实际上只需要取得一个最大值而已,从slow query log中可看到:
Rows_sent: 1 Rows_examined: 5502460
每次都要扫描500多万行数据,却只为读取一个最大值,效率非常低。
经过分析,这个SQL稍做简单改造即可在个位数毫秒级内完成,原先则是需要150-180秒才能完成,提升了N次方。
改造的方法是:对查询结果做一次倒序排序,取得第一条记录即可。而原先的做法是对结果正序排序,取最后一条记录,汗啊。。。
写在最后,小结
在这个例子中,产生瓶颈的原因比较好定位,SQL优化也不难,实际线上环境中,通常有以下几种常见的原因导致负载较高:
一次请求读写的数据量太大,导致磁盘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,可以在线直接调整,也可获得大幅提升。
出处:https://www.modb.pro/db/21627
点击下图查看更多 ↓
云和恩墨大讲堂 | 一个分享交流的地方
长按,识别二维码,加入万人交流社群
请备注:云和恩墨大讲堂
点个“在看”
你的喜欢会被看到????
实例解析:MySQL性能瓶颈排查定位,实现毫秒级完成180秒的任务相关推荐
- 实例解析MySQL性能瓶颈排查定位
优化系列 | 实例解析MySQL性能瓶颈排查定位 原文地址: http://imysql.com/2016/01/13/mysql-optimization-case-howto-find-perfo ...
- mysql单表瓶颈_mysql单表性能瓶颈_优化系列 | 实例解析MySQL性能瓶颈排查定位-云栖社区-阿里云...
导读 从一个现场说起,全程解析如何定位性能瓶颈. 排查过程 收到线上某业务后端的MySQL实例负载比较高的告警信息,于是登入服务器检查确认. 1. 首先我们进行OS层面的检查确认 登入服务器后,我们的 ...
- Mysql disk write 高_优化系列|实例解析MySQL性能瓶颈排查定位
导读
排查过程
导读 从一个现场说起,全程解析如何定位性能瓶颈. 排查过程 收到线上某业务后端的MySQL实例负载比较高的告警信息,于是登入服务器检查确认. 1. 首先我们进行OS层面的检查确认 登入服务器后,我们的 ...
- Mysql性能瓶颈深度定位分析
我们在性能测试过程中,经常会遇到Mysql出现性能瓶颈的情况,对于数据库来说,所谓的性能瓶颈无非是慢SQL.CPU高.IO高.内存高,其中前三个举实际例子来进行性能分析,最后内存高只是方法性说明(实际 ...
- mysql 瓶颈诊断_MySQL 监控、性能瓶颈排查
监控的作用 业务/数据库服务是否可用 是否可以对外提供服务 进程在允许,但没监听网络,或者授权不正确,或者网络出故障 因此不能只监控进程启动与否,是否监听网络 最好能模拟业务逻辑进行监控 这个业务逻辑 ...
- mysql如何定位耗时较长的sql_Mysql实例mysql优化之定位效率较低的SQL
<Mysql实例mysql优化之定位效率较低的SQL>要点: 本文介绍了Mysql实例mysql优化之定位效率较低的SQL,希望对您有用.如果有疑问,可以联系我们. 导读:一般通过以下两种 ...
- mysql 改表面_MySQL_解析MySQL数据库性能优化的六大技巧,数据库表表面上存在索引和防 - phpStudy...
解析MySQL数据库性能优化的六大技巧 数据库表表面上存在索引和防错机制,然而一个简单的查询就会耗费很长时间.Web应用程序或许在开发环境中运行良好,但在产品环境中表现同样糟糕.如果你是个数据库管理员 ...
- mysql迁移导致数据库效率低_MySQL数据库慢–排查问题总结(整理自《抽丝剥茧之MySQL疑难杂症排查》叶金荣)...
1.常见瓶颈 (1)SQL效率低 (2)选项配置不当 (3)访问题飙升 (4)硬件性能低 (5)其他进程抢资源 2.怎样确认是MySQL存在瓶颈 top/free/vmstat/sar/mpstat确 ...
- JAVA服务实例内存高问题排查及解决
生产服务内存高问题 问题描述# •1."计算中心" 服务堆内存分配4g,在生产环境运行一段时间后,实际占用内存4.8G,业务运行正常,未出现OOM.(本文以此服务进行排查) •2. ...
最新文章
- 利用栈的特性,将十进制数转换成八进制数
- 互联网各大公司职级和薪资一览
- Python全栈开发之路 【第六篇】:Python基础之常用模块
- Word 2010 制作文档结构之章节自动编号
- SAP CRM Fiori My task应用里roundtrip取舍的讨论
- mongodb mysql配置_Nosql_MongoDB数据库配置以及基本指令
- springboot mybatisplus 多数据源_【SpringBoot DB 系列】MybatisPlus 多数据源配置
- Git:撤销回滚操作
- ubuntu下git使用
- Python实战教程 | 轻松批量识别数百个快递单号
- Linux虚拟机怎么越狱,iOS 7完美越狱教程:5分钟轻松搞定
- 扩散方程——热传导问题(能量定律+傅里叶热传导定律)+ 拉普拉斯方程 | 偏微分方程(三)
- 当《流浪地球》冲过2亿:中国的科幻大片为什么来得这么晚?
- 互联网思维到底是什么?
- python 爬虫 403 Forbidden
- 0033__PDM,全称为 Persepolis Download Manager
- 2021年10月语音合成和语音识别论文月报
- 在线客服系统的功能有哪些是非常重要的?
- matlab 播放声音,用matlab录音和放音
- 【考研英语语法】复杂句的逻辑
热门文章
- 太强大了 | 一键生成,太强大了……
- Git笔记(17) 协议
- 黑龙江工程学院计算机系有几个门,黑龙江工程学院本科专业设置一览表
- android开启热点softap模式,[RK3288][Android6.0] Wifi开启热点(SoftAP)流程小结
- php执行跟踪_PHP 代码调试跟踪工具 Ytrace
- android 内存检测框架,Android项目内存泄漏检测
- 如何做好一位合格qc_如何管理好生产质量?
- python 递归遍历目录排序_python下递归遍历目录和文件
- vue页面锚文本_Vue如何实现锚点定位功能?
- ubuntu 设置 时区 更新时间