DB2性能优化（1）：从性能问题入手

实践中，应用系统运行一段时间后，用户通常会报告系统变慢，例如处理查询或者事务花费了过长的时间，或者系统在某些时段变慢。如果在数据库设计的过程中非常清晰的定义了性能需求，那么很容易确定应用或者系统是否有性能问题。相反，如果没有定义性能需求，那么就不容易为性能问题进行定量分析。

1  什么是性能问题

          性能问题比功能性问题难解决。根本原因在于根据症状不容易找到问题的根源。例如发现系统变慢或者有大量的锁超时现象发生，问题的根源是过时的统计信息导致优化器选择了错误的访问计划从而引发表扫描，这是很不容易定位的。另一方面，性能问题往往是断断续续发生的，不容易被捕捉。

          那么什么是性能呢？性能是一个系统在某一特定工作负载下所表现出的行为。一个工作负载由一系列来自应用的对系统的请求组成。通常认为一个系统的资源例如存储、CPU和内存等越多，资源被调度的越有效，能处理的工作负载就越大。换句话说，性能受两个关键因素的影响。其一是系统可用资源，其二是这些资源是如何被使用和共享的。

     性能的好坏可以从下面三个指标定量描述：

l  系统响应时间：数据库服务器收到应用请求后完成处理并返回给应用总共所消耗的时间，它反映了服务器的处理速度。

l  吞吐量：通常用每分钟处理的事务数（TPM）来计算，这个指标反映了系统的事务处理能力。

l  资源利用率：数据库服务器在处理事务或者查询的过程中，系统资源包括CPU、I/O以及磁盘的使用情况，这个指标反映了系统资源是否被服务器有效利用。

2  为系统做性能基准测试

       制定性能优化目标之前，首先需要对系统做基准测试（Benchmark Test, 即BMT）。基准测试通常会在特定条件下对选择好的工作负载进行测试，随后将结果和标准硬件最大阈值进行比较，例如每秒钟I/O吞吐量和执行的事务数。如果在同等配置条件下，当前工作负载的性能结果接近标准参数阈值，那说明当前已无需优化，否则说明还有较大的优化空间。另外一种情况是，在系统或应用没有改动前做基准测试，等改动后将再次测试的性能值和改动前进行对比，以确认性能变化情况。例如在开发阶段，应该使用基准测试来确定应用程序是否出现性能倒退。

      那么什么是基准测试呢？基准测试指通过设计科学的测试方法、测试工具和测试系统，实现对测试对象的某项性能指标进行定量的和可对比的测试。例如对DB2数据库的查询响应时间和事务处理能力等方面的性能指标进行基准测试。基准测试的三大原则是可测量、可重复和可对比。其中可测量是指测试的输入和输出之间是可达的，也就是测试过程是可以实现的，并且测试的结果可以量化表现；可重复是指按照测试过程实现的结果是相同的或处于可接受的置信区间之内，而不受测试的时间、地点和执行者的影响；可对比是指测试对象的测试结果具有一定关系，即测试结果的大小直接决定性能的高低。

基准测试能帮助你理解数据库在不同条件下的响应情况。这种条件可以是配置参数更改，也可以是一个应用的新版本发布，这个时候可以对因条件的变化而导致的性能变化做定量分析。基于每个用户或某个事务基准，你可以为整个程序或者某一个特定的工作负载例如死锁处理机制、DB2实用程序性能、不同的数据加载方式、读写速度等设计不同的测试场景。你可以按照常规方式启动所有应用，随后逐级限定在某个可能问题源头。这个时候，就可以为这个问题源头开发特定的测试用例。在这个特定的测试用例中，不需要模拟整个应用来获得有价值的信息，只需要从最简单的评估开始，随后根据需要逐渐增加复杂度。

基准测试通常是应用程序开发生命周期的一部分，应用开发人员和DBA通常都需要参与进来。从最佳实践来看，通常可以运行多个迭代来获得应用程序的最佳或次佳性能，而调整系统配置、SQL语句、索引、表空间和硬件配置等可以放在不同迭代之间进行。综上所述，一个好的基准测试具有下面的要求：

l  测试是可重现的

l  每个迭代起始于相同的系统状态

l  没有其他的应用在系统后台运行

l  软硬件测试环境和生产环境基本一致

3  制定性能优化目标

      根据成本效益分析（Cost-Benefit Analysis）模型，付出的努力永远要和获得的收益取得平衡。优化无止境，因为没有目标就不知道何时停止研究更好的解决方案。因为性能是有时间和金钱成本的。当DBA考虑需要多少时间和金钱用于性能优化时，要评估一下所花费的时间成本和金钱成本。

      性能优化通常可以解决的问题包括减少响应时间和提高事务吞吐量。在具体实践中，可以通过上一节描述的基准测试方法找到系统诸如响应时间和吞吐量的阀值。这个阀值具有下面的重大意义：

l  方便用来对性能目标进行量化。例如需要将系统优化到95%的阀值能力。

l  方便了解当前系统性能状态。例如增加了一个新模块，容易判断新的模块对整个软件系统的性能影响。

l  方便决定是否还需要进一步的优化。例如，现在系统性能已经到达90%以上阀值，考虑到边际效应，以后的优化只能产生越来越少的效益。

      最后，必需指出的是如果所有的优化方法都不太有效，这个时候，就需要重新调整优化目标和预期。为了取得更加显著的性能提高，需要有针对性地增加存储，使用更快的CPU、更多的内存、更快的网络连接，或者上面三者的组合。

4  把问题分类

       性能优化的背后实际上是业务需求驱动的。首先需要从业务角度将问题分类并识别结果，即从业务角度确定问题，设定每个问题的优化目标，并设定每个问题的优先级。随后从系统角度确定原因，弄清楚时间花在何处？时间是如何被消耗的？如何减少时间耗费？同时要考虑到不同问题之间的连带效应，避免解决一个问题的同时带来新的问题。

       在为性能问题分类前，我们可以从考虑下面的问题入手，这样非常有助于后续工作的开展，例如：

1.    是否有性能降低，与什么相关？我们的“基准”是什么？

2.    一个系统的性能看起来在随时间流逝下降了？还是与一个不同的系统或不同的应用比较下降了？数据量增加了？所有的硬件都运行正常吗？

3.    性能下降是什么时候发生的？在另一个工作负载运行之前、之中、之后？性能下降周期性的发生？甚至如果这个任务没有直接和数据库相关，它也可能由于消耗网络或者 CPU 资源影响数据库性能。

4.    性能下降的前后关系有什么变化吗？通常是，添加了新硬件、或应用程序被更改了、大量数据被加载、或者更多的用户访问这个系统。

5.    能不能向数据库管理员、应用程序开发人员以及架构师多了解一些业务和系统情况？因为DB2 服务器几乎总是硬件、其它中间件和应用程序这样复杂环境的一部分。

本文摘自《DB2设计与性能优化-原理、方法与实践》第一版，第二版在写作中。