Configuration Manager網站大小和效能指導方針

  • 發行項

適用於：Configuration Manager (目前的分支)

Configuration Manager在規模和效能方面領先業界。 其他檔涵蓋 支援的最大規模限制 ，以及以最大環境大小執行網站的 硬體指導方針 。 本文提供所有大小環境的補充效能指引。 本指引可協助您更精確地估計部署Configuration Manager所需的硬體。

本文著重于Configuration Manager效能瓶頸的最大參與者：磁片輸入/輸出子系統或 IOPS。

  • 呈現著重于 IOPS 的詳細資料和測試結果
  • 記載如何使用您自己的環境和硬體重現測試
  • 建議各種大小環境的磁片 IOPS 需求

效能測試方法

您可以使用許多獨特的方式來部署Configuration Manager，但請務必瞭解任何調整大小討論中的一些變數。 其中一個變數是 功能間隔，例如清查週期。 另一個變數是系統參考或部署的使用者、軟體部署或其他 物件 數目。 效能測試會將這些變數套用為 負載的一部分。 負載會以一般速率為在不同大小環境中使用生產環境部署的企業客戶產生物件。

注意事項

客戶使用量資料可讓您使用大部分客戶最常見的案例、組態和設定來測試最新分支組建。 本文中的建議是以這些平均值為基礎。 您的體驗可能會根據您的環境大小和設定而有所不同。 一般而言，Configuration Manager在物件和間隔方面需要有共通性。 因為您可以收集系統上的每個檔案，或將迴圈的間隔設定為一分鐘，並不表示您應該這麼做。

下列各節將醒目提示在大型企業測試和模型化處理需求時要使用的一些重要設定和組態。 這些指導方針有助於設定建議硬體大小的基本系統效能預期。

功能間隔設定

大部分測試都應該使用系統中金鑰週期的預設間隔。 例如，硬體清查測試每週會發生一次，其大小大於預設 的 .mof 檔案。 某些週期性功能間隔，特別是硬體和軟體清查週期，可能會對環境的效能特性產生顯著的影響。 為資料收集啟用積極預設間隔的環境，需要以活動增加的直接比例來超大硬體。 例如，假設您有 25，000 個桌面用戶端，而且想要比預設間隔快兩倍收集硬體清查。 從調整網站硬體大小開始，就如同您有 50，000 個用戶端一樣。

物件

測試應該使用大型企業通常會與系統搭配使用的物件 上限平均 值。 一般值是數千個集合和應用程式，這些集合和應用程式會部署到數十萬個使用者或系統。 測試應該在這些限制下同時在系統中 的所有 物件上執行。 許多客戶會使用數個功能，但通常不會在這些上限使用產品的所有功能。 使用所有產品功能進行測試有助於確保全系統最佳效能，並允許緩衝區以取得某些客戶可能使用高於平均值的功能。

負荷

測試也應該在高於標準 平均日 負載時執行，方法是執行模擬，以在系統上產生尖峰使用量需求。 其中一個範例是模擬「週二修補程式」推出，以確保系統可以在尖峰活動這幾天立即傳回更新合規性資料。 另一個範例是在大規模惡意程式碼攻擊期間模擬網站活動，以確保能夠及時通知和回應。 雖然建議大小的已部署機器在任何指定的一天都可能未使用，但更極端的情況需要一些處理緩衝區。

設定

在各種實體、Hyper-V 和 Azure 硬體上執行測試，並混合支援的作業系統和SQL Server版本。 一律驗證所支援組態的最差情況。 一般而言，Hyper-V 和 Azure 在設定方式類似時，會將可比較的效能結果傳回對等的實體硬體。 目前的伺服器作業系統通常具有等於或優於舊版 OS 的效能。 雖然所有支援的平臺都符合最低需求，但通常 Windows 和 SQL Server 等最新版本的支援產品會產生更好的效能。

最大的變化來自使用中的SQL Server版本。 如需SQL Server版本的詳細資訊，請參閱我應該執行哪個版本的SQL Server？。

關鍵效能決定因素

您可以使用不同種類的設定、不同的方式，以及不同的網站大小來測試和測量Configuration Manager效能。 下列設定和物件可能會大幅影響效能。 在您的環境中測試和模型化效能時，請務必加以考慮。

注意

雖然Configuration Manager的幾個層面都有官方最大值或使用者介面限制，可防止過度使用，但超出指導方針可能會對網站的效能造成顯著的負面影響。 超過建議的層級或忽略調整大小指引通常需要較大的硬體，而且在您降低各種物件的頻率或計數之前，可能會使您的環境變得無法維持不變。

硬體清查

若要測試基準效能，請將硬體清查集合設定為每週一次，預設 .mof 檔案大小加上大約 20% 的其他屬性。 請勿啟用所有屬性，並只收集您實際需要的屬性。 在收集屬性時特別注意，例如可用的虛擬記憶體，這些屬性 一律 會隨著 每個 清查週期而變更。 收集這些屬性可能會在每個用戶端的每個清查週期上造成過度變換。

軟體清查

若要測試基準效能，請將軟體清查收集設定為每週一次， 且僅包含產品 詳細資料。 收集許多檔案可能會對清查子系統造成顯著的壓力。 避免指定可能會在許多用戶端上收集數千個檔案的篩選準則，例如 *.exe 或 *.dll 。

集合

基準效能測試可以包含數千個集合，其中包含不同種類的範圍、大小、複雜度和更新設定。 網站效能不是網站上大量集合的直接功能。 效能也是集合查詢複雜度、完整和累加式更新和變更頻率、集合之間的相依性，以及集合中用戶端數目的交叉乘積。

可能的話，請將具有昂貴或複雜動態規則查詢的集合最小化。 對於需要這些規則類型的集合，請設定適當的更新間隔和更新時間，以將集合重新評估對系統的影響降到最低。 例如，在午夜更新，而不是上午 8：00。

啟用集合的累加式更新可確保集合成員資格的快速且及時更新。 但是，即使累加式更新很有效率，它們仍會在系統上載入。 平衡您預期的變更頻率，以及對成員資格進行近乎即時更新的需求。 例如，假設您預期集合成員會有大量變換，但不需要近乎即時的成員資格更新。 相較于啟用累加式更新，它更有效率且會在系統上產生較少的負載，以便在某個間隔內使用排程的完整更新來更新集合。

當您啟用累加式更新時，請減少相同集合上任何排程的完整更新。 它們只是評估的備份方法，因為累加式更新應該讓您的集合成員資格以近乎即時的方式更新。 集合的最佳做法 建議增量更新的總集合數目上限，但如本文所指出，您的體驗可能會因許多因素而有所不同。

只有直接成員資格規則且具有限制集合且未執行累加式更新的集合不需要排程的完整更新。 停用這些集合類型的更新排程，以防止系統上不必要的負載。 如果限制集合使用累加式更新，只有直接成員資格規則的集合可能不會反映最多 24 小時的成員資格更新，或是在排定的重新整理髮生之前。

雖然不是最佳做法，但有些組織會在各種商務程式中建立數百或甚至數千個集合。 如果您使用自動化來建立集合，請務必正確啟用任何必要的累加式更新。 將所有完整更新排程最小化並分散，以避免在單一期間內發生集合評估的熱點。 建立定期清理程式來刪除未使用的集合，特別是當您在一段時間後自動建立不再需要的集合時。

請記住，當您將部署等工作設為目標時，Configuration Manager會為集合中的所有物件建立原則。 透過排程的重新整理或累加式更新，成員資格變更可以為整個系統建立更多工作。 最新的最新分支組建具有適用于 [所有系統] 和 [所有使用者] 集合的特殊原則優化。 以整個企業為目標時，請使用內建集合，而不是這些內建集合的複製品。

若要更深入調查集合效能，請在主控台中檢視集合評估。 如需詳細資訊，請 參閱如何檢視集合評估。

探索方法

針對基準效能測試，請每週執行一次以伺服器為基礎的探索方法，適當地啟用差異探索，讓資料在一周內保持最新狀態。 測試應該會探索與模擬企業大小成正比的物件數量。 活動訊號探索的效能基準測試也應該每週執行一次。

探索資料是全域資料。 常見的效能相關問題在於在階層中設定錯誤的伺服器型探索方法，導致從多個主要月臺重複探索相同的資源。 仔細設定探索方法，以優化與目標服務的通訊，例如 Active Directory 網域控制站，同時避免在多個主要月臺上重複相同的探索範圍。

一般大小調整指導方針

根據上述 效能測試方法，下表提供特定受控用戶端數目的一般 最低 硬體需求指導方針。 這些值應該允許具有指定用戶端數目的大部分用戶端，以足夠快的速度處理物件，以管理指定的網站。 運算能力會每年持續降低價格，而下列部分需求對於新式伺服器硬體組態而言很小。 超過下列指導方針的硬體會針對需要更多處理能力或具有特殊產品使用模式的網站，以比例方式提升效能。

桌面用戶端 網站類型/角色 核心 附注 1 記憶體 (GB) SQL Server記憶體配置附注 2 IOPS：收件匣 附注 3 IOPS：SQL Server附注 3 ) 附注 4所需的儲存空間 (GB
25k 在相同伺服器上具有資料庫月臺角色的主要或 CAS 6 24 65% 600 1700 350
25k 主要或 CAS 4 8 600 100
遠端SQL Server 4 16 70% 1700 250
50k 在相同伺服器上具有資料庫月臺角色的主要或 CAS 8 32 70% 1200 2800 600
50k 主要或 CAS 4 8 1200 200
遠端SQL Server 8 24 70% 2800 400
100k 在相同伺服器上具有資料庫月臺角色的主要或 CAS 12 64 70% 1200 5000 1100
100k 主要或 CAS 6 12 1200 300
遠端SQL Server 12 48 80% 5000 800
150k 在相同伺服器上具有資料庫月臺角色的主要或 CAS 16 96 70% 1800 7400 1600
150k 主要或 CAS 8 16 1800 400
遠端SQL Server 16 72 90% 7400 1200
700k 在相同伺服器上具有資料庫月臺角色的 CAS 20+ 128+ 80% 1800+ 9000+ 5000+
700k Cas 8+ 16+ 1800+ 500+
遠端SQL Server 16+ 96+ 90% 9000+ 4500+
5k 次要月臺 4 8 500 - 200
15k 次要月臺 8 16 500 - 300

一般調整大小指導方針的注意事項

附注 1：核心

Configuration Manager同時執行許多進程，因此需要特定數目的 CPU 核心來處理各種網站大小。 雖然核心每年會變快，但請務必確保特定的最小核心數目以平行方式運作。 一般而言，2015 年之後產生的任何伺服器層級 CPU 都符合資料表中所指定核心的基本效能需求。 Configuration Manager利用建議以外的其他核心。 一旦您有建議的核心下限，請設定 CPU 資源投資的優先順序，以提高現有核心的速度。 請勿新增更多較慢的核心。 例如，Configuration Manager在具有 16 個快速核心的金鑰處理工作上，效能優於 24 個較慢的核心。 此效能假設有足夠的其他系統資源，例如磁片 IOPS。

核心與記憶體之間的關聯性也很重要。 一般而言，每個核心的 RAM 少於 3-4 GB，可減少 SQL Server 上的總處理功能。 當SQL Server與月臺伺服器元件共置時，每個核心都需要更多 RAM。

注意事項

所有測試都會設定機器電源計劃，以允許最大 CPU 耗電量和效能。

附注 2：SQL Server記憶體配置

使用此值可在 SQL Server 的屬性中設定以 MB 為單位的最大伺服器記憶體 () 。 這是伺服器上可用記憶體總量的百分比。

請勿將最小值和最大值設定為相同。 本指引特別適用于您應該允許SQL Server配置的最大記憶體。

附注 3：IOPS：收件匣和 IOPS：SQL

這些值會參考Configuration Manager和SQL Server邏輯磁片磁碟機的 IOPS 需求。 [IOPS： 收件匣]資料行會顯示具有Configuration Manager收件匣目錄之邏輯磁片磁碟機的 IOPS 需求。 [IOPS： SQL] 資料行會顯示各種SQL Server檔案所使用之邏輯磁片磁碟機 () 的總 IOPS 需求。 這些資料行不同，因為兩個磁片磁碟機的格式應該不同。 如需建議SQL Server磁片組態和檔案最佳做法的詳細資訊和範例，包括跨多個磁片區分割檔案的詳細資料，請參閱網站大小和效能常見問題。

這兩個 IOPS 資料行都會使用來自業界標準工具 Diskspd 的資料。 如需複製這些度量的指示，請參閱 如何測量磁片效 能。 一般而言，一旦您符合基本 CPU 和記憶體需求，儲存體子系統對月臺效能的影響就會最大，而這裡的改善可提供最高的投資報酬。

附注 4：需要儲存空間

這些實際值可能與其他記載的建議不同。 我們只提供這些數位作為一般指導方針;個別需求可能會有很大的差異。 在月臺安裝之前，請仔細規劃磁碟空間需求。 假設此儲存體的某些數量在大部分的情況下都會維持為可用的磁碟空間。 您可以在復原案例中使用此緩衝區空間，或針對需要可用磁碟空間進行安裝套件擴充的升級案例使用。 您的網站可能需要更多儲存體來收集大量資料、較長的資料保留期，以及大量的軟體發佈內容。 您也可以將這些專案儲存在個別的較低輸送量磁片區上。

如何測量磁片效能

您可以使用業界標準工具Diskspd，為各種大小Configuration Manager環境所需的 IOPS 提供標準化的建議。 雖然並非詳盡，但下列測試步驟和命令列提供簡單且可重現的方式來估計伺服器的磁片子系統輸送量。 您可以將結果與 一般調整大小指導方針 資料表中的最低建議 IOPS 進行比較。

如需實驗室環境中不同硬體組態類型的測試結果，請參閱 磁片設定範例。 您可以在從頭開始設計新環境的儲存體子系統時，將資料用於粗略的起點。

如何測試磁片 IOPS

  1. 下載 Diskspd 公用程式。

  2. 請確定您至少有 100 GB 的可用磁碟空間。 停用可能會干擾或造成磁片額外負載的任何應用程式，例如目錄、SQL 或 SMSExec 的作用中防毒軟體掃描。

  3. 從提升許可權的命令提示字元執行 Diskspd 。

    針對您想要測試的磁片區，依序執行工具兩次。 64k 大小的第一個測試，隨機寫入作業一分鐘。 這項測試會驗證控制器快取載入和磁碟空間配置，以防磁片區動態擴充。 捨棄第一個測試的結果。 第二個測試應該 緊接 在第一個測試之後，並執行相同的負載五分鐘。

    例如，使用下列特定命令列來測試磁片區 G: 。

    DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d60 -h -L G:\\test\testfile.dat

del G:\\test\testfile.dat

DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d300 -h -L G:\\test\testfile.dat

  4. 檢閱第二個測試的輸出，以尋找每個資料行 I /O 中的 IOPS 總數。 在下列範例中，IOPS 總數為 3929.18。

    Total IO
| thread |  bytes      |  I/Os   |  MB/s  | I/O per s | AvgLat | LatStdDev |
|--------|-------------|---------|--------|-----------|--------|-----------|
|   1    |  9651814400 |  147275 |  30.68 |    490.92 | 16.294 | 10.210    |
|   2    |  9676652544 |  147654 |  30.76 |    492.18 | 16.252 |  9.998    |
|   3    |  9638248448 |  147068 |  30.64 |    490.23 | 16.317 | 10.295    |
|   4    |  9686089728 |  147798 |  30.79 |    492.66 | 16.236 | 10.072    |
|   5    |  9590931456 |  146346 |  30.49 |    487.82 | 16.398 | 10.384    |
|   6    |  9677242368 |  147663 |  30.76 |    492.21 | 16.251 | 10.067    |
|   7    |  9637330944 |  147054 |  30.64 |    490.18 | 16.319 | 10.249    |
|   8    |  9692577792 |  147897 |  30.81 |    492.99 | 16.225 | 10.125    |
| Total: | 77250887680 | 1178755 | 245.57 |   3929.18 | 16.286 | 10.176    |

磁片設定範例

下表顯示如何使用各種測試實驗室組態 測量磁片效 能中執行測試步驟的結果。 從頭開始設計新環境的儲存體子系統時，請將此資料用於 粗略 的起點。

實體機器和 Hyper-V

硬體一律會改善。 預期新一代的硬體和不同的硬體組合，例如 SSD 和 SAN，會超過下列所述的效能。 這些結果是設計伺服器或與硬體廠商討論時要考慮的基本起點。

下表顯示各種測試實驗室組態中各種磁片子系統的測試結果，包括主軸和 SSD 型硬碟。 所有設定都會將磁片格式化為 64k 個叢集，並將其連結至企業級磁碟控制卡。 除了 RAID 陣列磁片計數之外，每個磁片都至少有一個備用磁片。

磁碟類型 磁片計數，不包括 +1 個備用磁片 RAID 測量的 IOPS
15k SAS 2 1 620
15k SAS 4 10 1206
15k SAS 6 10 1751
15k SAS 8 10 2322
15k SAS 10 10 2882
15k SAS 12 10 3476
15k SAS 16 10 4236
15k SAS 20 10 5148
15k SAS 30 10 7398
15k SAS 40 10 9913
SSD SATA 2 1 3300
SSD SATA 4 10 5542
SSD SATA 6 10 7201
SSD SAS 2 1 7539
SSD SAS 4 10 14346
SSD SAS 6 10 15607

下表列出此範例中使用的特定裝置。 此資訊並非任何特定硬體型號或製造商的建議。

磁碟類型 Model RAID 控制器 快取記憶體和設定
15k RPM SAS HD HP EH0300JDYTH Smart Array P822 2 GB、20% 讀取/80% 寫入
SSD SATA ATA MK0200GCTYV Smart Array P420i 1 GB、20% 讀取/80% 寫入
SSD SAS HP MO0800 JEFPB Smart Array P420i 1 GB、20% 讀取/80% 寫入

Azure 機器和磁片效能

Azure 磁片效能取決於數個因素，例如 Azure VM 的大小，以及其使用的磁片數目和類型。 Azure 也會持續新增與下圖不同的新機器類型和磁片速度。 如需Configuration Manager在 Azure 上執行的詳細資訊，以及瞭解 Azure 上磁片 I/O 的其他資訊，請參閱 Azure 上的Configuration Manager常見問題。

所有磁片都會格式化 NTFS 64k 叢集大小，且具有多個磁片的資料列會透過 Windows 磁片管理公用程式設定為等量磁片區。

Azure VM Azure 磁片 磁片計數 可用空間 測量的 IOPS 限制因素
DS2/DS11 P20 1 512 GB 965 Azure VM 大小
DS2/DS11 P20 2 1024 GB 996 Azure VM 大小
DS2/DS11 P30 1 1024 GB 996 Azure VM 大小
DS2/DS11 P30 2 2048 GB 996 Azure VM 大小
DS3/DS12/F4S P20 1 512 GB 1994 Azure VM 大小
DS3/DS12/F4S P20 2 1024 GB 1992 Azure VM 大小
DS3/DS12/F4S P30 1 1024 GB 1993 Azure VM 大小
DS3/DS12/F4S P30 2 2048 GB 1992 Azure VM 大小
DS4/DS13/F8S P20 1 512 GB 2334 P20 磁片
DS4/DS13/F8S P20 2 1024 GB 3984 Azure VM 大小
DS4/DS13/F8S P20 3 1536 GB 3984 Azure VM 大小
DS4/DS13/F8S P30 1 1024 GB 3112 P30 磁片
DS4/DS13/F8S P30 2 2048 GB 3984 Azure VM 大小
DS4/DS13/F8S P30 3 3072 GB 3996 Azure VM 大小
DS5/DS14/F16S P20 1 512 GB 2335 P20 磁片
DS5/DS14/F16S P20 2 1024 GB 4639 P20 磁片
DS5/DS14/F16S P20 3 1536 GB 6913 P20 磁片
DS5/DS14/F16S P20 4 2048 GB 7966 Azure VM 大小
DS5/DS14/F16S P30 1 1024 GB 3112 P30 磁片
DS5/DS14/F16S P30 2 2048 GB 6182 P30 磁片
DS5/DS14/F16S P30 3 3072 GB 7963 Azure VM 大小
DS5/DS14/F16S P30 4 4096 GB 7968 Azure VM 大小
DS15 P30 1 1024 GB 3113 P30 磁片
DS15 P30 2 2048 GB 6184 P30 磁片
DS15 P30 3 3072 GB 9225 P30 磁片
DS15 P30 4 4096 GB 10200 Azure VM 大小

如需目前可用磁片的詳細資訊，請 參閱選取 Azure IaaS VM 的磁片類型。

另請參閱