网络计算环境的调整与优化

10.7　Oracle网络计算环境的调整与优化

在评估性能问题时，了解应用的工作流程并估算每个组件的产量是必须的。预先测试和容量计划提供了生产前的符合实际的估算并可解决大多数的性能问题。缺乏一个测试环境和容量计划会增加性能故障和服务级别不足的可能性。为了获取最佳结果，应用程序必须减少等待时间并避免大量的同步点。

应用程序必须平衡每个组件的作用，避免出现薄弱环节。对每个组件的限制都必须很好地归档并要搞清楚。只有当应用程序效率高且等待时间已最小化时，才考虑实现的可测量性。

因此，优化系统的关键是清楚总体应答时间是如何使用的。正如Anjo Kolk在其公告“Oracle性能诊断方法学”（1998）中讨论的应答时间、服务时间和等待时间的关系时指出：

应答时间=服务时间（CPU时间）+等待时间

用户一定要搞清楚时间花费在何处才能把精力集中在主要的瓶颈处。一般性法则是：当没有系统或网络瓶颈存在时，80%的性能问题是由应用程序设计和编码引起的。

一旦清楚了每个组件限制，就需要有一种监视它的方法（也就是一种全面的监视方法），表10-1列出了必须被监视的组件。

表10-1　必须被监视的组件列表

续表

10.7.1　解决性能故障问题的前提条件

为了解决性能故障问题必须满足下列前提条件：

（1）实施容量计划并具有符合实际的服务级。

必须清楚当前的性能服务级。服务级包括诸如所希望的应答时间、产量及用户人数等项。

随着这些需求的增加，系统资源和拓扑结构需要重新估算。

（2）绘制全系统结构图。

清楚完整的系统、容量限制及拓扑结构有助于判定潜在的瓶颈位置并使用户对应用程序工作流程有一个更全面的了解。应用程序工作流程描述了数据经过不同的应用层和系统层的运动过程。了解内部的依赖性关系有助于找出性能问题的关键点。用户必须清楚应用程序和数据在何处同步，因为这里很可能是瓶颈。

（3）建立一个监视环境并收集充分统计值。

没有监视环境，就没有任何启发性数据和统计值以预防、检测和修复问题。固有的一个好的监视环境就是对不同资源值和限制的了解。

（4）了解基本线和峰值。

首先研究基本线。来自于基本线和峰值周期的统计值创建了比较和调试所需要的控制环境。

（5）检测并记录对应用程序轮廓或工作级别所做的修改。

解决故障关键是先检测修改，然后收集信息，分析这些修改产生的影响。应用程序的修改可能会动态地影响CPU或I/O资源的使用情况。例如，删除一个索引可能迫使Oracle做上百万行的表扫描，用尽系统资源和数据库缓冲区高速缓存。Web应答时间可能会随着增长3倍。

（6）检测资源消耗的差异。

一旦清楚了变化的内容，就可以比较资源消耗的差异，并深入研究特定的问题区域。

（7）优化或修改应用。

大多数优化都首先是针对应用程序的。除去系统和数据参数牵扯的因素，性能问题的主要原因是书写的代码不好。

10.7.2　评估栈

遇到故障时首先需要确定问题出现的层或区域，这时需要考虑各系列的所有的组件如客户机、网络和应用程序。用户应该要求自己能够回答下列问题：

（1）应用程序是否瓶颈。

如果断定应用程序是瓶颈，就依据应用程序的需要优化应用程序。应用程序的优化可以提高产量，并缩短应答时间。例如，在线事务处理（OLTP）应用决定了产量性能，因为这些应用每天要处理几百万条事务。另一方面，决策支持系统（DSS应用）决定了应答时间性能。

（2）客户机是否瓶颈。

理想中，用户的操作对客户机应该是透明的，但是，如果客户端的用户应用程序需要大量的内存或磁盘空间，那么就需要评估或指定适当的客户机以满足终端用户的要求。通过本地运行所有数据做一快速测试可以很容易地判定客户机是否能处理其负载。在电子商务和Internet世界中，公司不控制或管理客户机。但是，如果应用程序资源紧张，那么客户就会避免使用其服务或寻找其他途径。简单易行是关键。

（3）网络是否瓶颈。

网络可能是一个最大的性能瓶颈。需要估算当前和所希望的峰值负载，看看当前的网络容量是否能适应这种负载。记住网络性能的两个基本点：容量和延时。总体容量受最慢的同步连接限制。确信框架能够支持所有它服务的较小网络段。延时（即包间时间）也是关键。

典型地，包数越少通过WAN越慢，最好是大量数据包。冲突、超时和重传可能最终消耗网络的带宽。

（4）应用服务器层是否瓶颈。

评估应用程序时，最好用从上至下的方法。但是，评估操作系统和硬件可能比估计应用程序代码和应用服务器要容易得多。通过检查基本内容，通常就可以解决大多数的问题，首先验证硬件和操作系统配置及运行的有效性。日志和监视能提高诊断速度。

（5）数据库服务器层是否瓶颈。

一组丰富的工具集和有启发性的信息可用于监视数据库。