转pt-query-digest使用实例--688IT编程网

转pt-query-digest使⽤实例

##samlple 0

pt-query-digest 官⽅⽂档

pt-query-digest - Analyze MySQL queries from logs, processlist, and tcpdump.

SYNOPSIS

Usage

pt-query-digest [OPTIONS] [FILES] [DSN]

pt-query-digest analyzes MySQL queries from slow, general, and binary log files. It can also analyze queries

from SHOW PROCESSLIST and MySQL protocol data from tcpdump. By default, queries are grouped by fingerprint

and reported in descending order of query time (i.e. the slowest queries first). If no FILES are given, the t

ool reads

STDIN. The optional DSN is used for certain options like --since and --until.

Report the slowest queries from slow.log:

->pt-query-digest slow.log

Report the slowest queries from the processlist on host1:

pt-query-digest --processlist h=host1

->Capture MySQL protocol data with tcppdump, then report the slowest queries:

tcpdump -s 65535 -x -nn -q -tttt -i any -c 1000 port 3306 >

pt-query-digest --type p.txt

->Save query data from slow.log to host2 for later review and trend analysis:

pt-query-digest --review h=host2 --no-report slow.log

注意：

pt-query-digest 在采集本地慢查询⽇志到远端管理数据库时候，有的时候出现消耗⼀个cpu 100%资源的情况

可能原因是跟这个虚拟机本地磁盘I/O 瓶颈有关，需要读本地slow.log

规避⽅法

run it with nice -n 19 and then its priority will be so low that everything else gets priority.

nice -n 19 使⽤见下⽂

blog.chinaunix/uid-9950859-id-98406.html

## sample 1

wwwblogs/moss_tan_jun/p/8025517.html

感谢moss_tan_jun

-》如何通过慢查询⽇志出有问题的SQL

查询次数多且每次查询时间较长的sql

通常为pt-query-digest分析的前个查询

IO⼤的SQL（数据库的瓶颈之⼀是IO）

注意pt-query-digest分析结果中 Rows examine项

未命中索引的SQL

注意pt-query-digest分析结果中 Rows examine很⼤但是Rows Sent很⼩

-》通过explain分析SQL

->索引优化

如何选择合适的列建⽴索引

###sample 2

aws.amazon/cn/blogs/china/pt-query-digest-rds-mysql-slow-searchnew/

感谢闫静

实际案例

这⾥描述⼀个实际的案例，在 RDS MySQL 碰到性能问题时，我们如何通过 pt-query-digest ⼯具来分析性能，到其中的问题所在。发现问题

某⼀天突然发现 RDS MySQL CPU 利⽤率⾼达100%，平时正常运⾏⼏乎都在40%以下，怀疑 MySQL 数据库之前运⾏了⼀些问题 SQL 语句导致了 CPU 资源的飙升。

分析问题

这⾥我们⾸先来获取13:00-14:00这⼀个⼩时范围内的 RDS MySQL slow log ，然后再使⽤我们前⾯部署的 pt-query-digest ⼯具来分析⼀下，看是否可以发现⼀些端倪。

[root@ip-172-31-36-44 ~]# mysql -h mysql. xxxxxxxxxxxx.rds-northwest-1.amazonaws -u root -p -P13306 -D mysql -s -r -e "SELECT CONCAT( '# Time: ', DATE_FORMAT(start_time, '%y%m%d %H%i%s'), '\n', '# User@Host: ', user_host, '\n', '# Query_time: ', TIME_TO_SEC(query_time), ' Lock_time: ', TIME_TO_SEC(lock_time), ' Rows_sent: ', rows_sent, ' Rows_examined: ', rows_examined, '\n', sql_text, ';' ) FROM mysql.slow_log where DATE_FORMAT(st

art_time, '%Y%m%d %H:%i:%s') between '20190328 13:00:00' and

'20190328 14:00:00' " > /tmp/slow.log.1314.log

Enter password:

[root@ip-172-31-36-44 ~]#

[root@ip-172-31-36-44 ~]# pt-query-digest --report /tmp/slow.log.1314.log> /tmp/report.1314.log

[root@ip-172-31-36-44 ~]#

[root@ip-172-31-36-44 ~]# cat /tmp/report.1314.log

# 220ms user time, 30ms system time, 27.48M rss, 221.73M vsz

# Current date: Thu Mar 28 06:03:53 2019

# Hostname: ip-172-31-36-44-northwest-1pute.internal

# Files: /tmp/slow.log.1314.log

# Overall: 255 total, 4 unique, 0 QPS, 0x concurrency ____________________

# Attribute total min max avg 95% stddev median

# ============ ======= ======= ======= ======= ======= ======= =======

# Exec time 9360s 5s 62s 37s 49s 8s 35s

# Lock time 0 0 0 0 0 0 0

# Rows sent 3.12k 0 266 12.52 0 54.70 0

# Rows examine 1.85G 1.88M 12.99M 7.45M 9.30M 1.35M 6.94M

# Query size 2.42M 78 114.10k 9.72k 79.83k 28.60k 212.52

# Time 46.29M 185.87k 185.87k 185.87k 185.87k 0 185.87k

# Profile

# Rank Query ID Response time Calls R/Call V/M

# ==== ============================== =============== ===== ======= =====

# 7913.0000 84.5% 216 36.6343 1.57 SELECT MLModel?_ecgw_a_pred

# 971.0000 10.4% 25 38.8400 2.04 INSERT slph_adjust_his

# 466.0000 5.0% 12 38.8333 1.53 SELECT MLModel?_jd_pred unit_info MLModel?_jd_pred

# MISC 0xMISC 10.0000 0.1% 2 5.0000 0.0 <1 ITEMS>

# Query 1: 0 QPS, 0x concurrency, ID 0x582C46632FB388ABE5D178303E079908 at byte 420282

# This item is included in the report because it matches --limit.

# Scores: V/M = 1.57

# Attribute pct total min max avg 95% stddev median

# ============ === ======= ======= ======= ======= ======= ======= =======

# Count 84 216

# Exec time 84 7913s 20s 57s 37s 49s 8s 35s

# Lock time 0 0 0 0 0 0 0 0

# Rows sent 0 0 0 0 0 0 0 0

# Rows examine 79 1.48G 7.01M 7.02M 7.02M 6.94M 0 6.94M

# Query size 1 47.02k 222 223 222.89 212.52 0 212.52

# Time 84 39.21M 185.87k 185.87k 185.87k 185.87k 0 185.87k

# String:

# Hosts 172.31.39.23 (120/55%), 172.31.46.35 (36/16%)... 3 more

# Users root

# Query_time distribution

# 1us

# 10us

# 100us

# 1ms

# 10ms

# 100ms

# 1s

# 10s+ >>>>>>>>>>>>####

# Tables

# SHOW TABLE STATUS LIKE 'MLModel6_ecgw_a_pred'\G

# SHOW CREATE TABLE `MLModel6_ecgw_a_pred`\G

# EXPLAIN /*!50100 PARTITIONS*/

SELECT * FROM MLModel6_ecgw_a_pred

where unitname = 395 and forecast48hr >= now()

and forecast48hr < NOW() + INTERVAL 1 HOUR

order by predTime desc

limit 1\G

# Query 2: 0 QPS, 0x concurrency, ID 0x0E39F3F13EDA325B4E53D0244F2E9A23 at byte 210412 ..............

..............

从上⾯我们可以看到排在第⼀位的 SQL 语句在本次分析中总的时间占⽐⾼达84%，且单次调⽤耗时在36秒。接下来我们看看 SQL 语句的情况：

mysql> SELECT * FROM MLModel6_ecgw_a_pred

-> where unitname = 395 and forecast48hr >= now()

-> and forecast48hr < NOW() + INTERVAL 1 HOUR

-> order by predTime desc

-> limit 1

-> ;

Empty set (39.59 sec)

mysql> explain SELECT * FROM MLModel6_ecgw_a_pred

-> where unitname = 395 and forecast48hr >= now()

-> and forecast48hr < NOW() + INTERVAL 1 HOUR

-> order by predTime desc

-> limit 1;

+----+-------------+----------------------+------------+-------+---------------+---------+---------+------+------+----------+----------------------------------+

+----+-------------+----------------------+------------+-------+---------------+---------+---------+------+------+----------+----------------------------------+

+----+-------------+----------------------+------------+-------+---------------+---------+---------+------+------+----------+----------------------------------+

1 row in set, 1 warning (0.0

2 sec)

mysql> show index from MLModel6_ecgw_a_pred;

+----------------------+------------+----------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+

+----------------------+------------+----------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+

| MLModel6_ecgw_a_pred | 0 | PRIMARY | 1 | id | A | 6899295 | NULL | NULL | | BTREE | | | YES | NULL |

| MLModel6_ecgw_a_pred | 1 | idx_un | 1 | forecast48hr | A | 60106 | NULL | NULL | YES | BTREE | | | YES | NULL |

| MLModel6_ecgw_a_pred | 1 | idx_un | 2 | UNITNAME | A | 352164 | NULL | NULL | YES | BTREE | | | YES | NULL |

| MLModel6_ecgw_a_pred | 1 | idx_un1 | 1 | predTime | A | 112492 | NULL | NULL | YES | BTREE | | | YES | NULL |

| MLModel6_ecgw_a_pred | 1 | idx_un1 | 2 | UNITNAME | A | 162489 | NULL | NULL | YES | BTREE | | | YES | NULL |

+----------------------+------------+----------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+

5 rows in set (0.10 sec)

mysql>

从上⾯我们不难看出，此 SQL 语句使⽤了错误的索引 idx_un1 ，实际上使⽤ idx_un 索引选择性会更好，执⾏效率会更⾼。

解决问题

强制此 SQL 语句使⽤正确的索引，不到1秒就执⾏完毕：

mysql> SELECT * FROM MLModel6_ecgw_a_pred force index(idx_un)

-> where unitname = 395 and forecast48hr >= now()

-> and forecast48hr < NOW() + INTERVAL 1 HOUR

-> order by predTime desc

-> limit 1

-> ;

Empty set (0.03 sec)

mysql>

后续就是具体的优化⼯作，⾄于是优化索引设置，还是去调整SQL语句，可以根据实际情况来进⾏即可。

总结

pt-query-digest 是⼀个针对 MySQL slow log 进⾏分析的⼯具，可以获得更友好、易读、更⼈性化的 SQL 性能汇总及分析报告；

RDS MySQL 由于是托管的数据库，我们可以使⽤ awscli RDS API 或者以 MySQL sql 脚本来分别将 FILE 和 TABLE 形式的慢查询⽇志获取到本地，然后再使⽤ pt-query-digest 进⾏分析；

rows函数的使用方法及实例Percona Toolkit 是业界⽐较知名的 MySQL ⼯具集，⾥⾯包含多种可以提升效率的管理⼯具，除了 pt-query-digest 使⽤较多之外，还有 pt-online-schema-change 、 pt-mysql-summary 、 pt-summary 等⼯具被⼴泛使⽤，推荐有兴趣的同学可以尝试使⽤；

###samlple 3

blog.csdn/anzhen0429/article/details/77828927

感谢anzhen0429

案例背景：

线上某台mysql⽣产库服务器，CPU负载告警，使⽤率持续接近100%，丝毫没有回落的意思！

1. 性能表象的数据采集

登陆DB服务器：、mysql进程的CPU占⽤率765.9%(8核)，CPU基本上消耗殆尽!

2. 问题全⾯诊断：

结论：

内存，磁盘都不是问题，中断请求数还算可以接受，CPU出现性能瓶颈，有⼤量任务等待CPU时间⽚；

基本上可以断定是单纯的CPU问题，且是由于mysql进程引发；

根据CPU负载模型，可以断定出问题的地⽅：（⽤户态的CPU使⽤率是瓶颈）

1. mysql进⾏⼤量的内存操作，逻辑读；例如：缺失关键索引

2. ⼤量的CPU运算任务；例如：2表的笛卡尔积

3. MySQL层性能采集

此处可以考虑使⽤慢⽇志，由于磁盘不是瓶颈，不会带来太⼤的额外负载；

这⾥我采⽤tcpdump和pt-query-digest来抓问题SQL；

监控：

tcpdump -i eth0 -s 65535 -x -nn -q -tttt port 3306 -c 200000 > 1.dmp &

分析：

pt-query-digest --type tcpdump 1.dmp --limit 10 > report.log

基本上搞定TOP2SQL，问题就能得到缓解；

这2语句的执⾏时间基本是在1S的样⼦，且消耗了⼤量CPU时间：

OpenCV中InputArray和OutputArray使用方法

« 上一篇

go-sqlite3用法

688IT编程网

转pt-query-digest使用实例

发表评论

推荐文章

随机森林算法介绍及R语言实现

基于随机森林优化的神经网络算法在冬小麦产量预测中的应用研究_百度文 ...

基于正则化贪心森林算法的情感分析方法研究

随机森林算法和grandientboosting算法

基于随机森林的图像分类算法研究

热门文章

随机森林特征选择原理

自动驾驶系统中的随机森林算法解析

随机森林算法及其在生物信息学中的应用

监督学习中的随机森林算法解析(六)

随机森林算法在数据分析中的应用

机器学习——随机森林,RandomForestClassifier参数含义详解

随机森林的算法

随机森林算法作用

监督学习中的随机森林算法解析(十)

随机森林算法案例

随机森林案例

二分类问题常用的模型

绘制ssd框架训练流程

一种基于信息熵和DTW的多维时间序列相似性度量算法

SVM训练过程范文

如何使用支持向量机进行股票预测与交易分析

二分类交叉熵损失函数binary

tinybert_训练中文文本分类模型_概述说明

基于门控可形变卷积和分层Transformer的图像修复模型及其应用

人工智能开发技术的测试和评估方法

最新文章

基于随机森林的数据分类算法改进

人工智能中的智能识别与分类技术

基于人工智能技术的随机森林算法在医疗数据挖掘中的应用

随机森林回归模型的建模步骤

r语言随机森林预测模型校准曲线

《2024年随机森林算法优化研究》范文

标签列表

688IT编程网

转pt-query-digest使用实例

发表评论

推荐文章

随机森林算法介绍及R语言实现

基于随机森林优化的神经网络算法在冬小麦产量预测中的应用研究_百度文 ...

基于正则化贪心森林算法的情感分析方法研究

随机森林算法和grandientboosting算法

基于随机森林的图像分类算法研究

热门文章

随机森林特征选择原理

自动驾驶系统中的随机森林算法解析

随机森林算法及其在生物信息学中的应用

监督学习中的随机森林算法解析(六)

随机森林算法在数据分析中的应用

机器学习——随机森林,RandomForestClassifier参数含义详解

随机森林 的算法

随机森林算法作用

监督学习中的随机森林算法解析(十)

随机森林算法案例

随机森林案例

二分类问题常用的模型

绘制ssd框架训练流程

一种基于信息熵和DTW的多维时间序列相似性度量算法

SVM训练过程范文

如何使用支持向量机进行股票预测与交易分析

二分类交叉熵损失函数binary

tinybert_训练中文文本分类模型_概述说明

基于门控可形变卷积和分层Transformer的图像修复模型及其应用

人工智能开发技术的测试和评估方法

最新文章

基于随机森林的数据分类算法改进

人工智能中的智能识别与分类技术

基于人工智能技术的随机森林算法在医疗数据挖掘中的应用

随机森林回归模型的建模步骤

r语言随机森林预测模型校准曲线

《2024年随机森林算法优化研究》范文

标签列表

随机森林的算法