跳转到主内容

Data ONTAP 中的 CPU 利用率是多少:计划和监控?

Views:
7
Visibility:
Public
Votes:
0
Category:
data-ontap-8
Specialty:
core
Last Updated:

可不使用  

适用于

  • 集群模式 Data ONTAP 8 
  • Data ONTAP 8 7-模式 
  • Data ONTAP 7 及更早版本 

解答

注意:在 ONTAP 中, CPU 利用率只是复杂系统的一部分。请参见此知识库以确定 CPU 利用率是否值得关注

 

每个存储控制器包含一个或多个多核 CPU 。这些物理 CPU 核心是 Data ONTAP 可用于处理工作的主要计算资源。除了 CPU 核心外、 Data ONTAP 还与其他物理硬件(如以太网端口、 FC 端口、磁盘和 NVRAM )进行交互。所有这些物理资源的使用都是以高度优化和并行的方式进行的、要考虑到活动请求、资源可用性以及系统的整体活动级别。由于物理资源之间的交互可能复杂且相互依赖、因此衡量 CPU 繁忙( CPU 利用率)的度量不会随着客户端传入请求的增加而线性增加、也不能单独使用它来衡量系统的整体利用率。也就是说, CPU 资源具有几个独特的特性、在分析整个系统时可以很好地理解这些特性。

此知识库详细介绍了以下内容:

  • CPU 作为计算资源
  • CPU 作为系统性能的衡量标准
  • 如何测量 CPU 利用率 
CPU 作为计算资源:

Data ONTAP 采用粗牙对称多处理( CSMP )设计、将系统功能划分为逻辑处理域。每个逻辑处理域都有一组规则,用于控制如何以及何时在物理 CPU 核心之间调度逻辑 CSMP 域。这些规则旨在确保所有处理都以安全有效的方式进行。

下表介绍了一些常见的逻辑处理域、它们的典型任务、并说明了逻辑域是否可以同时在一个或多个 CPU 核心上运行、以及任何特定的调度规则:

域名

域中的典型任务

CPU 并发性

说明

网络独占

IP 处理、 NFS 协议处理

1

只能同时在单个 CPU 上运行的网络代码

网络免除

IP 处理、 NFS 协议处理( 7- 模式和 cDOT )、 SMB 处理( cDOT )

1 个以上

CPU 的最大数量取决于控制器型号和 Data ONTAP 版本

Network 传统

IP 处理、 NFS 协议处理

1

只能同时在单个 CPU 上运行的网络代码

storage


磁盘的 SCSI 通信

1 个以上

Data ONTAP 8.2.1 之前的并发 1 个 CPU 或少于 6 个 CPU

raid

RAID 子系统

1

 

RAID_免除

RAID 子系统

1 个以上

Data ONTAP 8.2 中引入

xor_ex

RAID 子系统 XOR 奇偶校验处理

1 个以上

在 ONTAP 9.0 中引入

target

SCSI ( FCP/iSCSI )处理

1

 仅限 7- 模式

SSAN_免除

SCSI ( FCP/iSCSI )处理

1 个以上

在集群模式 Data ONTAP 8.2 中引入

Kahuna

序列化的 WAFL 和其他域中没有的任何内容

1

不包括 WAFL_EX (例如, Kahuna 可以在 1 个 CPU 上处于活动状态、 WAFL_EX 可以在 1 个 CPU 以上的 CPU 上处于活动状态、但两者不能同时处于活动状态)

WAFL_EX

并行化 WAFL

1 个以上

与 Kahuna (即 Kahuna 可以在 1 个 CPU 上处于活动状态、 WAFL_EX 可以在 1 个 CPU 以上的 CPU 上处于活动状态、但两者都不能同时处于活动状态)

WAFL_XCleaner

WAFL

1 个以上

 

SM_免除

SnapMirror

1 个以上

 

cifs

SMB 协议处理(仅限 7 模式)

1

仅初始解码;大多数 SMB 处理都发生在 WAFL 中

豁免

常规并行化工作

1 个以上

 

HostOS

由 BSD 层拥有的任务包括 NTP 、环境传感器监控、 ZAPI 处理、 AutoSupport

1 个以上

 


 Data ONTAP 内核计划在物理 CPU 核心上运行逻辑 CSMP 域。计划逻辑是特定 Data ONTAP 版本和硬件平台的独特之处,并经过调整以最大限度地提高整体系统性能。因此,给定逻辑域的并行级别可能会因多种因素而异,其中包括传入工作负载速率、请求的工作类型、 Data ONTAP 操作系统版本等。 

计划行为可能包括:
  • 将大量使用的逻辑域连接到物理 CPU 核心以最大限度地提高缓存效率。
  • 关闭各种负载点的物理 CPU 核心以优化运行队列的处理。 

这些优化可能会导致物理 CPU 核心之间的工作负载平衡不均匀。此行为是按设计进行的、针对每个特定 Data ONTAP 版本和平台组合进行了优化。

CPU 作为系统性能的衡量标准:

如前所述、 CPU 只是 Data ONTAP 可用的物理资源类型之一。在分析系统性能时、务必要从整体角度审视系统。分析瓶颈的一般策略是使用服务指标(协议 / 卷 /LUN 延迟 / 工作负载)和组件指标( CPU 、磁盘 IO 、网络 IO )来提供系统的完整视图并减少错误结论的可能性。

具体看 CPU 资源、工作分为优先级、某些类型的工作被确定为背景或非必要 / 机会。这意味着,当后台工作使用一个或多个 CPU 核心时、它将在请求到达时有效地发挥更高优先级的作用。此外,随着系统负载的增加、处理优化很可能会导致非线性扩展,从而测量物理 CPU 核心利用率和逻辑 CSMP 域利用率。这在复杂的计算系统中是正常的。

以下三种 CPU 瓶颈类型可能是因为 CSMP 模型:
  • 平均 CPU 核心利用率:所有核心的 CPU 核心利用率平均度量达到 100% 。
  • 逻辑域瓶颈:逻辑域达到其并发限制。例如,如果逻辑域的并发性为 1 个 CPU 内核且利用率达到 100% 。
  • 逻辑域之间的交互:某些逻辑域是互斥的、不能与另一个关联的逻辑域同时运行。例如WAFL_ex,表示并行 WAFL 处理、而 Kahuna 则表示串行 WAFL 处理。这两个逻辑域是互斥的、意味着 Kahuna 可以在 1 个 CPU 上处于活动状态、也可以WAFL_ex 在 1 个以上的 CPU 上处于活动状态、但 Kahuna 和WAFL_Ex 两者都不能同时处于活动状态。根据工作量的不同、 Kahuna 可以限制可以执行的工作量WAFL_ex。必须注意的是,这种类型的瓶颈在以前的情况下是一种简单的变化。

注意:如果不达到域瓶颈或平均 CPU 瓶颈,则无法在物理 CPU 核心上产生瓶颈。因此,将物理 CPU 利用率监控作为直接衡量标准并不有效。

注:从 Data ONTAP 8.2.1 开始、表示 CPU 利用率(“sysstat”)的算法已更改,并报告avg_processor_busy并发数为 1 的最大域或最繁忙域。 

如何测量 CPU 利用率?

作为系统整体视图的一部分、您可以使用命令行实时查看 CPU 利用率,方法如下:

集群模式 Data ONTAP 

netapp::> set diag
Warning: These diagnostic commands are for use by NetApp personnel only.
Do you want to continue? {y|n}: y
netapp::*> node run -node netapp-01 sysstat -M 1
ANY1+ ANY2+ ANY3+ ANY4+ ANY5+ ANY6+ ANY7+ ANY8+ ANY9+ ANY10+ ANY11+ ANY12+ ANY13+ ANY14+ ANY15+ ANY16+  AVG 
 100%  100%  100%   99%   98%   96%   94%   91%   86%   81%   76%   70%   64%   57%   48%   37%   81%

CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 CPU12 CPU13 CPU14 CPU15 
 78%  76%  77%  83%  82%  83%  82%  82%  82%  82%   83%   84%   83%   82%   83%   82% 

Nwk_Excl Nwk_Lg Nwk_Exmpt Protocol Cluster Storage Raid Raid_Ex Target Kahuna WAFL_Ex(Kahu)
    3%    2%    450%     0%    0%    49%   2%   136%    0%    4%   511%( 94%) 

WAFL_XClean SM_Exempt Cifs Exempt SSAN_Ex Intr Host  Ops/s   CP
     0%     0%   0%   112%    0%  28%   8%  47111   0%

在此示例中, 16 个核心的平均 CPU 利用率为 81% 。  最繁忙的域在 WAFL 中的免除率为 511 %、网络免除率为 450 %、 RAID 免除率为 136 %、免除率为 112 %。WAFL 在示例间隔中处于活动状态的占 98% 、在串行处理中花费 4% 、在并行处理中花费 94% 。  由于 WAFL 串行处理非常低、因此并行 WAFL 可能会完成更多工作、因此在抽样间隔内处于 98% 活动状态、没有其他性能指标就不会引起关注。整体 CPU 资源越来越少,工作队将排队等待 CPU 、从而潜在地影响客户端延迟。

Data ONTAP 7-模式

netapp> priv set diag
netapp*> sysstat -M 1
ANY1+ ANY2+ ANY3+ ANY4+  AVG  CPU0 CPU1  CPU2  CPU3
93%    80%  36%   15%    56%  38%   32%  82%   72%

Nwk_Excl Nwk_Lg Nwk_Exmpt Protocol Cluster Storage Raid Raid_Ex Target Kahuna
1%         68%    1%       0%      0%      4%     0%  19%      0%    11%

WAFL_Ex(Kahu) WAFL_XClean SM_Exempt Cifs Exempt SSAN_Ex Intr Host Ops/s  CP
80%( 75%)      14%        0%     0%   24%    0%     1%    1%   0    83%

在此示例中,平均 CPU 利用率为 56% 、 Network _Legacy 域(最大并发率为 1 )为 68% 。为了分析 WAFL 瓶颈, Kahuna 的利用率为 11% 、WAFL_Ex总容量为 75% 或 86% 。由于这低于 100% 、因此不会成为瓶颈。但是,如果它接近 100% 、那么如果没有其他贡献绩效指标、它可能仍然不是一个问题。

虽然 Data ONTAP 会公开 CPU (逻辑和物理)利用率,但建议不要将 CPU 利用率作为第一级衡量指标来评估系统的整体性能。相反,建议将与请求的用户工作相关的输入和输出作为第一级衡量指标。

换句话说,建议重点关注正在服务的工作的实际延迟(响应时间)以及根据 IO 请求或字节(吞吐量)处理的操作数量。此性能度量实际上与给定工作负载相关,并抽象化逻辑和物理 CPU 调度变化的复杂性质。

其他信息

不适用