使用pt-stalk分析MySQL的性能波动 (转)

简介

在MySQL服务器出现短暂(5~30秒)的性能波动的时候,一般的性能监控工具都很难抓住故障现场,也就很难收集对应较细粒度的诊断信息。另外,如果这种波动出现的频率很低,例如几天才一次,我们也很难人为的抓住现场,收集数据。这正是pt-stalk所解决的问题。

参数

–function:设置触发条件,包括status、processlist、自定义脚本,详细见触发条件部分。

–dest:设置collect信息的存储目录,默认/var/lib/pt-stalk/。

另外设置–dest /u01/mysql选项到mysql目录之后,pt-stalk在清理超过期限的日志时,会暴力的将该目录下所有修改时间超过一定日期的文件全部删掉,

因此在设置dest目录时必须慎重(如果设置最好是一个独立的目录,而不是跟mysql或者其他设置在同一个目录)。–dest默认值是

查看pt-stalk的源码:

            # Delete collect files which more than --retention-time days old.
find "$dir" -warn -type f -mtime +$retention_time -exec rm -f ‘{}‘ \;

–iterations:该参数指定pt-stalk在收集几次故障现场后就退出。默认pt-stalk会一直运行。

–run-time:触发收集后,该参数指定收集多长时间的数据。默认是30秒,比如show processlist会连续收集30次。

–sleep:为防止一直触发收集数据,该参数指定在某次触发后,必须sleep一段时候才继续观察并触发收集。默认是300秒

–interval:默认情况pt-stalk会每隔一秒检查一次状态数据,判断是否需要触发收集。该参数指定间隔时间,默认是1秒。

–cycles:默认情况pt-stalk只有连续观察到五次状态值满足触发条件时,才触发收集。该参数控制,需要连续几次满足条件,收集被触发,默认是5次。

–verbose:设置log的输出级别,默认是2;第一次运行可以设置为3,方便观察情况。

LEVEL PRINTS

===== =====================================

0     Errors

1     Warnings

2     Matching triggers and collection info

3     Non-matching triggers

–plugin:和–function参数类似,可以指定一个包含before_collect、after_collect等函数的shell脚本。

pt-stalk的触发条件

三种触发条件,通过参数function设置:

  1. status

    –function status –variable Threads_connected –threshold
    2500,表示MySQL状态值Threads_connected超过2500时触发数据收集。常用的触发条件还可以使用Threads_running等。

  2. processlist
    –function processlist –variable State –match statistics –threshold 10,表示,show processlist中State列的值为statistics的线程数超过10则触发收集。
  3. 自定义脚本
    包含 trg_plugin函数的shell脚本, trg_plugin 函数必须返回一个int值,比如下面的脚本,因为slow log的status是一个累加值,不能分析差值,因此写小脚本来获取差值,对slow突然出现的尖刺进行分析。
function trg_plugin(){
current_slow=`mysql -uroot -pxxx -P5002
-S/opt/tmp/mysql5002.sock -e"show global status like ‘Slow_queries‘" -B
-N|awk ‘{print $2}‘`
current_timestamp=`date ‘+%s‘`
#when first execute,the last_timestamp is empty
if [ ! -e Slow_queries ];then
echo "$current_timestamp $current_slow">Slow_queries
echo "0"
exit 0
fi
last_timestamp=`cat Slow_queries|awk ‘{print $1}‘`
last_slow=`cat Slow_queries|awk ‘{print $2}‘`
echo "$current_timestamp $current_slow">Slow_queries
let diff_timestamp=$current_timestamp-$last_timestamp
let diff_slow=$current_slow-$last_slow
#echo "$diff_timestamp $diff_slow"
if [ $diff_timestamp -gt 11 ];then
echo "0"
else
echo $diff_slow
fi
}

实际例子

pt-stalk --daemonize
--function=slow_log_status.sh --variable=my_custemed_condition --cycles=1
--threshold=2 --interval=10 --socket=/opt/tmp/mysql5002.sock
--verbose=3

收集结果

可以看到收集的信息非常的全面,包括大量的系统状态(IO、CPU、网卡)等以及大量MySQL信息(processlist、innodb status、variables等)

时间: 2024-09-30 17:07:24

使用pt-stalk分析MySQL的性能波动 (转)的相关文章

MySQL优化 - 性能分析与查询优化

MySQL优化 - 性能分析与查询优化 优化应贯穿整个产品开发周期中,比如编写复杂SQL时查看执行计划,安装MySQL服务器时尽量合理配置(见过太多完全使用默认配置安装的情况),根据应用负载选择合理的硬件配置等. 1.性能分析 性能分析包含多方面:CPU.Memory.磁盘/网络IO.MySQL服务器本身等. 1.1 操作系统分析 常规的操作系统分析,在Linux中通常包含一些性能监控命令,如top.vmstat.iostat.strace.iptraf等. 1.内存:内存是大项,高查询消耗大量

【MySql】性能优化之分析命令

[MySql]性能优化之分析命令     一 当发现程序运行比较慢的时候,首先排除物力资源问题之后,就将注意力转向mysq数据库: 1.首先确定运行慢的sql语句: mysql> show full processlist; 2.确认低效的查询: 多次执行第一步发现time耗费大的sql语句.查看耗费的时间. 3.为sql生成一个执行计划query Execution plan(QEP) mysql> explain select * from tbal_name where ...; 4.查

MySQL 索引性能分析概要

上一篇文章 MySQL 索引设计概要 介绍了影响索引设计的几大因素,包括过滤因子.索引片的宽窄与大小以及匹配列和过滤列.在文章的后半部分介绍了 数据库索引设计与优化 一书中,理想的三星索引的设计流程和套路,到目前为止虽然我们掌握了单表索引的设计方法,但是却没有分析预估索引耗时的能力. 在本文中,我们将介绍书中提到的两种分析索引性能的方法:基本问题法(BQ)和快速估算上限法(QUBE),这两种方法能够帮助我们快速分析.估算索引的性能,及时发现问题. 基本问题法 当我们需要考虑对现有的 SELECT

MySQL优化 - 性能分析与查询优化(转)

出处:  MySQL优化 - 性能分析与查询优化 优化应贯穿整个产品开发周期中,比如编写复杂SQL时查看执行计划,安装MySQL服务器时尽量合理配置(见过太多完全使用默认配置安装的情况),根据应用负载选择合理的硬件配置等. 1.性能分析 性能分析包含多方面:CPU.Memory.磁盘/网络IO.MySQL服务器本身等. 1.1 操作系统分析 常规的操作系统分析,在Linux中通常包含一些性能监控命令,如top.vmstat.iostat.strace.iptraf等. 1.内存:内存是大项,高查

mysql数据库性能优化(包括SQL,表结构,索引,缓存)

优化目标减少 IO 次数IO永远是数据库最容易瓶颈的地方,这是由数据库的职责所决定的,大部分数据库操作中超过90%的时间都是 IO 操作所占用的,减少 IO 次数是 SQL 优化中需要第一优先考虑,当然,也是收效最明显的优化手段.降低 CPU 计算除了 IO 瓶颈之外,SQL优化中需要考虑的就是 CPU 运算量的优化了.order by, group by,distinct … 都是消耗 CPU 的大户(这些操作基本上都是 CPU 处理内存中的数据比较运算).当我们的 IO 优化做到一定阶段之后

Mysql数据库性能优化(一)

参考 http://www.jb51.net/article/82254.htm 今天,数据库的操作越来越成为整个应用的性能瓶颈了,这点对于Web应用尤其明显.关于数据库的性能,这并不只是DBA才需要担心的事,而这更是我们程序员需要去关注的事情.当我们去设计数据库表结构,对操作数据库时(尤其是查表时的SQL语句),我们都需要注意数据操作的性能.这里,我们不会讲过多的SQL语句的优化,而只是针对MySQL这一Web应用最多的数据库. mysql的性能优化无法一蹴而就,必须一步一步慢慢来,从各个方面

架构设计:系统存储(8)——MySQL数据库性能优化(4)

================================ (接上文<架构设计:系统存储(7)--MySQL数据库性能优化(3)>) 4-3.InnoDB中的锁 虽然锁机制是InnoDB引擎中为了保证事务性而自然存在的,在索引.表结构.配置参数一定的前提下,InnoDB引擎加锁过程是一样的,所以理论上来说也就不存在"锁机制能够提升性能"这样的说法.但如果技术人员不理解InnoDB中的锁机制或者混乱.错误的索引定义和同样混乱的SQL写操作语句共同作用,那么导致死锁出现的

架构设计:系统存储(9)——MySQL数据库性能优化(5)

=================================== (接上文<架构设计:系统存储(9)--MySQL数据库性能优化(5)>) 4-3-3-3.避免死锁的建议 上一篇文章我们主要介绍了MySQL数据库中锁的基本原理.工作过程和产生死锁的原因.通过上一篇文章的介绍,可以确定我们需要业务系统中尽可能避免死锁的出现.这里为各位读者介绍一些在InnoDB引擎使用过程中减少死锁的建议. 正确使用读操作语句 经过之前文章介绍,我们知道一般的快照读是不会给数据表任何锁的.那么这些快照读操作

mysql innodb 性能优化

默认情况下,innodb的参数设置的非常小,在生产环境中远远不够用比如最重要的两个参数innodb_buffer_pool_size 默认是8Minnodb_flush_logs_at_trx_commit 默认设置的是1 也就是同步刷新log(可以这么理解) innodb_buffer_pool_size: 这是InnoDB最重要的设置,对InnoDB性能有决定性的影响.默认的设置只有8M,所以默认的数据库设置下面InnoDB性能很差.在只有 InnoDB存储引擎的数据库服务器上面,可以设置6