首页/应用软件/内容

【MySQL数据库】第3章解读:服务器性能剖析 (下)

应用软件2024-01-30 阅读()
[摘要]容我感慨一下:DBA真的不是盖的3.3.3使用性能剖析:有限3.4诊断简歇性问题如系统偶尔停顿、慢查询、唤影问题,尽量不要使用试错的方式解决问题:风险大3.4.1单条查询问题还是服务问题使用SHOW...
容我感慨一下:DBA真的不是盖的

3.3.3使用性能剖析:有限

3.4诊断简歇性问题

如系统偶尔停顿、慢查询、唤影问题,尽量不要使用试错的方式解决问题:风险大

3.4.1单条查询问题还是服务问题

使用SHOW GLOBAL STATUS

较高频率:1s/次执行该命令铺获数据,问题出现通过计数器的

使用SHOW PROCESSLIST 【参考】显示哪些线程正在运行

1.png

使用查询日志

开启慢查询,设置全局的long_query_time=0,确认all连接采用了新设置(可能需要重置all连接使生效)

注意吞吐量突然下降时间段的日志,查询是在完成阶段才写入到慢查询日志的

好的工具事半功倍:tcpdump、pt-query-digest、Percona Server

理解发现的问题

可视化数据:gnuplot /R(绘图工具)

gnuplot:

安装 一些命令: 常用技巧 入门教程 2 Gnuplot 数据可视化

建议:先使用前两种方法,开销低且通简单shell脚本或反复执行的查询交互式收集数据

3.4.2铺获诊断数据

现间歇性问题,尽量多收集数据(不只是问题出现时的)

弄清楚:1、有区分 何时出现了问题 的方法:触发器;2、收集诊断数据的工具

诊断触发器

误差:在没有发生问题期间收集了很多诊断数据,浪费时间(这个和前的、仔细读一下 不矛盾)

漏检:在问题出现时没有铺获到数据,错失了机会,开始收集前确认触发器能够真正地识别问题

好的触发器:

找到些能和正常时的阈值进行比较的指标

选择一个合适的阈值:足够高(正常时不会触发)、不能太高(问题发生时不错过)

推荐工具pt-stalk【参考】【2】触发器,设定到某个条件记录 配置需监控的变量 阈值 检查的频率

收集什么样的数据

执行时间:工作的时间和等待的时间

在需要的时间段内收集all能收集的数据

未知问题发生的原因:1、服务器需做大量工作、导致大量消耗CPU;2、在等待资源释放

不同的方法收集诊断数据,确认原因:

1、剖析报告:确认是否有太多工作,工具:tcpdump 监听TCP流量 模式开闭慢查询日志

2、等待分析:确认是否存在大量等待,GDB堆栈跟踪信息、show processlist ,show innodb status观察线程、事务状态

解释结果数据

目的:1、问题是否真的发生了;2、是否有明显的跳跃性变化

工具:

oprofile利用cpu硬件层面提供的性能计数器(performance counter),通过计数采样,帮助我们从进程、函数、代码层面找出占用cpu的"罪魁祸首"。实例【参考】

opreport命令,分别从进程和函数层面查看cpu使用情况的方法

 samples (北联网教程,专业提供视频软件下载)

第1页  第2页  第3页 

……

相关阅读