第 2 章 已知问题和解决办法

在系统中可能有一个进程与两个受监视的工作负荷相匹配。在这种情况下，该进程使用的资源将合计为双重工作负荷，并重复计算结果。

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

要避免这种情况，在定义受监视的工作负荷时应小心。

受监视的工作负荷的利用率数据每 5 分钟收集一次。对于每 5 分钟的起始和结束时刻都不存在的任何进程，不会收集其数据。这样可能会遗漏某个运行了将近 10 分钟的进程。

如果受监视的工作负荷中的进程运行时间相当长，则这些工作负荷通常会更加精确。对于运行时间短于 5 分钟的进程，不会收集其数据。Capacity Advisor 会随机遗漏运行时间为 0 到 10 分钟的进程（其运行时间不少于 5 分钟）。平均起来，以 5 分钟为间隔来计算每个进程（即，一个 50 分钟的进程会有 10% 计算在内）。

在解释受监视的工作负荷中的结果时，请注意这一问题。

不要定义经常出现短时效进程的受监视工作负荷。如果没有定义任何工作负荷，则 Capacity Advisor 将使用系统工作负荷中的数据。系统工作负荷会计算所有短时效进程。

偶而会出现错误的读数。Capacity Advisor 可过滤出小于 0 的利用率数据，但是对于不太可能的乃至过高的数据则无法过滤出来。

这些偏离的读数对平均值乃至利用该数据计算出来的 90 分位点值没有太大影响，但是它们会使峰值读数相当不准确。

删除并重新安装 VSE 产品会从 CMS 中删除所有与受管系统相关的工作负荷信息，但不会删除受管系统的数据。

创建新工作负荷时，新的工作负荷可能会重新使用某些旧工作负荷的 ID。存储在受管系统中并使用旧工作负荷 ID 的数据，可能会被收集，并与恰好具有相同 ID 的、随机的新工作负荷建立关联。

可以通过使用配置文件编辑器将所有早于重新安装时间的数据标记为无效数据，来纠正此问题。《《HP Integrity Essentials Capacity Advisor 入门》》的有关安装的章节中也说明了此问题。^[1]

也可以在先前定义了工作负荷的受管系统上删除并重新安装“HP-UX Utilization Provider”产品。这样将删除旧数据。Utilization Provider 的 SD 产品名是“utilProvider”。

首次从 HP Virtual Machine 中收集数据时，根据收集数据的顺序，capcollect(1m) 会生成警告。

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

重新收集数据；这样即可清除此错误。

“VM guest”一词在内部用来代表 Virtual Machine 或“VM”。而 Capacity Advisor 则使用“VM guests”一词。

请注意，“VM”和“VM Guest”两个术语可以互换使用。

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

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

缺省时间并非总是像预期那样为午夜。

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

使用 Collect Capacity Advisor Data All 菜单选择，或运行不带参数的 capcollect，会尝试生成可由 HP-SIM 识别的所有系统的列表。如果列表中有大量系统，则进程间请求将超时。

对 All VSE Resources 集合执行 Collect Capacity Advisor Data 操作，可收集 Capacity Advisor 数据。这样，每当一个新系统获得 VSE 的许可后，您不必为收集数据重新定义调度任务。

在将从受管系统中提取的配置文件数据示例存储到 CMS 数据库中时，capcollect 命令不会调整该数据的时间戳。该数据会使用受管系统的系统时钟的时间戳来存储。

因此，如果所有受管系统上的系统时钟与 CMS 是不同步的（例如可通过 NTP 实现同步），则单独系统上的利用率跟踪可能会与绝对时标不匹配。

也就是说，对于在两个受管系统上同时发生的利用率事件，当收集到 CMS 中并加以显示时，可能会看上去像是发生在不同时间一样。

使用时间同步实用程序（如网络时间协议 (NTP)），将受管系统的系统时钟与 CMS 系统都同步为通用的 NTP 服务器源的时间。

如果收集了任何数据，Capcollect 命令会报告数据已收集。如果某天的数据中的部分数据有错误，您就会收到一条成功消息和一条错误消息。

HP-SIM 会在不同的标签上显示 stdout 和 stderr，如果在 stdout 标签上看到一组完整的成功消息，用户就很容易遗漏错误消息。

请务必检查 stderr 标签，确保在收集过程中没有错误。

如果某个系统的内存分配小于需求值，那么代表该系统的“截断的直方图”有时会在它不应显示的时候显示出来。编码假设内存值是整数。因此，如果系统有 3.98 GB 内存，那么此软件会认为只有 3 GB 内存；如果合并的内存值超过 3 GB，则会通过“截断的直方图”指示溢出状态。

在断定系统没有足够的内存来容纳新工作负荷之前，请仔细检查统计图下面的数值。

如果系统或组合系统支持 WBEM 请求，那么有时会报告以下消息：

The system "hostname" is not known 
to HP-SIM.

此消息表示用户输入的主机名无效或不在 HP-SIM 的系统列表中。

如果在命令行上未输入某个系统，而在该系统上报告了此消息，则忽略它。

如果您使用的是 Internet Explorer，并尝试保存报告，则会出现两个 File Download 弹出窗口，这两个窗口都可能会“挂起”，并且无响应。

要进行恢复，请选择一个窗口，该窗口至少部分遮盖了第一个弹出窗口。

Capacity Advisor 不会检查正在分析的系统是否可以实现已定义的方案。例如：虽然不支持在 2 路 VM 主机系统中运行 4 路 VM guest 虚拟机，但 Capacity Advisor 允许您在方案中尝试此操作。

使用 Capacity Advisor 来模拟实际的系统和情形。应根据常识来创建方案以及修改系统或工作负荷属性。

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

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

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

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

通过 capprofile（在 /opt/vse/bin 中）从另一个配置文件中导入数据。有关此命令的其他信息，请参阅 capprofile(1m)。

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

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

可以通过将该数据复制到一个新的工作负荷中，来利用该数据。使用 capprofile(1m) 命令，将前半年的系统数据修补到 existingWL 工作负荷中：

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

如果满足下列条件：

那么，在任何 Capacity Advisor 方案中系统都不再可见，这是因为系统包含未收集数据的工作负荷，Capacity Advisor 无法正确地汇总配置文件。如果对该系统进行任何更改，则可能会出现 Edit Scenario 错误。

在系统中重新收集 Capacity Advisor 数据。

Move Workload 页面通常根据时间间隔计算其度量值，但是它所采用的时间间隔不同于 Edit Scenario 页面采用的时间间隔。这会使两个页面之间的某些度量值计算结果不同。峰值度量可能会相当不精确。

在 Edit Scenario 页面中仔细检查累积的工作负荷。不要将峰值度量用作参考，因为一旦模拟间隔变化，此度量值很容易发生变化。

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

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

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

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

Capacity Advisor 导入 OVPA 数据时采用以千字节为单位的内存单元。OVPA 数据提取 (OVPA extract) 的最新版本在输出内存时以兆字节为单位。此更改发现得较晚，从而无法对 Capacity Advisor 进行更改，使其正确地导入该数据。

有几种办法可解决此问题：

Capovpaextract 的一项功能是，在从系统中导入数据时，通常不需要在命令行中给出完全限定的主机名。即使工作负荷数据在内部是使用完全限定的域名存储的，一般情况下也只需给出主机名即可。如果两个工作负荷都与该主机名匹配，则 capovpaextract 无法导入数据。当工作负荷在系统中用缺省名称定义时，因为 OTHER 工作负荷与系统名称相匹配，则会发生这种情况。如果一个系统的名称是另一个系统名称的前缀，例如“host1”和“host10”，也会发生这种情况。

在这种情况下，错误消息可能没有太大的帮助。消息如下所示：

One of the tool's parameters was 
invalid.An argument value contained 
a prohibited character.Do not specify 
the new line character or any of the 
following characters in an argument:
`;&|(#><

如果在导入数据时有一个主机的名称是另一个主机名称的前缀，请使用完全限定的域名。

如果系统名称还与 OTHER 工作负荷相匹配，可以通过重命名 OTHER 工作负荷来解决此问题。

另一种方法是，直接运行下面的一个命令。此形式可能有所变化，因此，如果某个脚本预计会在产品的将来发行版中使用，则在该脚本中不要使用这种命令形式。

/opt/mx/bin/mxexec \
-t "Import OVPA System Data" \
-h -A "host1.myco.com" -n \
host1.myco.com