現(xiàn)代 HPC 集群的功能時常通過諸如 StarCD* 或 Fluent* 等軟件提供給最終用戶（StarCD* 或 Fluent* 軟件是計(jì)算流體力學(xué)（CFD）領(lǐng)域中的兩個典型應(yīng)用）。只要一切工作正常進(jìn)行，或至少按預(yù)期進(jìn)行，設(shè)置計(jì)算的工程師和確保集群流暢工作的管理員實(shí)際上都不知道二進(jìn)制包的哪些程序正在繼續(xù)執(zhí)行所有計(jì)算。

但遺憾的是，事情往往不那么順利。此時，問題“什么正在進(jìn)行？”成為回答“我如何解決此問題？”的基礎(chǔ)。如果您無法回答前一個問題，您所做的一切就如同在黑暗中摸索。即使您能夠解決此問題，您仍可能不能夠確切了解修補(bǔ)奏效的原因，也不知此修補(bǔ)是否只是一個權(quán)宜之計(jì)。本文將討論英特爾集群工具，特別是英特爾® 跟蹤采集器、英特爾® 跟蹤分析器和英特爾® MPI 性能指標(biāo)評測，這些工具應(yīng)使在二進(jìn)制黑暗中摸索的您看到一些光明。

客戶訪問時，作者遇到了在千兆位以太網(wǎng)交換機(jī)上運(yùn)行 StarCD* 的 Hewlett-Packard (HP)*/英特爾® 安騰® 2 1.5 GHz 集群問題?？蛻魧ο到y(tǒng)的性能極為不滿，指出它們既不能高效地運(yùn)行簡單的 32 線程工作，也不能重現(xiàn)購買之時產(chǎn)生的性能評測結(jié)果。在拜訪客戶期間，作者很快證實(shí)，客戶的主要問題在于每個節(jié)點(diǎn)的 CPU 利用率，CPU 利用率僅為 60% 左右，而不是常用標(biāo)準(zhǔn) 95-100%

客戶和作者就簡單性能指標(biāo)評測（四百萬個單元，不含知識產(chǎn)權(quán)）迅速達(dá)成一致。令人慶幸的是，性能指標(biāo)評測表明其現(xiàn)場表現(xiàn)相同，這說明是系統(tǒng)問題而非軟件本身的問題。作者和 Hewlett-Packard 證實(shí)，在英特爾或 HP 現(xiàn)場所安裝的類似于英特爾® 安騰® 的系統(tǒng)不會出現(xiàn)此類問題。

由于此類問題與使用的 MPI 實(shí)現(xiàn)無關(guān)，因此作者假定此行為由網(wǎng)絡(luò)硬件中的某個問題引起。下一步將是調(diào)查 StarCD 的通信結(jié)構(gòu)。本文所選擇的工具是英特爾® 跟蹤采集器（ITC）和英特爾® 跟蹤分析器。幸運(yùn)的是，
英特爾公司可提供支持 ITC 的 StarCD 版本。由于 StarCD 的行為僅依賴于數(shù)據(jù)集和程序版本，因此我們可以在任何可用的硬件上運(yùn)行此測試。雖然執(zhí)行時間因硬件而異，但通信結(jié)構(gòu)并不變。此調(diào)查有三個重大發(fā)現(xiàn)：

1. StarCD 執(zhí)行相當(dāng)多的通信調(diào)用——如 本圖所示。即使在 0.1 秒時間幀上，該線程也一直在交換數(shù)據(jù)。

2. 所使用的主要 MPI 功能為alltoall調(diào)用。

3. 雖然在大約 13 個節(jié)點(diǎn)上的負(fù)載均衡的效果并不理想，但它能夠順利運(yùn)行，這樣，集群的工作效率至少應(yīng)能達(dá)到 90%。

上述發(fā)現(xiàn)表明，我們可以很輕松地測試集群上的 MPI 行為，而無需依賴 StarCD 并借助其它依賴關(guān)系。所選擇的工具為英特爾 MPI 性能指標(biāo)評測工具，該工具可自動生成可靠的測量結(jié)果。HP 在其自己的集群上測量最佳執(zhí)行時間，在消息大小為 35 kb 的情況下使用 alltoall 時，得到大約 3µs 的延遲時間。

在客戶現(xiàn)場所進(jìn)行的測量結(jié)果是錯誤的，該結(jié)果表明，性能僅實(shí)現(xiàn)約一半（如圖中的基本結(jié)果所示）。

更改交換機(jī)配置并未獲得真正的改進(jìn)（如圖真正的交換機(jī)結(jié)果所示）。

查看集群中使用的電纜后才獲得了重大突破。所有 63 個節(jié)點(diǎn)均連接到包含 5 個插件的交換機(jī)。用戶通常為一項(xiàng)工作保留 8 個或 16 個節(jié)點(diǎn)（每個節(jié)點(diǎn)使用 2 個 CPU），例如節(jié)點(diǎn) 1 到 16。正如您從布局中所看到的那樣，此配置迫使負(fù)載僅進(jìn)入一兩個插件，因此造成了交換機(jī)的超載。

根據(jù)作者的建議，僅對電纜布局稍做更改，就解決了此問題，并極大提高了集群內(nèi)的響應(yīng)速度（如上圖 帶區(qū)換換機(jī) 所示，請點(diǎn)擊 此處）。

通過更詳細(xì)地分析消息結(jié)構(gòu)，用戶可以發(fā)現(xiàn)哪些大小的消息導(dǎo)致了集群中的大多數(shù)延遲。目前，英特爾® 跟蹤分析器未實(shí)現(xiàn)此類圖表，但其信息可以直接從跟蹤文件中提取。在首先將數(shù)據(jù)轉(zhuǎn)換為 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"
            

第一個條目提供了時間戳，其余的條目都很容易理解。在此案例中，我們處理了從應(yīng)用程序到 MPI_Broadcast 的調(diào)用，從組 0 出發(fā)，經(jīng)線程 1 到 4 個接收器，長度為 4 字節(jié)，持續(xù)時間 499 刻度總數(shù)，最后返回到應(yīng)用程序（第 3 行）。

由于所需數(shù)據(jù)可能因應(yīng)用程序而異，因此必須編寫程序或腳本來解析輸出。

作者分析了以上使用的 StarCD 性能指標(biāo)評測，以便了解 MPI_alltoall 調(diào)用耗費(fèi)的總時間在消息大小上的分布。

此圖表顯示非常小的消息占用了約 40% 的運(yùn)行時間，大小超過 100 kb 的消息占用了另外的 40% 運(yùn)行時間。

此類信息可用于進(jìn)一步優(yōu)化網(wǎng)絡(luò)和交換機(jī)，不過，從此案例中可以看到，同時優(yōu)化非常大和非常小的消息可能極其困難。