目前，大型机容量规划的标准量度是MIPS（每秒百万条指令）。尽管这个标准量度只是个大概，但容量规划员发现，它对LPAR（逻辑分区）的工作负荷和未来测绘增长很有帮助。然而，所有容量规划员和性能大师都应该了解，某些工作负荷仍存在着问题。因为，容量规划处理的只是通常情况，它遗漏了隐藏在间隔期的一些问题。

　　容量规划受各种工作的束缚

　　大家都清楚地了解容量规划，它是一个战略性措施。在RMF（Resource Measurement Facility，资源测量工具）报告中，工作通过多种方式被细分，这样做对企业来说很有好处。容量规划员查看RMF报告后，使用IBM的MIPS图表并在适当大小的处理器中堆积任务就变得相对容易一些。

　　这并不是说这个工作不重要。每一个新的应用执行或系统软件配置更改都可能带来紧急的硬件升级，可能会损失好几千美元。幸运的是大多数时候事情都进展很顺利，企业可以在需要时再购买CPU。

　　但是，如果某些敏感任务突然停止、触发警报，在这奇怪的十秒间隔期内发生了些什么呢？

　　现在，大多数大型机企业都运行各种任务。除了一些特殊任务和特殊应用要求以外，还运行多个DBMS或事务处理器。处理策略性性能问题的性能分析师一定要从各种杂乱的任务中挑选出“最受宠爱”的任务，确保这些任务能得到所需资源。

　　性能容量规划方案

　　优先任务太多会使问题更加复杂。不管优先级多高，如果有多个最优先任务，当所有处理器都繁忙时，就会有任务不得不等待处理器。

　　例如，一个LPAR运行两个高优先级任务：任务A和任务B。任务A是繁重的事务管理工作，工作固定、反复，做企业的大部分重活。任务B则做一些轻松很多的工作，但是它后端支持网站，优先级低于任务A。它们是LPAR中优先级最高的的任务。处理器的总体利用率在80%时，运行很流畅。突然，任务B反应慢下来，这段时间大概5到10秒。由于任务B是公司网站的后端，经理会马上要求解释这个问题。

　　任务B的监控器显示调度时间（dispatch time）延长了。这里，调度时间的定义为任务可以运行，在调度链中等待CPU的时间。因此，任务B的性能分析师可以据此得出结论，此任务暂时正在等待处理器。

　　另一方面，RMF显示在间隔时间内CPU利用率为90%，任务延迟面板（DELAYJ）显示任务B的工作流正常。此外，任务B被限定到工作负载管理器（WLM），以便任务B能够得到所需处理器，而且RMF显示它可用。更让人迷惑不解的是，这种反应慢的现象是周期性的，而且几乎是在每天同一时刻出现。

　　问题反复出现几次后，分析师决定追踪任务B。他们还用RMF II监测处理器在一秒间隔期的利用率。再一次事故后，任务B追踪结果显示，每次间隔大概有100毫秒，间隔期间任务B不执行。同样，间隔期间RMF监控器显示CPU利用率高达百分之九十多。

　　问题的根本原因是任务A中的周期性自动化进程，它排挤了任务B。处理器利用率的峰值在RMF III中没有显示，因为它们相对一分钟间隔来说太短了。另外，WLM无法进行调整，因为对10秒监控器和更新窗口来说，这些峰值太短暂了。

　　性能规划之战略与策略

　　对于这个问题，有多种解决方案。第一种，调整任务B的优先级，使其与任务A平级。然而，如果它们都以同样的级别运行，那么后到的那个任务就必须得等待了。另一种方案是新添加一个处理器，在所有其它CPU都繁忙时，任务B就可以在新添的处理器中运行了。可能最好的解决方案是给任务B找一个处理器，使其成为该处理器中唯一的“山大王”。这个方案可能不像听起来那么牢靠。如果经理实在很担心这些5到10秒间隔的问题，那么应该鼓励他们花钱以便保护这个任务。

　　这个实例是为了区分战略性性能规划和策略性性能规划。我们还应注意自己的系统，即使它们看起来并不是满负荷运行。这里要告诉大家一条好消息和坏消息。好消息是大型机有一些工具，以供在毫秒级的间隔期获取详细的数据信息。而且，我们还有MIPS可以做长远规划。坏消息是，在如今的业务环境下，我们将不得不花费更多的时间寻找“5秒问题”的根本原因。

　　关于作者：Robert Crawford有24年关于CICS系统项目方面的讲演。他擅长调试和调整应用，他还写了关于COBOL、Assembler和使用的C++以及DLI和DB2。