首先介绍下 pt-stalk,它是 Percona-Toolkit 工具包中的一个工具,说起 PT 工具包大家都不陌生,平时常用的 pt-query-digest、 pt-online-schema-change 等工具都是出自于这个工具包,这里就不多介绍了。
pt-stalk 的主要功能是在出现问题时收集 OS 及 MySQL 的诊断信息,这其中包括:
1. OS 层面的 CPU、IO、内存、磁盘、网络等信息;
2. MySQL 层面的行锁等待、会话连接、主从复制,状态参数等信息。
而且 pt-stalk 是一个 Shell脚本,对于我这种看不懂 perl 的人来说比较友好,脚本里面的监控逻辑与监控命令也可以拿来参考,用于构建自己的监控体系。
三、使用
接着我们来看下如何使用这个工具。
pt-stalk 通常以后台服务形式监控 MySQL 并等待触发条件,当触发条件时收集相关诊断数据。
触发条件相关的参数有以下几个:
function:
∘ 默认为 status,代表监控 SHOW GLOBAL STATUS 的输出;
∘ 也可以设置为 processlist,代表监控 show processlist 的输出;
variable:
∘ 默认为 Threads_running,代表 监控参数,根据上述监控输出指定具体的监控项;
threshold:
∘ 默认为 25,代表 监控阈值,监控参数超过阈值,则满足触发条件;
∘ 监控参数的值非数字时,需要配合 match 参数一起使用,如 processlist 的 state 列;
cycles:
∘ 默认为 5,表示连续观察到五次满足触发条件时,才触发收集;
连接参数:host、password、port、socket。
其他一些重要参数:
iterations:该参数指定 pt-stalk 在触发收集几次后退出,默认会一直运行。
run-time:触发收集后,该参数指定收集多长时间的数据,默认 30 秒。
sleep:该参数指定在触发收集后,sleep 多久后继续监控,默认 300 秒。
interval:指定状态参数的检查频率,判断是否需要触发收集,默认 1 秒。
dest:监控数据存放路径,默认为 /var/lib/pt-stalk。
retention-time :监控数据保留时长,默认 30 天。
daemonize:以后台服务运行,默认不开启。
log:后台运行日志,默认为 /var/log/pt-stalk.log。
collect:触发发生时收集诊断数据,默认开启。
∘ collect-gdb:收集 GDB 堆栈跟踪,需要 gdb 工具。
∘ collect-strace:收集跟踪数据,需要 strace 工具。
∘ collect-tcpdump:收集 tcpdump 数据,需要 tcpdump 工具。
本期我们用 MySQL 提供的 DBUG 工具来研究 MySQL 的 SQL 处理流程。
起手先造个实例
这里得稍微改一下实例的启动文件 start,将 CUSTOM_MYSQLD 改为 mysqld-debug:
重启一下实例,加上 debug 参数:
我们来做一两个实验,说明 DBUG 包的作用:
先设置一个简单的调试规则,我们设置了两个调试选项:
d:开启各个调试点的输出
O,/tmp/mysqld.trace:将调试结果输出到指定文件
请点击输入图片描述
然后我们创建了一张表,来看一下调试的输出结果:
请点击输入图片描述
可以看到 create table 的过程中,MySQL 的一些细节 *** 作,比如分配内存 alloc_root 等
这样看还不够直观,我们增加一些信息:
请点击输入图片描述
来看看效果:
请点击输入图片描述
可以看到输出变成了调用树的形式,现在就可以分辨出 alloc_root 分配的内存,是为了解析 SQL 时用的(mysql_parse)
我们再增加一些有用的信息:
请点击输入图片描述
可以看到结果中增加了文件名和行号:
请点击输入图片描述
现在我们可以在输出中找一下统计表相关的信息:
请点击输入图片描述
可以看到 MySQL 在这里非常机智,直接执行了一个内置的存储过程来更新统计表。
沿着 que_eval_sql,可以找到其他类似的统计表,比如下面这些:
请点击输入图片描述
请点击输入图片描述
本次实验中,我们借助了 MySQL 的 DBUG 包,来让 MySQL 将处理过程暴露出来。MySQL 中类似的技术还有不少,比如 performance_schema,OPTIMIZER_TRACE 等等。
这些技术将 MySQL 的不同方向的信息暴露出来,方便大家理解其中机制。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)