mysqlreport工具(一) (2012-02-23 15:58:41)
转载▼
标签: 杂谈分类: 技术分享
写在前面
看到微博上有人笑谈,如果你没有一个自己的技术博客,你不敢说你自己是搞过研发的!嗨,俺是一个俗人,想想这个还是随大流吧!
这篇文章主要是参考http://hackmysql.com/mysqlreport上的内容,是我去年遇到一个MySQL问题是苦于没有检测工具,从《高性能MySQL》中了解到的一个工具,比较不错。一直想把这篇文章翻译一下,没有恒心。赶上公司要交流,想到mysqlreport手册可以拿出来和大家分享一下,所以翻译一下,练习英语了!呵呵,还可以做个连载!欢迎各位高手指正!
正文
进行MySQL的配置优化,首先必须找出MySQL的性能瓶颈所在;而SHOW STATUS输出的报告正是用来计算性能瓶颈的参考数据。mysqlreport不像SHOW STATUS那样简单的罗列数据,而是对这些参考数据加以融合计算,整理成一个个优化参考点,然后就可以根据这个优化参考点的值以及该点的衡量标准,进行对应调整。
安装就不赘述了,很简单。估计redhat的话直接copy上就能执行。我是在公司内部版本的服务器上运行的,需要再安装perl-DBI和perl-DBD-MySQL。搞不定,问google吧。
运行输出报告(我喜欢这种方式):mysqlreport --user=root --password=root_password --port=3306 --outfile=/data/mysql_data/report/mysqlreport.txt
下面是报告说明(英文参考)http://hackmysql.com/mysqlreportguide
本手册用于解释mysqlreport输出的信息,本手册帮助理解报告中所有内荣,进而判断mysql服务器运行的如何?
目前的mysqlreport能够自动的生成一份完整的分析MySQL状态数据的报告。完整的报告包含14个部分112行。根据MySQL服务器的配置,一部分的区域并不会生成。例如,如果query caching选项被关闭,那么报告的第4部分Query Cache将不会生成。因此,报告的长度会有所不同。
为了跟好的帮助理解您所看见的报告,手册将完整的进行信息的说明,每部分都是逐行解释说明的。
Report Header: Line 1 报告的第一行,报头,包含三部分信息:MySQL服务器版本信息,MySQL服务器运行时间,服务器当前时间。
MySQL服务器版本信息表明MySQL服务器包含和不包含哪些特点。MySQL服务器运行时间表明报告价值的代表性。服务器运行时间对于评估报告是很重要的,因为如果服务器不运行几个小时的话,输出报告有可能存在曲解和误导性。有时甚至运行几个小时时间都是不够的,比如,MySQL服务器运行了午夜的6个小时几乎没有业务访问过。最理想的情况是,MySQL服务器运行一天之后再运行mysqlreport来输出报告,这样报告的代表价值要比系统刚运行时要好的多。
在这个例子中,MySQL服务器运行了34分钟,因此,此报告不具备代表性。
Key Report: Lines 3 - 7第一主要报告部分是Key report(索引报告),因为MySQL服务器的索引信息是最重要部分。尽管报告不能表明是否MySQL服务器索引是否良好,但是它能够指示shared key buffer(共享索引缓存)是否被充分利用。本部分仅能显示用于MyISAM表的共享索引缓存,其他的缓存并没有显示。
Buffer used: Line 4MySQL服务器的首要问题:索引缓存用了多少?如果它并没有被用很多,说明状况比较好,MySQL仅仅是在需要时分配了用于索引缓存的系统RAM。也就是说,如果索引缓存设置为512M,那么MySQL不是在系统开始时就分配的512M内存,MySQL仅仅会当需要时才会分配512M那么多!
第四行,Buffer used,显示的就是MySQL曾经一次分配的最大的数量。实际上,MySQL实际的使用量会少,也有可能多于这个数。MySQL称之为“高水位(high water mark)”。这一指标通常说明MySQL的配置指标中key_buffer_size是否足够大。如果报告的此行指示,MySQL已经占用了索引缓存的80%到90%,那么key_buffer_size的参数就应该增大。注意,这一行的指标是不可能超过95%的。考虑到mysqlreport无法计算一些内部数据结构对索引缓存的占用情况,所以,95%通常也就是表示为100%。
在本例子中,MySQL利用了512M缓存的380k空间,所以索引缓存是相当大的,但是下一行却表示了不一样的东西。
Current: Line 5这一行仅当MySQL服务器为version4.1.2和以后的版本才有效,因为Key_blocks_unused是在version4.1.2以后的版本中才增加的。这一行指示MySQL在生成报告时占用索引缓存的情况。如果前一行表示是一个高水位指示,那么这一行的占用量应该是小于或等于上一行的高水位。有时也会高于高水位指示,这是不是MySQL的Bug目前还不得而知。不管怎样,这一行和前一行的结果能够很好地指示key_buffer_size的参数设置的是不是足够大。
在本例子中,MySQL服务器状态就很好,占用了近60M,是索引缓存的12%,还没有接近完全的空间。
Write hit: Line 6
索引(keys)是使用固有RAM分区的。他们的效能表现在他们是缓存在能够快速接入的内存中,而不是接入速度较慢的内存中。但是,MySQL也不可避免的时常读取和写入硬盘。
这一行,Write hit,显示了索引写入的效率(这是个百分比比率值,分子是索引写入硬盘的量,分母是索引写入缓存的量)。索引写入命中率没有一个标准值。索引写入命中率依赖于MySQL服务器基本执行的是哪种语句。如果MySQL主要执行的是updates或者inserts,那么索引写入命中率可能接近0%是可接受的;如果MySQL主要执行的是selects,那么索引写入命中率可能90%或更多是可接受的。一个负数百分比表示MySQL写入索引到硬盘多于写入缓存,这样通常会很慢、不合理的、不可接受的。
最好描述索引写入命中率的方法,就是需要你知道MySQL服务器主要执行哪些语句,DMS报告(Lines 17-22)能够帮助解决这一问题。
Read hit: Line 7
比索引写入命中率更重要的是索引读取命中率(key read hit)。这一行描述了索引读取的效率(这是个百分比比率值,分子是索引读取硬盘的量,分母是索引读取缓存的量)。索引读取命中率应该低于99%。
过低的百分比表明这会是一个问题。一个低索引命中百分比通常可能是索引空间太小了。索引空间是为了避免MySQL装载过多的索引到内存中,当这种情况发生时,MySQL会恢复从硬盘读取索引,这就会使得硬盘相当慢而且会使索引无效。
通常来讲,开始运行MySQL的前1-2个小时,这一行的值会低于99%,经过1-2个小时以后,取值就会接近99%。
转载▼
标签: 杂谈分类: 技术分享
写在前面
看到微博上有人笑谈,如果你没有一个自己的技术博客,你不敢说你自己是搞过研发的!嗨,俺是一个俗人,想想这个还是随大流吧!
这篇文章主要是参考http://hackmysql.com/mysqlreport上的内容,是我去年遇到一个MySQL问题是苦于没有检测工具,从《高性能MySQL》中了解到的一个工具,比较不错。一直想把这篇文章翻译一下,没有恒心。赶上公司要交流,想到mysqlreport手册可以拿出来和大家分享一下,所以翻译一下,练习英语了!呵呵,还可以做个连载!欢迎各位高手指正!
正文
进行MySQL的配置优化,首先必须找出MySQL的性能瓶颈所在;而SHOW STATUS输出的报告正是用来计算性能瓶颈的参考数据。mysqlreport不像SHOW STATUS那样简单的罗列数据,而是对这些参考数据加以融合计算,整理成一个个优化参考点,然后就可以根据这个优化参考点的值以及该点的衡量标准,进行对应调整。
安装就不赘述了,很简单。估计redhat的话直接copy上就能执行。我是在公司内部版本的服务器上运行的,需要再安装perl-DBI和perl-DBD-MySQL。搞不定,问google吧。
运行输出报告(我喜欢这种方式):mysqlreport --user=root --password=root_password --port=3306 --outfile=/data/mysql_data/report/mysqlreport.txt
下面是报告说明(英文参考)http://hackmysql.com/mysqlreportguide
本手册用于解释mysqlreport输出的信息,本手册帮助理解报告中所有内荣,进而判断mysql服务器运行的如何?
目前的mysqlreport能够自动的生成一份完整的分析MySQL状态数据的报告。完整的报告包含14个部分112行。根据MySQL服务器的配置,一部分的区域并不会生成。例如,如果query caching选项被关闭,那么报告的第4部分Query Cache将不会生成。因此,报告的长度会有所不同。
为了跟好的帮助理解您所看见的报告,手册将完整的进行信息的说明,每部分都是逐行解释说明的。
Report Header: Line 1 报告的第一行,报头,包含三部分信息:MySQL服务器版本信息,MySQL服务器运行时间,服务器当前时间。
MySQL服务器版本信息表明MySQL服务器包含和不包含哪些特点。MySQL服务器运行时间表明报告价值的代表性。服务器运行时间对于评估报告是很重要的,因为如果服务器不运行几个小时的话,输出报告有可能存在曲解和误导性。有时甚至运行几个小时时间都是不够的,比如,MySQL服务器运行了午夜的6个小时几乎没有业务访问过。最理想的情况是,MySQL服务器运行一天之后再运行mysqlreport来输出报告,这样报告的代表价值要比系统刚运行时要好的多。
在这个例子中,MySQL服务器运行了34分钟,因此,此报告不具备代表性。
Key Report: Lines 3 - 7第一主要报告部分是Key report(索引报告),因为MySQL服务器的索引信息是最重要部分。尽管报告不能表明是否MySQL服务器索引是否良好,但是它能够指示shared key buffer(共享索引缓存)是否被充分利用。本部分仅能显示用于MyISAM表的共享索引缓存,其他的缓存并没有显示。
Buffer used: Line 4MySQL服务器的首要问题:索引缓存用了多少?如果它并没有被用很多,说明状况比较好,MySQL仅仅是在需要时分配了用于索引缓存的系统RAM。也就是说,如果索引缓存设置为512M,那么MySQL不是在系统开始时就分配的512M内存,MySQL仅仅会当需要时才会分配512M那么多!
第四行,Buffer used,显示的就是MySQL曾经一次分配的最大的数量。实际上,MySQL实际的使用量会少,也有可能多于这个数。MySQL称之为“高水位(high water mark)”。这一指标通常说明MySQL的配置指标中key_buffer_size是否足够大。如果报告的此行指示,MySQL已经占用了索引缓存的80%到90%,那么key_buffer_size的参数就应该增大。注意,这一行的指标是不可能超过95%的。考虑到mysqlreport无法计算一些内部数据结构对索引缓存的占用情况,所以,95%通常也就是表示为100%。
在本例子中,MySQL利用了512M缓存的380k空间,所以索引缓存是相当大的,但是下一行却表示了不一样的东西。
Current: Line 5这一行仅当MySQL服务器为version4.1.2和以后的版本才有效,因为Key_blocks_unused是在version4.1.2以后的版本中才增加的。这一行指示MySQL在生成报告时占用索引缓存的情况。如果前一行表示是一个高水位指示,那么这一行的占用量应该是小于或等于上一行的高水位。有时也会高于高水位指示,这是不是MySQL的Bug目前还不得而知。不管怎样,这一行和前一行的结果能够很好地指示key_buffer_size的参数设置的是不是足够大。
在本例子中,MySQL服务器状态就很好,占用了近60M,是索引缓存的12%,还没有接近完全的空间。
Write hit: Line 6
索引(keys)是使用固有RAM分区的。他们的效能表现在他们是缓存在能够快速接入的内存中,而不是接入速度较慢的内存中。但是,MySQL也不可避免的时常读取和写入硬盘。
这一行,Write hit,显示了索引写入的效率(这是个百分比比率值,分子是索引写入硬盘的量,分母是索引写入缓存的量)。索引写入命中率没有一个标准值。索引写入命中率依赖于MySQL服务器基本执行的是哪种语句。如果MySQL主要执行的是updates或者inserts,那么索引写入命中率可能接近0%是可接受的;如果MySQL主要执行的是selects,那么索引写入命中率可能90%或更多是可接受的。一个负数百分比表示MySQL写入索引到硬盘多于写入缓存,这样通常会很慢、不合理的、不可接受的。
最好描述索引写入命中率的方法,就是需要你知道MySQL服务器主要执行哪些语句,DMS报告(Lines 17-22)能够帮助解决这一问题。
Read hit: Line 7
比索引写入命中率更重要的是索引读取命中率(key read hit)。这一行描述了索引读取的效率(这是个百分比比率值,分子是索引读取硬盘的量,分母是索引读取缓存的量)。索引读取命中率应该低于99%。
过低的百分比表明这会是一个问题。一个低索引命中百分比通常可能是索引空间太小了。索引空间是为了避免MySQL装载过多的索引到内存中,当这种情况发生时,MySQL会恢复从硬盘读取索引,这就会使得硬盘相当慢而且会使索引无效。
通常来讲,开始运行MySQL的前1-2个小时,这一行的值会低于99%,经过1-2个小时以后,取值就会接近99%。