本节介绍性能下降问题的常见现象和处理流程。
性能下降（Performance Degradation），主要是指系统的性能随时间而逐渐下降（这里假定在系统性能下降的过程中系统的负载状况没有明显变化）。这里的性能指标可以包括第 2 章介绍的各种性能指标，所以系统运行过程中占用的 CPU 或内存随时间增加也属于广义的性能下降问题。
在生产环境中，通常由终端客户最先感觉到并报告性能下降问题。所以狭义的性能下降问题主要是指系统运行指标随时间变化，比如吞吐率随时间下降或页面响应时间随时间上升，或者两者兼而有之。
在性能测试中发现或重现性能下降问题主要通过可靠性测试用例进行，即通过较长的执行时间发现各种性能指标的变化趋势。当然，与发现内存使用问题一样，也可以采用提高系统负载的方法（如长时间压力测试）加快性能下降问题现象的出现。
由于可靠性测试的代价比较高，所以性能测试过程中可靠性测试用例的覆盖范围一般比较小。因此，在压力测试过程中作者也推荐测试人员仔细考察测试工具性能指标报告中的变化趋势，以发现潜在的性能下降问题。
图 11-1 与图 11-2 所示为某 3 小时压力测试过程中测试工具提供的吞吐率和响应时间变化曲线，从中可以看出明显的性能下降趋势。
按照性能下降问题出现的范围，又可以将其分为局部（某个模块或某些页面 / 命令）的性能下降问题和全局的性能下降问题。
性能下降问题的现象虽然都差不多，但是引起性能下降问题的原因却很复杂。根据作者的经验，性能下降问题一般由以下单个或多个原因混合导致。
图 11-1. 吞吐率下降曲线示例
图 11-2. 响应时间上升曲线示例
应用程序资源使用问题。主要是内存使用问题，即由于应用服务器的内存碎片问题或内存泄漏问题，导致垃圾回收的开销随时间增大。也有可能是因为磁盘临时文件积累造成磁盘访问开销增大。
应用程序设计问题。由于应用程序的设计存在可扩展性或可靠性问题，导致运行开销随时间或业务对象的积累而增大。
数据库访问问题。该问题又可以分为许多类型，如调优参数问题、表结构或索引设计问题、垃圾数据问题等。其共同特点是导致应用程序利用特定操作访问数据库的开销随时间而增大。
服务器软件资源使用问题。虽然可能性很小，但是应用服务器、数据库服务器等服务器程序也是软件程序，也有可能存在性能下降问题。这些服务器程序在自身测试过程中可能遗漏了某些性能问题，而在用户特定的执行状况下触发了这些问题，结果导致这些服务器程序使用的操作系统资源泄漏而出现性能下降问题。
测试用例设计问题。性能测试中有可能发现一些“假”的性能下降问题。比如测试用例设计时假设在测试执行过程中系统负载保持恒定，但实际的测试用例实现导致系统负载或特定页面的处理内容随时间增多，也可能导致测试工具的测试报告中出现性能下降问题。
如前所述，性能下降问题的原因可能来自多方面，所以分析性能下降问题时，推荐从自顶向下分析方法开始。
第 7 章介绍过自顶向下分析方法重视产生问题的条件而不是问题本身的现象。应用到性能下降问题，就是通过比较性能下降前后的环境不同，通过排除法确定可以使性能恢复的条件（也就是导致性能下降的条件）。确定了产生性能下降问题的条件，也就确定了性能下降问题产生的位置（来源），从而为进一步确定问题的真正原因及解决方案奠定了基础。与性能调优的原则类似，采取操作恢复性能的时候很可能会破坏问题现场，所以一次只能恢复一个条件并应做好系统备份工作。
采用自顶向下分析方法分析性能下降问题的过程如图 11-3 所示。
图中体现了性能下降问题出现前后可能的各种环境差异，如应用服务器状态、操作系统状态和数据库内容等。值得注意的是系统中的临时文件（包括各种服务器程序产生的数据文件或日志文件）也可能是导致性能下降问题的原因。所以清除各种临时目录（应用服务器的临时目录、数据库服务器的临时目录及操作系统的临时目录等）也可以用来检验是否可以恢复系统性能。本书第 12 章会涉及一个由于磁盘动态高速缓存文件导致的性能下降问题，该问题就是通过删除应用服务器临时目录（默认情况下动态高速缓存文件存放在应用服务器临时目录下）发现的。
正如第 7 章介绍的那样，采取自顶向下分析方法确定问题出现的范围之后，可以采用自底向上分析方法找到产生性能下降问题的真正原因。
这里介绍作者在性能测试过程中分析解决数据库引起的性能下降问题的过程。如图 11-4 所示为该分析过程的流程图。
下面是对该分析流程图的各步骤的简要说明。
1．在性能测试报告中检查是否所有页面 / 命令的响应时间均随时间下降。这可以通过把一个较长的性能测试分为几个连续的小段执行，分段收集页面响应时间来实现。如果只有少数特定的页面响应时间变慢，这往往是特定页面设计或代码实现的问题所导致的，可以使用一些运行剖析分析工具（如 Jinsight 等）来分析代码执行时间为什么随时间延长。该问题一般不属于数据库引起的性能下降问题。
2．检查重新启动 WebSphere 应用服务器后，性能下降问题是否仍旧存在（即性能指标是否恢复到下降前的水平）。如果重新启动 WebSphere 应用服务器后，性能指标恢复，通常说明问题是由应用服务器的运行状态引起的。最常见的是内存使用问题，可以通过垃圾回收日志分析确定是否存在内存使用问题。本书第 10 章已经介绍过内存使用问题的分析方法，本章着重对非应用服务器问题进行讨论。
3．检查数据库服务器的统计信息是否需要更新。本书第 9 章讨论死锁问题的时候，已经强调过数据库统计信息对于 SQL 操作访问计划的影响。如果在性能测试过程中，数据库特定数据表的统计信息发生了巨大变化，则在性能测试开始时优化的访问计划到出现性能下降问题时已经完全不适用了。所以当出现性能下降问题的时候，可以考虑更新数据库的统计信息然后看性能是否恢复。第 9 章已经介绍过，对于 DB2 系统可使用 runstats 和 reorg 命令更新数据库统计信息。对于 Oracle 数据库，可采用下面的命令来达到类似的效果：
execute dbms_utility.analyze_schema ('schema_name','COMPUTE')
|
4．检查数据库配置参数是否需要调优。如果没有做过参数调优，可以考虑通过性能监视和日志分析进行参数调优过程。可能解决性能下降问题的 DB2 性能参数包括缓冲大小（BUFFPAGE），排序堆大小（SORTHEAP）等。数据库参数调优过程在第 8 章中已经有所介绍，这里不再赘述。如果数据库参数调优后，交易吞吐率下降问题仍然存在，那么可能需要检查是否存在特定的 SQL 执行次数或开销异常。如果没有发现特定的 SQL 开销异常，则转到下一步继续进行分析。
5．检查数据库中的数据是否存在分布不均匀的情况。性能测试过程中数据分布的不均匀往往是由预热执行过程不合理或正式运行时用户分布不均匀导致的。本书第 5 章介绍性能测试用例设计问题的时候讨论过类似问题。以电子商务应用中的购物场景压力测试为例，在预热执行阶段或正式执行时总是用特定的用户下订单，就会导致数据库中的订单与用户分布不均衡，少量用户拥有大量订单。解决方法也在第 5 章中介绍过，即让虚拟用户在一个大数量的用户集合内随机登录进行操作。
6．缩小测试场景。如果泛泛的数据库分析手段不能找到问题的真正原因，那就需要缩小测试场景进行问题的精确定位。这个过程又称为分割和排查（Divide and Conquer），具体做法是通过调整测试脚本将复杂的测试场景分解为若干个简单的片段分别进行测试。例如对于电子商务应用中的购物场景，可以分解为单纯的用户登录 / 退出场景，产品目录浏览场景，产品搜索场景和订单处理场景等。如果发现性能下降问题只存在于某个特定的子场景中，则对该子场景继续进行分割和测试直到缩小到可以重现性能下降问题的最小单元为止。此时就可以针对发生性能下降问题的最基本单元做针对性分析，从而加快分析和解决问题的速度。
7．对上一步中确定的发生性能下降问题的最小测试场景进行长时间的压力测试，并在测试的过程中对数据库获取多次快照，从而获取性能下降各个阶段的数据库状态信息。例如，可以针对发生问题的测试场景进行为期两天的压力测试，然后分别在测试第 12 小时、第 24 小时和第 36 小时获取数据库快照，通过对比不同阶段的数据库快照文件来发现问题。
8．对比不同阶段的数据库快照，检查是否出现 SQL 语句的总执行成本和该 SQL 语句的执行次数的比值（Cost/SQL，即单次 SQL 语句的执行成本）变大的情况。如果 Cost/SQL 变大，可以通过清除数据库中的垃圾数据或调整数据表索引来尝试解决性能下降问题。通过对比不同的数据库快照文件，可以找出执行成本增加最快的 SQL 语句。SQL 语句的运行成本包括每次 SQL 查询的执行时间，每次 SQL 执行期间的用户 CPU 和系统 CPU 的占用时间等。需要注意的是，必须在不同的数据库快照文件中对比同一个 SQL 语句的统计信息来判断其执行成本是否增大。
9．如果 Cost/SQL 在测试运行期间保持相对稳定，可以通过比较数据库快照文件来观察某些 SQL 语句是否存在每次执行该 SQL 语句时所读取的数据行数（rows read/exec）逐渐增大的情况。如果存在读取行数逐渐增大的 SQL 语句，应该尝试调整其对应的索引来改善数据库性能；否则需要通过分析访问计划（Access Plan）来判断其他数据库设计是否还有改进的余地。
需要注意的是，尽管该流程图中已经涉及了很多可能导致应用系统性能下降的数据库问题，但这并不是一个数据库问题的完备集合。读者完全可以根据自己的经验和出现的性能下降问题的实际情况制订自己的分析流程。作者的分析流程只是用来说明导致性能下降问题的原因的复杂性。这从另一个方面也说明了自底向上分析方法的局限性。
本节介绍一个作者实际工作中通过自顶向下方式分析解决性能下降问题的实例。该实例中，性能下降问题发生在一个执行时间 3 小时的压力测试中，待测试的 WebSphere 应用运行在 AIX/DB2 软件平台，采用单节点的测试环境。
该性能下降问题发生在一次电子商务应用的性能测试过程中。该测试用例是一个包含复杂商业模型和促销活动的购物场景。测试类型为 3 小时的压力测试，测试软件环境为 AIX/DB2 平台，测试环境的拓扑结构为单节点（Web 服务器、应用服务器和数据库服务器在同一台物理服务器上）。
在最初的 3 小时压力测试过程中发现有一定的性能下降趋势，通过将压力测试的执行时间延长到 12 小时，可以在测试工具提供的报告中发现非常明显的性能下降趋势。12 小时的吞吐率和响应时间变化曲线如图 11-5 和图 11-6 所示。
可以看到经过 12 小时的压力测试，系统的吞吐率几乎下降到 0，而响应时间也上升为最初的 5 到 10 倍。
遇到这个性能下降问题之前，作者刚解决过一个现象类似的性能下降问题，问题是由磁盘动态高速缓存引起的（本书第 12 章将介绍该问题）。作者想当然地认为这次的性能下降问题也是由类似原因引起的，因此作者就从这个假定出发进行自底向上的分析。经过反复的分析动态高速缓存和内存使用状况，仍然没有找到问题的真正原因。这时一位同事提醒作者，应该首先用自顶向下分析缩小出现问题的范围。于是作者采取了自顶向下分析，结果很快找到了问题的真正原因。
图 11-5. 12 小时压力测试吞吐率变化曲线
图 11-6. 12 小时压力测试响应时间变化曲线
依照本章前一节介绍的自顶向下分析性能下降问题的过程，应该从可以恢复系统性能的条件入手，缩小导致系统性能下降的问题范围。于是，作者重新运行了一次 12 小时的压力测试，此时系统出现了非常明显的性能下降现象。然后作者依次尝试了各种手段恢复系统的性能，即采取特定手段后，运行非常短的一段时间压力测试，将得到的系统吞吐率与 12 小时前的系统吞吐率做比较，判断性能是否已经恢复。如果没有恢复，则尝试下一项手段，并重复短期压力测试。为了验证该性能下降问题是否与动态高速缓存相关，作者采取了一些与动态高速缓存相关的恢复手段。
作者所采用的恢复手段和测试结果如表 11-1 所示。
| 操作编号 | 操作内容 | 是否能恢复系统性能 |
| 1 | 清除内存中的动态高速缓存条目 | 不能 |
| 2 | 重新启动应用服务器 | 不能 |
| 3 | 清除应用服务器临时目录（包括磁盘动态高速缓存），然后再重新启动应用服务器 | 不能 |
| 4 | 重新启动数据库服务器 | 不能 |
| 5 | 恢复 12 小时前的数据库备份并重新启动操作系统 | 能 |
通过这个自顶向下分析过程，可以明显看出该性能下降问题与应用服务器状态（包括动态高速缓存使用）无关，而完全是由于数据库访问的问题（初步怀疑是配置参数问题或统计信息更新问题等）导致。
接下来，作者分析了 12 小时测试构成中的操作系统监视结果和数据库监视结果（这次 12 小时测试执行过程中进行了性能监视）。
测试过程中 nmon 提供的操作系统监视汇总信息（包括 CPU 和磁盘传输信息）如图 11-7 所示。
由此信息图可发现在 12 小时测试进行过程中，系统的磁盘传输（Disk xfers）逐渐增大，与此同时系统 CPU 占用率逐渐下降。进一步检查单个 CPU 的使用情况，发现 1 号 CPU 的 Wait 状态占用率明显增大，如图 11-8 所示。这说明 CPU 占用率逐渐下降是由于等待磁盘 I/O 引起的。
接下来分析磁盘传输汇总信息，如图 11-9 所示，可以看出磁盘写数据量没有明显增加，但是磁盘读数据量明显随时间而增加。
仅凭磁盘传输汇总信息，还不能确定磁盘读取是由什么操作引起的。好在前面的自顶向下分析已经确定不是由应用服务器读取导致的性能下降问题。所以基本可以肯定不断增加的磁盘读取操作是由数据库引起的。
随后，分析 DB2 的快照监视器的监视结果，可以发现 DB2 缓冲池（Buffer pool）的数据和索引物理读（physical read）的比例非常高。如下例所示：
Buffer pool data logical reads = 5502388 Buffer pool data physical reads = 430671 Buffer pool temporary data logical reads = 0 Buffer pool temporary data physical reads = 0 …… |
可以看到缓冲池的物理读比例（即缓冲池不命中率）高达 7%，这远远大于 1% 的警戒线。而且物理读比例有随时间增加的趋势（通过不同时间的快照信息对比发现）。
至此可以怀疑性能下降问题是由于 DB2 的缓冲池配置参数设置不当引起的。考察数据库配置参数信息发现，该数据库的 BUFFPAGE 参数值为 10 000。与该测试用例使用的数据规模相比，这个参数值明显偏小。于是作者将 BUFFPAGE 参数值增大 10 倍，变为 100 000，重新运行性能测试，发现性能下降问题基本消失。
重新测试 3 小时的吞吐率报告如图 11-10 所示。
从图中可以看到 3 小时内的吞吐率基本稳定。
nmon 产生的系统汇总报告如图 11-11 所示。
从图中可以看到 CPU 占用率和磁盘传输基本保持稳定。
通过 DB2 快照监视器看到缓冲区的物理读比例也下降到了 1% 以下。
图 11-11. 3 小时 nmon 操作系统监视汇总信息图
清单 2. 缓冲池监视结果 2
Buffer pool data logical reads = 2272348 Buffer pool data physical reads = 19283 Buffer pool temporary data logical reads = 0 Buffer pool temporary data physical reads = 0 …… |
至此性能下降问题基本得到解决。但是在延长到 12 小时的压力测试过程中，发现吞吐率仍然有轻微下降的趋势。经分析发现是由于该测试用例的吞吐率比较高，短时间内向数据库内插入了大量数据引起的。通过在测试过程中定期运行 DB2 的 runstats 命令可以解决该问题。解决该问题后，性能下降问题彻底解决。
在本节中，再介绍一个使用本章所介绍的自底向上分析方法解决由数据库引起的性能下降问题的实例。
本节介绍的仍然是由数据库访问引起的性能下降问题，但是比上一节介绍的实例更复杂。在简单地自顶向下分析确定问题范围之后，即转入 11.1.2 介绍的自底向上分析过程。
本实例仍然来自于电子商务应用的性能测试过程。该测试用例与前一节介绍的测试用例比较类似，是另一种类型商店的购物场景。测试类型为 3 小时的压力测试，测试软件环境为 AIX/DB2 平台，测试环境的拓扑结构为单节点。
在该压力测试用例开始执行的过程中，只发现系统的吞吐率没有达到预先定义的通过标准。在对吞吐率问题进行问题诊断的过程中，偶然发现性能有轻微的下降趋势。测试工具产生的吞吐率和响应时间报告如图 11-12 所示。
从图中看到的性能下降趋势尽管轻微，但是确实存在。通过把 3 小时的压力测试分为连续三个 1 小时的压力测试，对比吞吐率和响应时间的报告证实了确实存在性能下降问题（每小时吞吐率下降在 5% 以内）。而且，如果系统能够保持第 1 小时的吞吐率，就可以达到该压力测试用例的通过标准。所以，作者就将分析的重点转向解决该性能下降问题。
作者按照 11.1.2 介绍的针对数据库引起的性能下降问题的分析流程进行了如下分析。
首先作者按照前述分析流程中第 1 步到第 3 步进行简单的自顶向下分析，确定问题出现的位置。
1．通过对 1 小时、2 小时和 3 小时的测试报告进行比较，发现所有页面的性能都有下降的趋势（响应时间上升）。与订单相关的页面下降趋势较为明显，但是基本可以排除特定页面处理逻辑存在性能下降问题的可能。
2．测试运行 3 小时后，重新启动 WebSphere 应用服务器再进行 1 小时压力测试，吞吐率不能恢复。
3．使用工具分析 WebSphere 应用服务器的详细垃圾回收日志文件，发现 JVM 垃圾回收和内存分配过程基本正常。为了保险起见，测试人员进行了延长到两天的压力测试。图 11-13、图 11-14 及图 11-15 分别显示了两天内的详细垃圾回收日志的分析结果。
至此可以基本排除内存使用问题，主要怀疑方向为数据库访问引起的性能下降问题。
接下来作者从图 11-4 中所介绍的第 3 步开始继续分析过程。
在第 3 步中，可以确认在运行 3 小时压力测试开始之前已经进行过 runstats 等数据库优化命令。3 小时测试之后（出现性能下降问题时）运行 runstats 命令不能够使吞吐率恢复。所以 3 小时内数据库统计信息没有发生大的变化。
图 11-14. 分配失败前空闲内存大小统计图
图 11-15. 引起内存分配失败的对象大小统计图
在第 4 步中，通过 DB2 快照监视器发现存在一些排序过程中的排序堆溢出现象。作者尝试将 DB2 排序堆参数 SORTHEAP 由初始值 1 024 增至 2 048，排序堆溢出现象基本消失，但是对系统整体吞吐率影响不大，同时没有发现其他 DB2 调优参数需要调整。
在第 5 步检查数据库的过程中作者发现某些表存在数据不均衡问题。本测试场景为购物场景，所以测试执行过程中主要产生的是订单数据。作者在订单数据表上执行查询操作，得到如下结果：
db2 => select member_id, count(*) from orders group by member_id having count(*) > 50 MEMBER_ID 2 -------------------- ----------- -1002 4353 100010000020 1949 100010000021 276 100010000022 261 100010000023 254 100010000024 261 100010000070 1062 100010000071 271 100010000072 260 100010000073 249 100010000074 246 100010000120 940 100010000121 263 100010000122 247 100010000123 264 100010000124 276 100010000170 1028 100010000171 249 100010000172 262 100010000173 244 100010000174 251 |
从中可以发现除了 MEMBER_ID 为 -1 002 的用户（这在电子商务系统中是一个特殊的管理员用户）外，还有 4 个用户（其 MEMBER_ID 为 100010000020、100010000070、100010000120 和 100010000170）的订单数量远远多于其他的用户。在重新审核测试人员的执行步骤后，作者找到了产生数据不均衡问题的原因。
在预热执行阶段，测试人员仅仅使用了 4 个固定的用户执行购物流程，从而使与这 4 个用户相关的订单数据远多于其他用户。
数据库中有 200 个注册用户，但是在实际的压力测试运行阶段只使用了其中 20 个注册用户执行购物流程，从而造成数据库中只有十分之一的用户产生了较多数量的订单而大多数用户并没有订单产生。
对应上面的问题，解决方法也包含以下两个方面。
在数据库中将注册用户数量从 200 增加到 400。
在预热执行和测试正式执行期间从 400 个注册用户中随机挑选用户执行测试脚本，从而将原本由 20 个注册用户产生的订单数据较均匀地分配给 400 个注册用户。
经过这两项调整，重新进行的压力测试中不再出现上面的数据不均衡问题，单个用户的相关订单数也下降到了 50 以下。
解决了数据不均衡问题之后，发现压力测试的吞吐率结果略有提升，但是性能下降问题并没有完全解决，仍旧有轻微的下降趋势。因此还需要进一步分析可能产生性能下降问题的原因。
在第 6 步中，经过几轮分割与排查，作者发现只有下订单场景有明显的性能下降问题，其他场景（用户登录和产品目录浏览等）没有明显的性能下降问题。于是作者将测试脚本缩小至用户下订单这个场景片段来重点分析。
在第 7 步中，针对用户下订单这个场景片段连续 4 天执行压力测试并在第 2 天和第 4 天的 10 小时时间点上取得两个 DB2 快照监视器输出文件。
以下为第 2 天 10 小时时间点上所取得的快照监视器输出文件中的 SQL 语句快照结果：
清单 4. 第 2 天 10 小时时间点上输出文件中的 SQL 语句快照结果
＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃ Number of executions = 32190 Number of compilations = 0 Worst preparation time (ms) = 16 Best preparation time (ms) = 2 Internal rows deleted = 0 Internal rows inserted = 0 Rows read = 1887446809 Internal rows updated = 0 Rows written = 0 Statement sorts = 0 Statement sort overflows = 0 Total sort time = 0 Buffer pool data logical reads = 1905882921 Buffer pool data physical reads = 65 Buffer pool temporary data logical reads = 0 Buffer pool temporary data physical reads = 0 Buffer pool index logical reads = 9949316 Buffer pool index physical reads = 0 Buffer pool temporary index logical reads = 0 Buffer pool temporary index physical reads = 0 Total execution time (sec.ms) = 11323.861567 Total user cpu time (sec.ms) = 9643.660000 Total system cpu time (sec.ms) = 101.080000 Statement text = SELECT T1.TOTALTAX, T1.LOCKED, T1.TOTALTAXSHIPPING, T1.STATUS, T1.FIELD2 …FROM ORDERS T1 WHERE T1.MEMBER_ID=? AND T1.STATUS=? AND T1.STOREENT_ID=? ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃ |
以下为第 4 天 10 小时时间点上所取得的快照监视器输出文件中的 SQL 语句快照结果：
清单 5. 第 4 天 10 小时时间点上输出文件中的 SQL 语句快照结果
＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃ Number of executions = 21148 Number of compilations = 0 Worst preparation time (ms) = 4 Best preparation time (ms) = 2 Internal rows deleted = 0 Internal rows inserted = 0 Rows read = 2008877277 Internal rows updated = 0 Rows written = 0 Statement sorts = 0 Statement sort overflows = 0 Total sort time = 0 Buffer pool data logical reads = Not Collected Buffer pool data physical reads = Not Collected Buffer pool temporary data logical reads = Not Collected Buffer pool temporary data physical reads = Not Collected Buffer pool index logical reads = Not Collected Buffer pool index physical reads = Not Collected Buffer pool temporary index logical reads = Not Collected Buffer pool temporary index physical reads = Not Collected Total execution time (sec.ms) = 11367.884559 Total user cpu time (sec.ms) = 9994.690000 Total system cpu time (sec.ms) = 109.820000 Statement text = SELECT T1.TOTALTAX, T1.LOCKED, T1.TOTALTAXSHIPPING, T1.STATUS, T1.FIELD2 … FROM ORDERS T1 WHERE T1.MEMBER_ID=? AND T1.STATUS=? AND T1.STOREENT_ID=? ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃ |
在第 8 步中，通过对比第 7 步中所取得的两个数据库快照文件，并没有发现存在 SQL 语句执行成本和执行次数（Cost/SQL）变大的情况。
在第 9 步中，通过对比第 7 步中所取得的两个数据库快照文件，作者发现了每次执行所读取数据行数变大的 SQL 语句，如图 11-16 所示（图中着重标出的数据对应的 SQL 语句其每次执行所读取的数据行数在第 4 天收集的数据库快照文件中明显变大）。
图 11-16. 每次执行所读取数据行数变大的 SQL 语句统计
图 11-16 中所列出的第一行统计信息即为前面引用的快照监视器输出中对比的 SQL 语句。通过确认这些每次执行读取数据行数变大的 SQL 语句，为解决性能下降问题提供了线索。经过下面的针对性解决方案，系统吞吐率得以明显提升。
- 移除 ORDERS 表中无关的索引 MEMBER_ID + TYPE + STOREENT_ID，这样查询操作可以使用更加适合的索引 MEMBER_ID + STATUS + STOREENT_ID。
- 为表 BUSEVENT 添加新索引 CHECKED。
- 在系统运行过程中阶段性地清除 CTXMGMT 及 BUSEVENT 表中的垃圾数据。
- 删除 MEMBER_ID 为 -1 002 的用户所下的订单数据使得系统性能再次提升 4% （参见第 5 步提到的数据不均衡问题）。
通过以上措施，在新一轮压力测试过程中，图 11-16 中所着重标出的各 SQL 语句其每次执行所读取数据行数变大的问题基本上都得到了解决，如图 11-17 所示（图中着重标出的行所对应的 SQL 语句即为图 11-16 中存在问题的 SQL 语句）。
在解决以上诸多引起 SQL 执行成本增大的问题后，系统在 3 小时的压力测试中没有产生性能下降问题，如图 11-18 所示。
图 11-18 3 小时压力测试中性能平稳
但是，经过长时间（24 小时）的压力测试作者发现性能仍然有轻微的随时间下降的趋势，如图 11-19 所示。
针对这个问题，作者重新分析了数据库统计信息和关键 SQL 语句的访问计划。发现在经过较长时间测试运行后，新增加的大量订单数据导致数据库统计信息已经失效。分析过程第 3 步排除的 runstats 操作在较长时间（压力测试 1 天增加的相对数据量变化大约相当于真实用户几个星期的数据量变化）运行过程中已经变得重要。因此，作者决定在系统长时间的运行过程中定期执行 runstats 命令。图 11-20 及图 11-21 显示了 runstats 命令对 SQL 访问计划的影响。
可以看出，执行 runstats 之后的访问计划去掉了一个排序操作，这在实际系统运行中带来明显的性能提升。这也再次证明了本书第 9 章强调的 runstats 对 DB2 数据库性能的重要性。
在长时间压力测试过程中通过定期执行 runstats 命令使得系统的吞吐率又恢复到了平稳的状态，整个系统性能下降问题最终得到解决。
图 11-20. 执行 runstats 之前的访问计划
图 11-21. 执行 runstats 之后的访问计划
通过本实例，读者可以看到实际工作中数据库访问引起的性能下降问题的复杂性。
  |
|
出处：http://www.ibm.com/developerworks/cn/websphere/book_websphere_performance/11/
1067
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
