附加的 Capacity Advisor 发行说明

OVPA 3.86 无法正确处理格林尼治以东的时区

如果从位于格林尼治标准时间以东时区内的系统上对由 OVPA 3.86 收集的数据运行 capovpaextract，则可能会生成异常。该异常将生成一个类似于以下消息的错误消息：

#capovpaextract isc02.jpn.hp.com
Exception received: com.hp.vse.cp.exception.CpInvalidTraceException:
Invalid profile trace for 
workload "isc02.jpn.hp.com": The sample times are not a 
multiple of the sample interval offset from midnight GMT.

解决办法： 导致该问题的缺陷已在 OVPA 4.5 中得以修复。要避免发生该问题，请执行下列操作：

在受管节点上升级至 OVPA 4.5。
使用 VSE 2.5 或更高版本。

重复计算利用率数据

可以将同一个进程包含在两个受监视的工作负荷中。在这种情况下，该进程使用的资源将合计为双重工作负荷，从而导致了重复计算。

可以在 Capacity Advisor 的配置文件查看器中观察到这种重复计算现象。在方案外部查看与在方案内部查看，所得到的系统配置文件图表是不同的。在方案外部显示的数据是系统实际总数，而在方案内部显示的系统数据则是工作负荷总和。重复计算会使方案内部的跟踪数值更高。

解决办法： 定义受监视的工作负荷时要谨慎。

如果通过用户模式定义工作负荷，请确保没有在两个不同的工作负荷中包含同一个指定用户。
如果通过可执行文件定义工作负荷，请确保每个可执行文件仅指定在一个工作负荷中。
混合使用用户和可执行文件两种工作负荷时，需要特别小心。

不过滤不可能的数据

偶而会出现错误的读数。Capacity Advisor 可过滤出小于 0 的利用率数据，但对于所有不太可能或过高的数据则无法过滤出来。这些偏离的读数对平均值或者利用该数据计算出来的 90 分位点值几乎没有影响，但是它们会显著地更改峰值。

解决办法：

在根据峰值数据确定下一步操作之前，请仔细检查该数据。
Capacity Advisor 具有将读取的数据标记为无效的功能。这一点对于消除这些不正确的读数很有用。只要您发现某个读数明显错误，即可将其标记为无效。

从虚拟机首次收集数据期间的警告

首次从 HP Virtual Machine 中收集数据时，根据收集数据的顺序，capcollect 会生成如下所示的警告消息。

Warning: unable to determine the 
    HPVM Host for Guest "guestname"
Valid CPU utilization data is 
    not available.

解决办法： 重新收集数据。这样即可消除该错误。

HP SIM 中以多个时区显示数据

在 HP-SIM 中，有些时间以浏览器使用的时区显示，而其他时间则以 CMS 使用的时区显示。Capacity Advisor 的时间始终以 CMS 使用的时区显示。

解决办法： 请注意 HP SIM 中显示的时间来源，以及它们是以浏览器的时区显示还是以 CMS 时区显示的。

缺省的报告开始与结束时间不始终为午夜

缺省的报告开始与结束时间并非总是像预期那样为午夜。

解决办法： 在创建 Capacity Advisor 利用率报告时，请仔细检查开始时间和结束时间。

Capcollect 报告访问 HP SIM 实例失败

在运行 capcollect 时，将出现以下消息：

Standard Error:
Could not access the HP-SIM instance on this system null

当 capcollect 在一个特定的受管节点上运行，而同时 capcollect 在其他节点上成功运行时，便可能出现此消息。

解决办法： 在 Central Management Server 上执行下列操作：

备份将要被更改的文件：

cp /opt/vse/lbin/capcollect /opt/vse/lbin/capcollect.orig

按如下所示编辑文件 /opt/vse/lbin/capcollet：将靠近文件结尾处的行
$JAVA -client $CLASSNAME "$@"
更改为：
$JAVA -client -Xmx256m $CLASSNAME "$@"

保存 Capacity Advisor 报告 ZIP 文件会使 Internet Explorer 不响应

如果在使用 Internet Explorer 时尝试保存报告 .ZIP 文件，则会出现两个“File Download”弹出窗口，并且 Internet Explorer 会变为无响应。在其他情况下，保存 ZIP 文件之后，用于创建报告的屏幕将无响应。

解决办法（两个“File Download”窗口）： 要进行恢复，请选择一个窗口，该窗口至少部分遮盖了第一个弹出窗口。这样可以启用第二个弹出窗口。在响应了第二个弹出窗口之后，Internet Explorer 即恢复响应。

解决办法（无响应的报告创建屏幕）： 要进行恢复，请单击“Save Report”链接，并取消 Internet Explorer 提示时有关保存该文件的操作。取消保存操作之后，用于创建报告的屏幕即会恢复响应。

方案可以模拟不支持的配置

Capacity Advisor 不会始终检查是否可以在正在分析的系统上实现已定义的方案。例如，虽然不支持在 2 路 VM Host 上运行 4 路虚拟机，但构建这样的方案则是可行的。

解决办法： 使用 Capacity Advisor 来模拟实际的系统和情形。仔细检查方案是否基于可支持的配置。

关闭和重新启动虚拟机时可能会丢失数据

要获得准确的虚拟机利用率数据，需要从虚拟机及其 VM Host 上获取 Utilization Provider 的信息。从运行在虚拟机内的 Utilization Provider 中收集的 CPU 利用率值，不能正确反映真实的 CPU 利用率，但是确实能够提供内存、网络和磁盘的利用率值。要获得准确的虚拟机 CPU 利用率值，应使用 VM Host 上的相应 FSS 分区中的值。这需要在 VM Host 上使虚拟机与其 FSS 分区相匹配。如果关闭虚拟机并重新引导，则重新引导后它可能会在一个与之前不同的 FSS 分区中运行。如果运行 capcollect，则它会指明 FSS 分区当前的虚拟机分配情况，并使用该分配情况将 FSS 分区中的 CPU 利用率数据与正确的虚拟机相关联。为了防止误用为虚拟机记录的 CPU 利用率值，如果虚拟机从一个午夜（以 GMT 时区表示）到下一个午夜这 24 小时期间已重新引导，则不存储重新引导之前的时间段内的所有 CPU 利用率值。

解决办法： 为了最大程度地降低虚拟机利用率数据的差异，应在重新引导虚拟机之前收集虚拟机上的 Capacity Advisor 数据。虚拟机的下一个定期收集操作会填充重新引导后的数据，并保留重新引导前收集的数据。

首次从 VM Host 及其虚拟机中收集数据时，在对最近 30 天内重新引导的任何虚拟机的 CPU 利用率值进行解释时请务必谨慎。在上次重新引导之前的时间段内显示的虚拟机的 CPU 利用率值，可能不适用于当前虚拟机。

创建工作负荷使数据好像消失了一样

Capacity Advisor 整体上从系统收集数据，也从工作负荷进行收集。当没有工作负荷时，在方案中会使用系统整体数据，但是工作负荷数据为首选。有可能存在几个月的系统整体数据，但是不存在今天之前定义的工作负荷的数据。即使工作负荷数据为空，Capacity Advisor 也会尝试使用该数据。

解决办法： 如下例所示，通过 capprofile 导入另一个配置文件的数据。有关此命令的其他信息，请参考 capprofile(1m)。

示例 4-1 修补在添加工作负荷之前获得的数据

假定系统名为“myhost”，其系统数据可追溯到 2005 年 1 月 1 日。在 2005 年 6 月 30 日下午 2 点，添加了名为“existingWL”和“addedWL”的两个工作负荷定义。这时，方案中将不再使用 6 月 30 日之前的六个月的系统数据。

可以通过将该数据复制到一个新的工作负荷中，来利用该数据。通过输入以下命令，将前半年的系统数据修补到“existingWL”工作负荷的数据中：

# /opt/vse/bin/capprofile -x -b20050101 \
-e200506301400 myhost.myco.com > /tmp/sysdata
#/opt/vse/bin/capprofile -i existingWL < /tmp/sysdata

创建工作负荷可能会导致系统从方案中消失

如果出现下列所有情况，则系统在任何 Capacity Advisor 方案中均不可见：

针对该系统收集了 Capacity Advisor 数据。
将该系统添加到 Capacity Advisor 方案中。
在该系统上创建了一个工作负荷，但没有收集任何 Capacity Advisor 数据。

出现这种情况的原因是，系统上有一个未收集数据的工作负荷，并且 Capacity Advisor 不能正确汇总配置文件。如果对该系统进行任何更改，则可能会导致 Edit Scenario 错误。

解决办法： 从系统收集数据。

Move Workload 页面计算出的总数与方案编辑器计算出的总数不同

Move Workload 页面通常根据时间间隔计算其度量值，但是它所采用的时间间隔不同于 Edit Scenario 页面采用的时间间隔。这会使两个页面之间的某些度量值计算结果不同。峰值度量会有明显的差别。

解决办法： 在 Edit Scenario 页面中仔细检查累积的工作负荷。不要将峰值度量用作参考，因为一旦模拟间隔变化，此度量值很容易发生变化。注意读数旁边的星号 ("*")。星号指明模拟间隔期间缺失的数据，它可能会导致利用率值不准确。

Profile Viewer 并始终显示正确的模拟间隔

Profile Viewer 屏幕可以显示按给定的结束日期结束的不同时间间隔下的数据。Edit Scenario 屏幕可以使用按给定的间隔开始或结束的模拟时间间隔。从 Edit Scenario 页面中启动 Profile Viewer 时，可以让 Profile Viewer 显示模拟间隔的数据，这一点是合理的。如果使用一个开始日期来指定模拟间隔，那么启动 Profile Viewer 时会显示错误的间隔。

解决办法： 请使用一个结束日期来定义模拟间隔，或者在每次访问 Profile Viewer 时重新调整日期。将数据向前调整若干天，该天数等于模拟间隔的天数减一。例如，如果 Edit Scenario 页面显示的月份数据开始于 3 月 1 日，则将 Profile Viewer 日期从 3 月 1 日更改为 3 月 31 日。

来自 Capacity Advisor 网络数据的 OVPA 网络数据

有时，从 OVPA 导入的网络数据与 Capacity Advisor 收集的数据不匹配。这种差别似乎与使用自动端口聚合功能有关。

解决办法： 解释从 OVPA 收集的数据的方式与解释由 Capacity Advisor 收集的数据的方式不同。OVPA 数据是系统上所有 LAN 端口的 BYNETIF_IN_BYTE_RATE 和 BYNETIF_OUT_BYTE_RATE 之和。Capacity Advisor 收集系统上每个 LAN 端口传入和传出的字节总数，但是对该数据执行 pstat(2) 命令。

Move Workload 页面上的易于造成误导的注释

在将工作负荷从一个系统移动到另一个系统时，屏幕的底部将出现如下所示的注释：

Note: The Platform CPU Multiplier is less than 1.0 when moving from a 
      slower system to a faster one. The default CPU multiplier is computed 
      from the clock speeds of the source and destination system -- using 
      actual benchmarks will be more precise. The Platform Memory Multiplier 
      should be greater than 1.0 if the application is expected to use more 
      memory on the new platform. Changing versions of an application can 
      affect both of these multipliers.

该时钟速度调整实际上是在后台执行的，时钟速度倍频规定为“1”。

解决办法： 应忽略“The default CPU multiplier is computed from the clock speeds of the source and destination system -- using actual benchmarks will be more precise.”一句。

尝试重新使用主机名将使系统列表中出现“None”

如果删除某个已创建的系统，然后尝试使用相同的名称创建一个 VM Host 类型的新系统，将导致在 VM Host 托管的系统的列表中显示“NONE”。

解决办法： 不要尝试重新使用已从方案中删除的系统的名称。

将 CMS 从 11.11 更新至 11.23 后 Capcollect 会失败

在更新 CMS 过程中的某个步骤有时会在为 Java 插件保留的目录中保留一些“.save”文件。当出现这种情况时，Java 虚拟机将尝试加载这些空文件并失败。这将导致 capcollect、vselicense 和 capprofile 失败，并生成类似如下所示的消息：

 # capcollect
 /opt/vse/lbin//capcollect[33]: could: The specified number is not 
 valid for this command.
 /opt/vse/lbin//capcollect[33]: could: The specified number is not 
 valid for this command.
 Unable to find an installed Java JRE meeting the minimum version 
 requirements.
 This command requires a minimum version of 1.4.2.07
 Unable to find a java executable.

即使 Java 的版本正确也是如此。

解决办法： 删除这些不需要的“.save”文件。最可能出现在系统上的文件是 /opt/java1.4/jre/lib/PA_RISC2.0/plugins/.save。可能需要从与 /opt/java*/jre/lib/*/plugins 匹配的目录中删除“.save”文件。