循序渐进DB2 (第2版)——DBA系统管理、运维与应用案例

性能调整概述

为什么要进行性能调优呢？因为我们的应用系统在运行一段时间后，用户报告系统运行会变慢，使他们不能完成所有的工作，完成事务和处理查询花费了过长的时间，或者应用程序在一天中的某些时段变慢。要确定造成问题的本质原因，必须评估系统资源的实际使用情况并进一步地分析资源使用的瓶颈所在。
用户通常报告以下性能问题：
● 事务或查询的响应时间比预期的长
● 事务吞吐量不足以完成必需的工作负载
● 事务吞吐量减少
为了维持数据库应用程序的最优性能，应该制定一个计划用于评估系统性能，以便在性能出现问题的时候，该计划可以根据性能问题的情况对数据库做出调整，以维持良好的性能。定期的、特定的评估能够帮助您预见并纠正性能问题。通过尽早识别出问题，可以有效地防止这些问题严重地影响用户。
本章我们将通过一个实际生产中的客户案例，展开对性能调整的讲解。本章主要内容包括：
● 性能概述
● 性能目标
● 性能评估
● 性能模型
● 什么时候需要性能调整
● 性能调整准则
● 性能调整的方法和过程
● 保持良好性能
1.1  性能概述
首先让我们以一个真实的某移动公司应用案例来展开性能调整的话题，图1-1和图1-2分别为该移动公司营账应用系统的逻辑架构部署图和物理架构部署图。
 

图1-2中的某移动公司营账系统是一个大型的复杂系统。在这个系统中，从上至下包括以下几个层次：应用程序、中间件应用服务器、数据库、主机系统(操作系统)、光纤交换机和SAN存储网络(IBM ESS)。在系统发生性能问题时，性能问题的定位和调优很复杂。
 

该移动公司营账应用系统的信息架构如下：
● 存储：采用的是IBM ESS 800存储系统
● 操作系统：IBM AIX 5.3(p 690)
● 数据库：IBM DB2 V8.2.1
● 中间件：IBM WebSphere 5.1
● Web服务器：IBM Http Sever
● 应用：采用基于J2EE的Java应用
该移动公司计费业务中心营账系统从年初开始陆续上线，营账系统在上线运行一段时间后出现性能问题。主要表现在对最终用户的交互响应速度不如预期，尤其在业务繁忙时更是无法得到及时的交互响应。从主机系统上观察，主要表现在系统的I/O等待时间较长。营账系统是由业务应用程序、DB2数据库、AIX主机、ESS存储多个部分组成，因此性能瓶颈的定位和性能的优化都比较复杂。
那么我们如何来解决这些性能问题呢？有两种方法：
● 第一种方法是我们可以通过扩容硬件物理资源(增加CPU、内存以及购买更快的存储系统)来实现。
● 第二种方法是我们试图对应用系统作出相应的调整来优化系统以改善目前的情况。
第一种方法我们需要投入更多的经济成本，而第二种方法需要我们利用经验来对整个系统作出调整。本书中我要介绍的是第二种方法。
在进行调整之前，您有必要先了解关于性能调优方面的某些话题。
首先，性能的概念是什么呢？性能是业务应用系统(例如我们本章所举的移动公司营账系统案例)在特定硬件资源(例如32路CPU、128GB内存)和工作负载下所表现出来的处理能力。性能主要通过系统响应时间、吞吐量和可用性来衡量。
性能受以下因素影响：
● 系统中可用的物理资源
● 如何充分合理地利用这些资源
一般情况下，通过性能调整我们可以完成以下目标：
● 处理更大的或更紧迫的工作负载，而不增加处理成本，例如增加工作负载而不用购买新硬件或占用更多处理器时间
● 获得更快的系统响应时间或更大的吞吐量，而不增加处理成本
● 降低处理成本，而不会降低对用户的服务
1.2  性能评估
以下评估描述了事务处理系统的性能：
● 吞吐量
● 响应时间
● 每个事务的成本
● 资源利用率
1. 吞吐量
吞吐量用于评估系统的整体性能。对于事务处理系统，吞吐量通常用每秒事务数(TPS)或每分钟事务数(TPM)来计量。吞吐量取决于以下因素：
● 服务器硬件资源配置
● 软件中的处理开销
● 磁盘上数据的布局
● 硬件和软件都支持的并行度
● 正在处理的事务类型
2. 响应时间
响应时间用于评估单个事务或查询的性能。通常认为，响应时间是从用户输入一个命令或激活一个功能开始一直到应用程序指示已完成该命令或功能所消耗的时间。典型DB2应用程序的响应时间包括以下操作序列(每个操作都需要一定的时间，响应时间不包括用户思考和输入查询或请求的时间)：
(1) 应用程序将查询转发到数据库服务器。
(2) 数据库服务器执行查询最优化并检索所有用户定义的SQL、命令、脚本和程序。
(3) 数据库服务器检索、添加或更新适当的记录并执行与查询直接相关的磁盘I/O操作。
(4) 数据库服务器执行在查询或事务仍处于暂挂状态的同期发生的所有后台I/O操作(如日志记录和脏页面清除)。
(5) 数据库服务器将结果返回给应用程序。
(6) 应用程序显示信息或发出确认，并随后向用户发出新的提示。
图1-3显示了步骤(1)~(6)中所述的操作如何作用于整体响应时间。
 
  

3. 响应时间和吞吐量
响应时间和吞吐量是相关联的。在您增加总体吞吐量时一般事务的响应时间会减少。但是，可以通过为特定查询分配不成比例的资源数量，在牺牲总体吞吐量的情况下减少该查询的响应时间。与之相反，可以通过限制数据库分配给大型查询的资源数来维持总体吞吐量。
当尝试在对高事务吞吐量的当前需求和对执行大型决策支持查询的即时需求之间取得平衡时，吞吐量与响应时间之间的平衡就变得明显起来。应用于查询的资源越多，可用于处理事务的资源就越少，并且查询对事务吞吐量的影响就越大。相反，提供给查询的资源越少，查询花费的时间就越长。
4. 每个事务的成本
每个事务的成本是财务上的量度，通常用于比较应用程序、数据库服务器或硬件平台之同的总体操作成本。
要评估每个事务的成本，通常采用下面的方法：
(1) 计算与运行应用程序相关的所有成本，这些成本可能包括硬件和软件的安装成本、运作成本及其他费用。
(2) 设计应用程序有效期的事务和查询的总数。
(3) 用总成本除以事务总数。
尽管该测量对于进行规划和评估很有用，但是它与达到最佳性能的运行问题几乎无关。
5. 资源利用率和性能
典型的事务处理应用程序在其各个运行周期中需要满足的要求各不相同。一天、一周、一月、一年中的峰值负载以及决策支持(DSS)查询或备份操作所施加的负载对于任何容量将用尽的系统都会产生明显的影响。可以使用从特定系统派生的直接历史数据精确地测定这种影响。
必须对系统的工作负载和性能进行定期评估，以预测峰值负载并比较使用周期中不同时刻的性能评估。定期评估有助于为数据库服务器上的应用程序开发总体的性能概要文件，该概要文件对于确定如何可靠地提高性能具有关键意义。
关于操作系统提供的用于评估对系统和硬件资源的性能影响的工具，请参阅本书第2章“操作系统及存储的性能调优”。
资源利用率是与系统资源可用的总时间相比，该系统资源实际被占用的时间的百分比。例如，如果CPU在一分钟内总共用42秒处理事务，那么在这段时间间隔内的利用率就是70％。
定期评估并记录以下系统资源的利用率：
● CPU
● 内存
● 磁盘
● 网络
当某项资源被过度使用或者它的利用率与其他系统资源的利用率不成比例时，就称该资源对于性能是临界的。例如，当一个磁盘的利用率达到70％，而系统中其他所有磁盘的利用率只有30％的时候，可以认为该磁盘是临界的或是被过度使用。尽管70％并不表示磁盘被严重过度使用，但可以通过重新安排数据来平衡整个磁盘集上的I/O请求，从而提高系统的性能。
如何评估资源利用率取决于操作系统为报告系统活动和资源利用率所提供的工具。一旦发现看起来被过度使用的资源，就可以使用数据库服务器的性能监视实用程序来收集数据，并对可能占用该系统资源上负载的数据库活动进行干涉。可以调整数据库的配置参数或操作系统的相关I/O配置，以减少那些数据库活动或将它们分散到其他资源中(关于这部分的详细内容请参见本书第2章)。

http://sale.jd.com/act/JdiKt3VT8v2WX.html