如何监控MySQL性能

一，获取mysql用户下的进程总数

成都创新互联公司长期为成百上千客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为海林企业提供专业的成都做网站、成都网站设计、成都外贸网站建设，海林网站改版等技术服务。拥有十多年丰富建站经验和众多成功案例,为您定制开发。

ps -ef | awk '{print $1}' | grep "mysql" | grep -v "grep" | wc-1

二，主机性能状态

# uptime

[root@ ~]# uptime

13:05:52 up 53 days, 52 min, 1 user, load average: 0.00, 0.00, 0.00

三，CPU使用率

# top

或

# vmstat

四，磁盘IO量

# vmstat 或 # iostat

五，swap进出量[内存]

# free

六，数据库性能状态

(1)QPS(每秒Query量)

QPS = Questions(or Queries) / seconds

mysql show /*50000 global */ status like 'Question';

(2)TPS(每秒事务量)

TPS = (Com_commit + Com_rollback) / seconds

mysql show status like 'Com_commit';

mysql show status like 'Com_rollback';

(3)key Buffer 命中率

key_buffer_read_hits = (1-key_reads / key_read_requests) * 100%

key_buffer_write_hits = (1-key_writes / key_write_requests) * 100%

mysql show status like 'Key%';

(4)InnoDB Buffer命中率

innodb_buffer_read_hits = (1 - innodb_buffer_pool_reads / innodb_buffer_pool_read_requests) * 100%

mysql show status like 'innodb_buffer_pool_read%';

(5)Query Cache命中率

Query_cache_hits = (Qcahce_hits / (Qcache_hits + Qcache_inserts )) * 100%;

mysql show status like 'Qcache%';

(6)Table Cache状态量

mysql show status like 'open%';

(7)Thread Cache 命中率

Thread_cache_hits = (1 - Threads_created / connections ) * 100%

mysql show status like 'Thread%';

mysql show status like 'Connections';

(8)锁定状态

mysql show status like '%lock%';

(9)复制延时量

mysql show slave status

(10) Tmp Table 状况(临时表状况)

mysql show status like 'Create_tmp%';

(11) Binlog Cache 使用状况

mysql show status like 'Binlog_cache%';

(12) Innodb_log_waits 量

mysql show status like 'innodb_log_waits';

当然你也可以使用一下开源监控软件进行监控

一，RRDTool

二，Nagios

三，MRTG

四，Cacti

如何监控MySQL

首先介绍下 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主从同步情况

用 pt-table-checksum 时，会不会影响业务性能？

实验

实验开始前，给大家分享一个小经验：任何性能评估，不要相信别人的评测结果，要在自己的环境上测试，并（大概）知晓原理。

我们先建一对主从：

然后用 mysqlslap跑一个持续的压力：

开另外一个会话，将 master 上的 general log 打开：

然后通过 pt-table-checksum 进行一次比较：

查看 master 的 general log，由于 mysqlslap 的影响，general log 中有很多内容，我们找到与 pt-table-checksum 相关的线程：

将该线程的操作单独列出来：

操作比较多，我们一点一点来说明：

这里工具调小了 innodb 锁等待时间。使得之后的操作，只要在 innodb 上稍微有锁等待，就会马上放弃操作，对业务影响很小。

另外工具调小了 wait_timeout 时间，倒是没有特别的作用。

工具将隔离级别调整为了 RR 级别，事务的维护代价会比 RC 要高，不过后面我们会看到工具使用的每个事务都很小，加上之前提到 innodb 锁等待时间调到很小，对线上业务产生的成本比较小。

RR 级别是数据对比的基本要求。

工具通过一系列操作，了解表的概况。工具是一个数据块一个数据块进行校验，这里获取了第一个数据块的下边界。

接下来工具获取了下一个数据块的下边界，每个 SQL前都会 EXPLAIN 一下，看一下执行成本，非常小心翼翼。

之后工具获取了一个数据块的 checksum，这个数据块不大，如果跟业务流量有冲突，会马上出发 innodb 的锁超时，立刻退让。

以上是 pt-table-checksum 的一些设计，可以看到这几处都是精心维护了业务流量不受影响。

工具还设计了其他的一些机制保障业务流量，比如参数 --max-load 和 --pause-file 等，还有精心设计的数据块划分方法，索引选择方法等。大家根据自己的情况配合使用即可达到很好的效果。

总结

本期我们介绍了简单分析 pt-table-checksum 是否会影响业务流量，坊间会流传工具的各种参数建议或者不建议使用，算命的情况比较多，大家都可以用简单的实验来分析其中机制。

还是那个观点，性能测试不能相信道听途说，得通过实验去分析。

如何监控mysql表的变化

本期我们用 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 的不同方向的信息暴露出来，方便大家理解其中机制。

网站栏目：怎么监控mysql 怎么监控电脑上网记录
当前地址：http://lswzjz.com/article/ddsdsii.html