工作负载资源需求估计

除非您正在购买配有详细资源需求文档的软件包，否则资源估计可能是性能规划过程中最困难的任务。

造成困难有如下几个原因：

• 执行任何任务都有几种方法。 您可以编写 C (或其他高级语言) 程序， shell 脚本， perl 脚本， awk 脚本， sed 脚本， AIX® 窗口对话框等。 从性能观点看，一些看来特别适合算法和程序员生产力的技术非常昂贵。

  有一条准则很有用，即抽象级别越高，就越要谨慎，以确保某个系统不会承受令人惊讶的性能。 请仔细考虑由一些明显无害的构造所暗示的数据量大小和迭代数量。

• 单个过程的精确成本是很难确定的。 困难之处不仅仅是技术上的；还有哲学上的。 如果多用户运行的给定程序的多个实例正在共享程序文本页面，那么哪一个进程应该负责那些内存页面呢？ 操作系统将最近用过的文件页面保留在内存中，以便为重新访问该数据的程序提供高速缓存的效果。 重新访问数据的程序应该对用来保留数据的空间负责吗？ 某些评估的粒度，比如系统时钟，可以在用于同一程序连续实例的 CPU 时间上产生变化。

  有两种方法来处理资源报告的模糊性和可变性。 第一种是忽略模糊性，持续消除可变性的来源，直到评估变得可一致性接受。 第二种方法是尝试让评估尽可能真实，并从统计上描述结果。 注意后者产生与生产环境有某种相关性的结果。

• 系统很少专门运行单个程序的单个实例。 存在几乎一直处于运行的守护程序、频繁的通信活动和通常来自多个用户的工作负载。 这些活动很少线性增加。 例如，增加给定程序的实例个数几乎没有增加使用的新程序文本页面数，因为大部分程序已存在于内存中。 但是，附加的进程可能导致对处理器高速缓存的额外争用，所以，不仅其他进程不得不和新进程共享处理器时间，而且所有进程都会经历执行每条指令需要更多周期的情况。 这实际上使得处理器速度减慢，结果导致更频繁的高速缓存未命中。

为使您的估计与具体情况所允许的一样真实，请使用以下准则：

• 如果程序存在，对最类似您自己需求的现有安装进行评估。 最好的方法是使用容量规划工具，如 BEST/1。
• 如果没有合适的安装可用，那么进行试安装并对综合工作负载进行评估。
• 如果生成与需求相匹配的综合工作负载是不实际的，那么评估个体的交互作用并将结果用作仿真输入。
• 如果程序还不存在，查找使用同种语言和通用结构的同等程序并对其进行评估。 再次强调，语言越抽象，在确定可比性时就越需谨慎。
• 如果同等程序不存在，那么用规划的语言开发一个主要算法的原型，对这个原型进行评估并对工作负载建模。
• 只有当任何类型的评估都是不可能或不可行的，您才应作一个有根据的猜测。 如果在规划阶段有必要对资源需求进行猜测，那么在其开发阶段尽早对实际程序进行评估是很关键的。

牢记独立软件供应商 (ISV) 对他们的应用程序常常有可缩放的准则。

在估计资源时，我们主要对四个方面感兴趣（无特殊顺序）：

CPU 时间 (CPU time)

工作负载的处理器成本

磁盘访问

工作负载产生的磁盘读写速率

LAN 流量

工作负载生成的信息包数目和交换的数据字节数

实内存

工作负载所需 RAM 的大小

以下各节讨论了在各种情况下如何确定这些值。