如何设计一个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 工具。

随着Web应用变得越来越复杂，单纯的MySQL + Memcached似乎已满足不了数据存储的需求，一些企业纷纷转向NoSQL方案，比如MongoDB、CouchDB、 TokyoCabinet/Tyrant、Cassandra等。在他们看来，如果数据访问模式不是很复杂，用不上SQL数据库。然而，DeNA公司截然相反，他们选择了 "only MySQL" 的方案，且获得了远远超越NoSQL的性能。

该公司仍在使用MySQL + Memcached，Memcached主要用于前端Cache，比如预处理的HTML、计数和摘要信息等，但数据行并不放在Cache里，而是直接从数据库查，因为普通的服务器就可以获得75万次每秒的查询，当前又有哪种NoSQL可以做到呢？

可以使用sysbench、super-smack、mysqlslap等工具测试MySQL性能，比如

[matsunobu@host ~]$ mysqlslap --query="select user_name,..

from test.user where user_id=1" \

--number-of-queries=10000000 --concurrency=30 --host=xxx -uroot

然后使用如下命令得到每秒读取的行数，

[matsunobu@host ~]$ mysqladmin extended-status -i 1 -r -uroot \

| grep -e "Com_select"

...

| Com_select | 107069 |

| Com_select | 108873 |

| Com_select | 108921 |

| Com_select | 109511 |

| Com_select | 108084 |

| Com_select | 108483 |

| Com_select | 108115 |

...

可以使用vmstat和Oprofile等工具诊断系统瓶颈。

MySQL Cluster因为性能问题一直受人批判，为改善这种情况引入了NDBAPI，使得性能提升了N倍。但对于非集群情况怎么优化呢？通过MySQL瓶颈分 析，发现大部分时间花费在SQL解析和表 *** 作上，如果绕过这层 *** 作直接存取存储引擎，可大大提升性能，MySQL的插件HandlerSocket正是由 此获得了每秒75万次查询 *** 作的性能，这个评测数据无疑会颠覆整个NoSQL世界。另外，HandlerSocket支持批量读取和写 *** 作，这进一步提升 了它的性能。

---