search 2013 adfgs

最近很多朋友反馈之前开发的 myperf 工具自从增加了 snap 和 report 两个功能升级之后使用起来比以前复杂了,不仅参数选项增加了,还多了一个配置文件,而且还要创建数据库,不是很明白如何使用了。 为了让大家使用起来更方便容易,这里做一个简单的介绍。 文件组成 myperf myperf工具主程序,可执行python文件 myperf.cnf myperf工具的配置文件,用来存放各种配置项以减少命令行输入 myperf.sql myperf工具用来存放性能数据的Schema结构创建文件,如果需要使用snap和report功能,就必须要通过此文件创建好Schema用来存放性能数据。当然,如果一直只是使用top模式,那就不需要使用了 功能组成 top 类似于Linux/Unix 下最常用最基本的性能查看工具 top 类似,实时刷新展示数据库中的各项核心性能指标信息 snap 收集数据库当前各项性能状态数据并存储在数据库中,用于性能分析调优,类似于 Oracle 的 Statspack 的 snapshot功能,目前收集的信息主要是 global status,如果是 MySQL5.5,还会手机Performance Schema 中的部分信息 report 和上面的snap是相辅相成的,主要是对snap存储的性能数据进行分析,获得性能报告,类似于 Oracle 的 Statspack 的 report 功能。当然,由于数据来源有限,和 Oracle Statspack 相比,还有很大的差距 由于配置文件对于程序运行比较重要,所以这里对配置文件再单独介绍一下。myperf 配置文件模仿 MySQL 的配置文件,也将配置项进行了分组,目前的3个分组分别如下: main 用来配置与数据库连接无关的全局控制参数,如interval,mode,event,session等 source 用来配置被监控的源数据库的连接信息 target 用来配置存放监控数据的目标数据库连接信息,由于需要存储性能数据,所以这里的配置中还会有一个用来指定存放性能数据的database的参数项 最后,有个好消息宣布,那就是 […]

, , , ,

myperf 继 0.1-beta 版发布,可以实时在线显示 MySQL 性能数据并定期刷新之后,最近又增加了计划中的另外两个小功能: 定期收集MySQL数据库的性能数据并存储(snapshot) 由于初衷主要是考虑到多台 MySQL 服务器,所以数据会集中存储到一台集中的 MySQL Server中,并没有保存到自身。当然,以后有可能增加这样的功能。 根据性能数据的snapshot进行分析并生成report记录到文本文件 目前生成的报表还只能生成纯文本方式,不支持保存在数据库中。且只支持生成相邻两个snapshot的报表,暂不支持人工选择某两个snapshot之间的报表。 除了增加这2个功能外,还在原来的基础上增加了一个可选配置文件。主要是为了减少在命令行输入的内容,毕竟很多时候都在重复输入一些参数。当然,不喜欢配置文件方式的同学,选择不使用配置文件,直接将参数全部在命令行中输入。 由于现在 MySQL 5.5 增加了 Performance Schema,所以新版本中也增加了针对 Performance Schema 数据的收集,比如Event wait,File IO 等,只是目前针对这写数据的分析还比较弱,希望后续能加强一些。 源代码、配置文件以及存储snapshot数据所使用的Schema结构文件都放在 Google Code 上了,可以通过SVN工具匿名方式co出来,也欢迎猛击下载试用。 至此,之前设想的基本功能已经完成的差不多了,我的代码写的比较糙,有兴趣进一步完善的同学,欢迎 Gmail 给 sky000,一起维护完善这个小工具。

, , , ,

一直苦恼于 MySQL 没有像 Oracle Statspack 这样的性能分析工具,调优手段太少。很久以前自己学习 C 的时候,写了个简单的收集分析 MySQL 性能状态数据的小工具,之所以选择用 C 去写,一来是为了熟悉 MySQL 的 C API,熟悉 MySQL 代码,另一方面想捡回早就丢掉的 C 语言知识(后被证明很难实现,哈哈)。 随着 MySQL 5.5的出现,MySQL 新增了 Performance Schema,用于展示一些系统等待事件和性能信息。虽然仍然没有 DBA 最需要的 SQL 执行的信息,但至少比以前仅仅只有一些简单的 status 有了很大的进步。 所以最近又想完善一下这个被我自己称为 MySQL Performance Tool 的工具 “myperf” 。这次选择用较轻量级的脚本来实现,简单快速嘛(其实对我也是刚开始学习的,哈哈) 暂时计划包含以下3个功能: 显示实时性能状态 (top mode) 对性能状态做snapshot  (snap mode) 分析性能状态,输出报告 (report mode) 目前暂时先做了第一个功能点,连接到需要查看的数据库后以类似于linux 上 top 命令的方式实时刷新,包括active session 也会输出。 […]

, , , ,

From Ryam: p26 倒数第二行: 原文:“逻辑层与存储引擎实现层的过度解偶” -> :“逻辑层与存储引擎实现层的过度解耦” p82 第9行: 原文:“这样就省略了分页程序在分以前实时计算” -> :“这样就省略了分页程序在分页前实时计算” p118 第5行: 原文:“如果系统须要有限保证” -> :“如果系统须要优先保证” p123 第1行: 原文:“并不一定完全按照系数据库的元信息” -> :“并不一定完全按照数据库的元信息” p85 倒数第2行: 原文:“然后再瓶装展现对象” -> :“然后再拼装展现对象” p139 第8行: 原文:“那么将会存在大量记录指针信息存于同一Hash值相关联” -> :“那么将会存在大量记录的指针信息与同一Hash值相关联” p142 倒数第6行: 原文:“当然,并不是存在更新的字段就适合创建索引” -> :“当然,并不是存在更新的字段就不适合创建索引” p171 第3行: 原文:“但是当遇到一些自查询或较为复杂的join时” -> :“但是当遇到一些子查询或较为复杂的join时” 第11行: 原文:“group_message_bad是优化前的表,优化后为group_message表),如示例代码9-1所示:…” -> :这里的示例代码中group_message更换成group_message_bad p194 第3行 原文:“这样不仅可以让变化频繁的Table的Query浪费Query Cache的内存” -> :“这样不仅可以避免变化频繁的Table的Query浪费Query Cache的内存” p196 倒数第1行: […]

, , ,

《MySQL性能调优与架构设计》从最开始网上书店上架(2009.06.11)到现在才35天时间,库存量就已经很少了。接到出版社通知,需要今天完成勘误信息的整理,马上出片进行第二次印刷了。 这次印刷会订正掉目前位置已知的所有编写及出版过程中出现的错误信息,相信各方面品质都会比第一次印刷更好。 非常感谢各位读者热心积极的反馈以及肯定,感谢各位朋友的支持,感谢博文视点出版社的大力帮助,谢谢大家了。

, , ,