高性能MySQL第2，3章性能相关回顾笔记-CSDN博客

1. 基准测试（benchmark）

不管是新手还是专家都要熟悉基准测试，benchmark测试是对系统的一种压力测试，目标是为了掌握在特定压力下系统的行为。也有其他原因：如重现系统状态，或者是为新硬件的可靠性测试。

1.1 为什么需要基准测试

benchmark测试可以观察系统在不同压力下的行为，评估系统的容量，掌握哪些是重要变化，创造一些虚构的场景来观察系统如何处理不同的数据。

验证基于系统的y 一些假设，确认这些假设是否符合实际情况。
重现系统中的某些异常行为，以解决这些异常。
测试系统当前的运行情况。如果不清楚系统当前的性能，就无法确认某些优化的效果如何。也可以利用历史的基准测试结果来分析诊断一些无法预测的问题。
模拟比当前系统更高的负载，以找出系统随着压力增加而可能遇到的扩展性瓶颈。
规划未来的业务增长。基准测试可以评估在项目未来的负载下，需要什么样的硬件，需要多大容量的网络，以及其他相关资源。这有助于降低系统升级和重大变更的风险。
测试应用适应可变环境的能力。例如，通过基准测试，可以发现系统在随机的并发峰值下的性能表现，或者是不同配置的服务器之间的性能表现。基准测试也可以测试系统对不同数据分布的处理能力。
测试不同的硬件、软件和操作系统配置。比如RAID y 5 还是RAID 10 更适合当前的系统？如果系统从ATA 硬盘升级到SAN 存储，对于随机写性能有什么帮助？ Linux2.4 系列的内核会比2.6 系列的可扩展性更好吗？升级MySQL 的版本能改善性能吗？为当前的数据采用不同的存储引擎会有什么效果？所有这类问题都可以通过专门的基准测试来获得答案。
证明新采购的设备是否配置正确。笔者曾经无数次地通过基准测试来对新系统进行压测，发现了很多错误的配置，以及硬件组件的失效等问题。因此在新系统正式上线到生产环境之前进行基准测试是一个好习惯，永远不要相信主机提供商或者硬件供应商的所谓系统已经安装好，并且能运行多快的说法。如果可能，执行实际的基准测试永远是一个好主意。

使用基准测试进行容量规划也需要掌握技巧，不能只根据测试结果做简单的推断。例如，假设想知道使用新的服务器后，系统能支撑多大的业务量增长。首先对原系统做基准测试，然后再对新系统做基准测试，如果发现新系统可以支持原系统40倍的TPS(每秒事务数)，这时候就不能简单推断说新系统一定可以支持40倍的业务增长，这是因为在业务增长的同时，系统流量、用户、数据以及不同数据之间的交互都在增长，他们不可能都有40倍的支撑能力，尤其是相互之间的关系。而且当业务增长到40倍时，应用本身的设计也可能已经随之改变。可能有新的功能特性会上线，其中某些功能特性可能会系统造成的压力远大于原有功能。而这些压力、数据、关系和特性的变化都很难模拟，所以他们对系统的影响也很难评估。

1.2基准测试的策略

两种主要策略：一是针对整个系统的整体测试（full stack test），二是单独测试某个部件（single component test）。做整体测试而非单部件测试的原因有：

测试这个应用系统，包括web服务器，应用代码，网络和数据库是非常有用的，因为用户关注度不仅仅是数据库本身的性能，而是整体性能。
某单个部件不一定是系统的瓶颈所在，通过整体测试可以揭露这一点。
只有整体测试，才能发现各部件之间的数据组织和缓存带来的影响。
整体测试更能揭示应该的真实表现，而单独的测试很难做到。

1.2.1 测试何种指标

测试目标决定了选择什么样的测试工具和技术，以获得精确而有意义的测试结果。可以将测试目标细化为一系列的问题。有时候要用不同的测试方法来测试不同的指标。比如延迟和吞吐量就要采用不同的方法。在实际测试中通常要考虑如下指标，并看看自己如何满足这些指标的测试需求：

吞吐量

吞吐量指的是单位时间内事务的处理数。这一直是经典的数据库应用测试指标，通常以TPS为单位。

响应时间或者延迟

这个指标用于测试任务所需的整体时间。单位通常有微妙，毫秒，秒，分钟。根据不同的时间单位可以计算出平均响应时间，最小响应时间，最大响应时间和所占百分比。最大响应时间通常意义不大，因为测试时间越长，最大响应时间也可能越大。而且其结果通常不可重复，每次测试都可能得到不同的最大响应时间。因此，通常可以使用百分比响应时间来代替最大响应时间。例如：如果95%的响应时间都是5毫秒，则表示任务在95%的时间段内都可以在5毫秒之内完成。

并发性

并发性是一个非常重要又经常被误解和误用的指标。它经常被表示成多少用户在同一时间浏览一个web站点，经常使用的指标是有多少个会话。然而，http是无状态的，大多数用户只是简单地读取浏览器上显示的信息，这并不等同于web服务器的并发性。而且，web服务器的并发性也不等同于数据库的并发性，而仅仅表示会话存储机制可以处理多少数据能力。web服务器的并发性更准确的度量指标应该是任意时间有多少同时发生的并发请求。换句话说，并发基准测试需要关注的是正在工作中的并发操作，或者是同时工作中的线程数目或者连接数目。当并发性增加时，需要测量吞吐量是否下降，相应时间是否变长，如果是这样，应用可能无法处理峰值压力。注意：并发性测试通常不是为了测试应用能达到的并发度，而是为了测试应用在不同并发下的性能。

可扩展性

在系统的业务压力可能发生重大变化时，测试可扩展性就非常必要。简单地说，可扩展性指的是，给系统增加一倍的工作，在理想情况下就能获得两倍的结果（即吞吐量增加一倍），或者说给系统增加一倍的资源，就可以获得两倍的吞吐量，同时性能也必须在可接受的范围内，大多数系统是无法做到这种理想的线性扩展，随着压力的变化，吞吐量和性能都可能越来越差。可扩展性指标对容量规范非常有用，他可以提供其他测试无法提供的信息，来帮助发现应用的瓶颈。比如，如果系统是基于单个用户的响应时间测试（这是一个很糟糕的测试策略）设计的，虽然测试的结果很好，但当并发度增加时，系统的性能有可能变得非常糟糕。而一个基于不断增加用户连接的情况下的响应时间测试则可以发现这个问题。

归根结底，应该测试那些对用户来说最重要的指标。因此应该尽可能地去收集一些需求，比如，什么样的响应时间是可以接受的，期待多少的并发性，等等。然后基于这些需求来设计基准测试，避免目光短浅地只关注部分指标，而忽略其他指标。

1.3基准测试方法

在了解基本概念之后，现在可以来具体讨论下如何设计和执行基准测试。先看看经典错误：

使用真实数据的子集而不是全集。例y 如应用需要处理几百GB 的数据，但测试只有1GB 数据；或者只使用当前数据进行测试，却希望模拟未来业务大幅度增长后的情况。
使用错误的数据分布。例如使用均匀分布的数据测试，而系统的真实数据有很多热点区域（随机生成的测试数据通常无法模拟真实的数据分布）。
使用不真实的分布参数，例如假定所有用户的个人信息（profile）都会被平均地读取注2。
在多用户场景中，只做单用户的测试。
在单服务器上测试分布式应用。
与真实用户行为不匹配。例如Web 页面中的“思考时间”。真实用户在请求到一个页面后会阅读一段时间，而不是不停顿地一个接一个点击相关链接。
反复执行同一个查询。真实的查询是不尽相同的，这可能会导致缓存命中率降低。而反复执行同一个查询在某种程度上，会全部或者部分缓存结果。
没有检查错误。如果测试的结果无法得到合理的解释，比如一个本应该很慢的查询突然变快了，就应该检查是否有错误产生。否则可能只是测试了MySQL 检测语法错误的速度了。基准测试完成后，一定要检查一下错误日志，这应当是基本的要求。
忽略了系统预热（warm up）的过程。例如系统重启后马上进行测试。有时候需要了解系统重启后需要多长时间才能达到正常的性能容量，要特别留意预热的时长。反过来说，如果要想分析正常的性能，需要注意，若基准测试在重启以后马上启动，则缓存是冷的、还没有数据，这时即使测试的压力相同，得到的结果也和缓存已经装满数据时是不同的。
使用默认的服务器配置。第3 章将详细地讨论服务器的优化配置。
测试时间太短。基准测试需要持续一定的时间。

后面会继续讨论这个话题。只有避免了上述错误，才能走上改变测试质量的漫漫长路。

1.3.1设计和规划基准测试

第一步是提出问题并明确目标。设计专用的基准测试是很复杂的，往往需要一个迭代的过程。首先需要获得生产数据集的快照，并且该快照很容易还原，以便进行后续的测试。然后，针对数据运行查询。更好的办法是选择一个有代表性的时间段，比如高峰期的一个小时，或者一整天，记录生产系统上的所有查询。即使不需要创建专用的基准测试，详细地写下测试规划也是必需的。应该建立将参数和结果文档化的规范，每一轮测试都必须进行详细记录。文档规范可以很简单，比如采用电子表格（spreadsheet）或者记事本形式，也可以是复杂的自定义的数据库。

1.3.2基准测试应该运行多长时间

有时候无法确认测试需要运行多长的时间才足够。如果是这样，可以让测试一直运行，持续观察直到确认系统已经稳定。下面是一个在已知系统上执行测试的例子，图2-1 显示了系统磁盘读和写吞吐量的时序图。

ph1

1.3.3获取系统性能和状态

在执行基准测试时，需要尽可能多地收集被测试系统的信息。最好为基准测试建立一个目录，并且每执行一轮测试都创建单独的子目录，将测试结果、配置文件、测试指标、脚本和其他相关说明都保存在其中。即使有些结果不是目前需要的，也应该先保存下来。多余一些数据总比缺乏重要的数据要好，而且多余的数据以后也许会用得着。需要记录的数据包括系统状态和性能指标，诸如CPU 使用率、磁盘I/O、网络流量统计、SHOWGLOBAL STATUS 计数器等。下面是一个收集MySQL 测试数据的shell 脚本：

ph2

还是推荐使用5 秒或者10 秒的间隔来收集数据。
每个文件名都包含了该轮测试开始的y 日期和小时。如果测试要持续好几天，那么这个文件可能会非常大，有必要的话需要手工将文件移到其他地方，但要分析全部结果的时候要注意从最早的文件开始。如果只需要分析某个时间点的数据，则可以根据文件名中的日期和小时迅速定位，这比在一个GB 以上的大文件中去搜索要快捷得多。
每次抓取数据都会先记录当前的时间戳，所以可以在文件中搜索某个时间点的数据。也可以写一些awk 或者sed 脚本来简化操作。
这个脚本不会处理或者过滤收集到的数据。先收集所有的原始数据，然后再基于此做分析和过滤是一个好习惯。如果在收集的时候对数据做了预处理，而后续分析发现一些异常的地方需要用到更多的原始数据，这时候就要“抓瞎”了。
如果需要在测试完成后脚本自动退出，只需要删除/home/benchmarks/running 文件即可。

这只是一段简单的代码，或许不能满足全部的需求，但却很好地演示了该如何捕获测试的性能和状态数据。从代码可以看出，只捕获了MySQL 的部分数据，如果需要，则很容易通过修改脚本添加新的数据捕获。例如，可以通过pt-diskstats 工具捕获/proc/diskstats 的数据为后续分析磁盘I/O 使用。

1.3.4获得准确的数据结果

获得准确测试结果的最好办法，是回答一些关于基准测试的基本问题：是否选择了正确的基准测试？是否为问题收集了相关的数据？是否采用了错误的测试标准？例如，是否对一个I/O 密集型（I/O-bound）的应用，采用了CPU 密集型（CPU-bound）的测试标准来评估性能？

接着，确认测试结果是否可重复。每次重新测试之前要确保系统的状态是一致的。如果是非常重要的测试，甚至有必要每次测试都重启系统。一般情况下，需要测试的是经过预热的系统，还需要确保预热的时间足够长（请参考前面关于基准测试需要运行多长时间的内容）、是否可重复。如果预热采用的是随机查询，那么测试结果可能就是不可重复的。

如果测试的过程会修改数据或者schema，那么每次测试前，需要利用快照还原数据。在表中插入1 000 条记录和插入100 万条记录，测试结果肯定不会相同。数据的碎片度和在磁盘上的分布，都可能导致测试是不可重复的。一个确保物理磁盘数据的分布尽可能一致的办法是，每次都进行快速格式化并进行磁盘分区复制。要注意很多因素，包括外部的压力、性能分析和监控系统、详细的日志记录、周期性作业，以及其他一些因素，都会影响到测试结果。

1.3.5运行基准测试并分析结果

自动化基准测试是个好主意。自动化的过程可以防止测试人员偶尔遗漏某些步骤，或者误操作。另外也有助于归档整个测试过程。自动化的方式有很多，要尽可能地使所有测试过程都自动化，包括装载数据、系统预热、执行测试、记录结果等。

一旦设置了正确的自动化操作，基准测试将成为一步式操作。如果只是针对某些应用做一次性的快速验证测试，可能就没必要做自动化。但只要未来可能会引用到测试结果，建议都尽量地自动化。否则到时候可能就搞不清楚是如何获得这个结果的，也不记得采用了什么参数，这样就很难再通过测试重现结果了。

基准测试通常需要运行多次。具体需要运行多少次要看对结果的记分方式，以及测试的重要程度。要提高测试的准确度，就需要多运行几次。一般在测试的实践中，可以取最好的结果值，或者所有结果的平均值，要把“数字”变成“知识”。

1.3.6绘图的重要性

如果你想要统治世界，就必须不断地利用“绘图”。最简单有效的图形，就是将性能指标按照时间顺序绘制。通过图形可以立刻发现一些问题，而这些问题在原始数据中却很难被注意到。或许你会坚持看测试工具打印出来的平均值或其他汇总过的信息，但平均值有时候是没有用的，它会掩盖掉一些真实情况。幸运的是，前面写的脚本的输出都可以定制为gnuplot或者R绘图的数据来源。假设使用gnuplot，假设输出的数据文件名是QPS-per-5-seconds: "gnuplot> plot "QPS-per-5-seconds" using 5 w lines title "QPS" "

ph3

下面我们讨论一个可以更加体现图形价值的例子。假设MySQL 数据正在遭受“疯狂刷新（furious flushing）”的问题，在刷新落后于检查点时会阻塞所有的活动，从而导致吞吐量严重下跌。95% 的响应时间和平均响应时间指标都无法发现这个问题，也就是说这两个指标掩盖了问题。但图形会显示出这个周期性的问题，请参考图2-3。

图2-3 显示的是每分钟新订单的交易量（NOTPM，new-order transactions per minute）。从曲线可以看到明显的周期性下降，但如果从平均值（点状虚线）来看波动很小。一开始的低谷是由于系统的缓存是空的，而后面其他的下跌则是由于系统刷新脏块到磁盘导致。如果没有图形，要发现这个趋势会比较困难。这种性能尖刺在压力大的系统比较常见，需要调查原因。

ph4

1.4基准测试工具

没有必要开发自己的基准测试系统，除非现有的工具确实无法满足需求。

1.4.1集成式测试工具

ab 是一个Apache HTTP 服务器基准测试工具。它可以测试HTTP 服务器每秒最多可以处理多少请求。如果测试的是Web 应用服务，这个结果可以转换成整个应用
每秒可以满足多少请求。这是个非常简单的工具，用途也有限，只能针对单个URL进行尽可能快的压力测试。关于ab 的更多信息可以参考http://httpd.apache.org/docs/2.0/programs/ab.html。
http_load 这个工具概念上和ab 类似，也被设计为对Web 服务器进行测试，但比ab 要更加灵活。可以通过一个输入文件提供多个URL，http_load 在这些URL 中随机选择进行测试。也可以定制http_load，使其按照时间比率进行测试，而不仅仅是测试最大请求处理能力。更多信息请参考http://www.acme.com/software/http-load/。
JMeter JMeter 是一个Java 应用程序，可以加载其他应用并测试其性能。它虽然是设计用来测试Web 应用的，但也可以用于测试其他诸如FTP 服务器，或者通过JDBC 进行数据库查询测试。
JMeter 比ab 和http_load 都要复杂得多。例如，它可以通过控制预热时间等参数，更加灵活地模拟真实用户的访问。JMeter 拥有绘图接口（带有内置的图形化处理的功能），还可以对测试进行记录，然后离线重演测试结果。更多信息请参考http://jakarta.apache.org/jmeter/。

2.剖析性能数据

在我们的技术咨询生涯中，最常碰到的三个性能相关的服务请求是：如何确认服务器是否达到了性能最佳的状态、找出某条语句为什么执行不够快，以及诊断被用户描述成“停顿”、“堆积”或者“卡死”的某些间歇性疑难故障。

这看起来是个艰巨的任务，但是事实证明，有一个简单的方法能够从噪声中发现苗头。这个方法就是专注于测量服务器的时间花费在哪里，使用的技术则是性能剖析（profiling）

首先我们要保持空杯精神，抛弃掉一些关于性能的常见的误解。

2.1 性能优化简介

问10 个人关于性能的问题，可能会得到10 个不同的回答，比如“每秒查询次数”、“CPU利用率”、“可扩展性”之类。这其实也没有问题，每个人在不同场景下对性能有不同的理解，但本章将给性能一个正式的定义。我们将性能定义为完成某件任务所需要的时间度量，换句话说，性能即响应时间，这是一个非常重要的原则。我们通过任务和时间而不是资源来测量性能。

还有另外一个问题：什么是优化？我们暂时不讨论这个问题，而是假设性能优化就是在一定的工作负载下尽可能地降低响应时间。很多人对此很迷茫。假如你认为性能优化是降低CPU 利用率，那么可以减少对资源的使用。但这是一个陷阱，资源是用来消耗并用来工作的，所以有时候消耗更多的资源能够加快查询速度。CPU 利用率只是一种现象，而不是很好的可度量的目标。

同样，如果把性能优化仅仅看成是提升每秒查询量，这其实只是吞吐量优化。吞吐量的提升可以看作是性能优化的副产品。对查询的优化可以让服务器每秒执行更多的查询，因为每条查询执行的时间更短了（吞吐量的定义是单位时间内的查询数量，这正好是我们对性能的定义的倒数）。

所以如果目标是降低响应时间，那么就需要理解为什么服务器执行查询需要这么多时间，然后去减少或者消除那些对获得查询结果来说不必要的工作。也就是说，先要搞清楚时间花在哪里。这就引申出优化的第二个原则：无法测量就无法有效地优化。所以第一步应该测量时间花在什么地方。

我们观察到，很多人在优化时，都将精力放在修改一些东西上，却很少去进行精确的测量。我们的做法完全相反，将花费非常多，甚至90% 的时间来测量响应时间花在哪里。如果通过测量没有找到答案，那要么是测量的方式错了，要么是测量得不够完整。如果测量了系统中完整而且正确的数据，性能问题一般都能暴露出来，对症下药的解决方案也就比较明了。测量是一项很有挑战性的工作，并且分析结果也同样有挑战性，测出时间花在哪里，和知道为什么花在那里，是两码事。

前面提到需要合适的测量范围，这是什么意思呢？合适的测量范围是说只测量需要优化的活动。有两种比较常见的情况会导致不合适的测量：

在错误的时间启动和停止测量。
测量的是聚合后的信息，而不是目标活动本身。

例如，一个常见的错误是先查看慢查询，然后又去排查整个服务器的情况来判断问题在哪里。如果确认有慢查询，那么就应该测量慢查询，而不是测量整个服务器。测量的应该是从慢查询的开始到结束的时间，而不是查询之前或查询之后的时间。

完成一项任务所需要的时间可以分成两部分：执行时间和等待时间。如果要优化任务的执行时间，最好的办法是通过测量定位不同的子任务花费的时间，然后优化去掉一些子任务、降低子任务的执行频率或者提升子任务的效率。而优化任务的等待时间则相对要复杂一些，因为等待有可能是由其他系统间接影响导致，任务之间也可能由于争用磁盘或者CPU 资源而相互影响。根据时间是花在执行还是等待上的不同，诊断也需要不同的工具和技术。

2.1.1通过性能剖析进行优化

一旦掌握并实践面向响应时间的优化方法，就会发现需要不断地对系统进行性能剖析（profiling）。性能剖析一般有两个步骤：测量任务所花费的时间；然后对结果进行统计和排序，将重要的任务排到前面。

但对于我们的目标来说更重要的是，可以将相似的任务分组并进行汇总。对相似的任务分组并进行汇总可以帮助对那些分到一组的任务做更复杂的统计分析，但至少需要知道每一组有多少任务，并计算出总的响应时间。通过性能剖析报告（profile report）可以获得需要的结果。性能剖析报告会列出所有任务列表。每行记录一个任务，包括任务名、任务的执行时间、任务的消耗时间、任务的平均执行时间，以及该任务执行时间占全部时间的百分比。性能剖析报告会按照任务的消耗时间进行降序排序。

转载于:https://www.cnblogs.com/Ironman-Jason/p/5439227.html