现代 HPC 集群的功能时常通过诸如 StarCD* 或 Fluent* 等软件提供给最终用户（StarCD* 或 Fluent* 软件是计算流体力学（CFD）领域中的两个典型应用）。只要一切工作正常进行，或至少按预期进行，设置计算的工程师和确保集群流畅工作的管理员实际上都不知道二进制包的哪些程序正在继续执行所有计算。

但遗憾的是，事情往往不那么顺利。此时，问题“什么正在进行？”成为回答“我如何解决此问题？”的基础。如果您无法回答前一个问题，您所做的一切就如同在黑暗中摸索。即使您能够解决此问题，您仍可能不能够确切了解修补奏效的原因，也不知此修补是否只是一个权宜之计。本文将讨论英特尔集群工具，特别是英特尔® 跟踪采集器、英特尔® 跟踪分析器和英特尔® MPI 性能指标评测，这些工具应使在二进制黑暗中摸索的您看到一些光明。

客户访问时，作者遇到了在千兆位以太网交换机上运行 StarCD* 的 Hewlett-Packard (HP)*/英特尔® 安腾® 2 1.5 GHz 集群问题。客户对系统的性能极为不满，指出它们既不能高效地运行简单的 32 线程工作，也不能重现购买之时产生的性能评测结果。在拜访客户期间，作者很快证实，客户的主要问题在于每个节点的 CPU 利用率，CPU 利用率仅为 60% 左右，而不是常用标准 95-100%

客户和作者就简单性能指标评测（四百万个单元，不含知识产权）迅速达成一致。令人庆幸的是，性能指标评测表明其现场表现相同，这说明是系统问题而非软件本身的问题。作者和 Hewlett-Packard 证实，在英特尔或 HP 现场所安装的类似于英特尔® 安腾® 的系统不会出现此类问题。

由于此类问题与使用的 MPI 实现无关，因此作者假定此行为由网络硬件中的某个问题引起。下一步将是调查 StarCD 的通信结构。本文所选择的工具是英特尔® 跟踪采集器（ITC）和英特尔® 跟踪分析器。幸运的是，
英特尔公司可提供支持 ITC 的 StarCD 版本。由于 StarCD 的行为仅依赖于数据集和程序版本，因此我们可以在任何可用的硬件上运行此测试。虽然执行时间因硬件而异，但通信结构并不变。此调查有三个重大发现：

1. StarCD 执行相当多的通信调用——如 本图所示。即使在 0.1 秒时间帧上，该线程也一直在交换数据。

2. 所使用的主要 MPI 功能为alltoall调用。

3. 虽然在大约 13 个节点上的负载均衡的效果并不理想，但它能够顺利运行，这样，集群的工作效率至少应能达到 90%。

上述发现表明，我们可以很轻松地测试集群上的 MPI 行为，而无需依赖 StarCD 并借助其它依赖关系。所选择的工具为英特尔 MPI 性能指标评测工具，该工具可自动生成可靠的测量结果。HP 在其自己的集群上测量最佳执行时间，在消息大小为 35 kb 的情况下使用 alltoall 时，得到大约 3µs 的延迟时间。

在客户现场所进行的测量结果是错误的，该结果表明，性能仅实现约一半（如图中的基本结果所示）。

更改交换机配置并未获得真正的改进（如图真正的交换机结果所示）。

查看集群中使用的电缆后才获得了重大突破。所有 63 个节点均连接到包含 5 个插件的交换机。用户通常为一项工作保留 8 个或 16 个节点（每个节点使用 2 个 CPU），例如节点 1 到 16。正如您从布局中所看到的那样，此配置迫使负载仅进入一两个插件，因此造成了交换机的超载。

根据作者的建议，仅对电缆布局稍做更改，就解决了此问题，并极大提高了集群内的响应速度（如上图 带区换换机 所示，请点击 此处）。

通过更详细地分析消息结构，用户可以发现哪些大小的消息导致了集群中的大多数延迟。目前，英特尔® 跟踪分析器未实现此类图表，但其信息可以直接从跟踪文件中提取。在首先将数据转换为 ASCII 格式之后，使用 xstftool （该工具随英特尔® 跟踪采集器一同提供）：  #p#page_title#e#

xstftool FILE.stf --dump
            

1998984 EXCHEXT CPU 0:1 DOWNTO "MPI:MPI_Bcast"
1998984 GLOBALOP MPI_Bcast ON 0:1 COM COMM_WORLD(2) ROOT 1 SENT 4 RECVD 0 DURATION 499
1999149 EXCHEXT CPU 0:3 UPTO "Application:User_Code"
            

第一个条目提供了时间戳，其余的条目都很容易理解。在此案例中，我们处理了从应用程序到 MPI_Broadcast 的调用，从组 0 出发，经线程 1 到 4 个接收器，长度为 4 字节，持续时间 499 刻度总数，最后返回到应用程序（第 3 行）。

由于所需数据可能因应用程序而异，因此必须编写程序或脚本来解析输出。

作者分析了以上使用的 StarCD 性能指标评测，以便了解 MPI_alltoall 调用耗费的总时间在消息大小上的分布。

此图表显示非常小的消息占用了约 40% 的运行时间，大小超过 100 kb 的消息占用了另外的 40% 运行时间。

此类信息可用于进一步优化网络和交换机，不过，从此案例中可以看到，同时优化非常大和非常小的消息可能极其困难。