System Center - Service Manager 效能

重要

此版本的 Service Manager 已終止支援。 建議您升級至 Service Manager 2022。

System Center 的效能 - Service Manager 伺服器角色和功能會受到不同因素的影響。 一般而言，有三個區域在 Service Manager 中，正面和負面效能最明顯：

• Service Manager 主控台回應性。 這是您在主控台中採取某些動作到完成為止所需的時間長度。

• 連接器的資料插入時間。 這是連接器同步處理時，Service Manager 匯入資料所需的時間。

• 工作流程完成時間。 這是工作流程自動套用某些動作所需要的時間長度。

連接器效能

連接器初始同步處理可能需要很長的時間;例如，使用 Configuration Manager 進行大型初始同步處理的 8 到 12 小時。 當連接器一開始同步處理時，您可能會預期在這段時間內，所有 Service Manager 伺服器角色和處理程式的效能都會受到影響。 這是因為數據會循序插入 Service Manager 資料庫中，這是 Microsoft SQL Server 資料庫。 雖然您無法暫停連接器的初始同步處理程式，但您可以規劃初始同步處理，並確保同步處理程式在 Service Manager 進入生產環境之前順利完成。

初始同步處理完成時，Service Manager 繼續同步處理差異，這不會影響效能。

工作流程效能

工作流程是一種自動產生的程序， 其中包括傳送電子郵件通知、變更要求啟動的下一個步驟，以及自動套用範本等。

工作流程的效能考量包括下列各項：

• 通常工作流程會在一分鐘之內開始及結束。 當 Service Manager 伺服器角色在繁重的工作負載下時，工作流程不會像平常一樣快速完成。

• 此外，建立新的工作流程 (例如新的通知訂閱) 時，將會增加系統的額外負載。 隨著您建立的新工作流程數量不斷增加，執行每個工作流程所需要的時間也會隨之增加。

系統的負載過重時，舉例來說，如果已建立大量的新事件，且每個事件都產生許多工作流程時，可能會對效能造成負面影響。

群組、佇列和使用者角色對效能的影響

您應提前進行群組和使用者角色的規劃。 您應謹慎建立群組，並且盡可能針對最小的領域建立群組。 然後，在建立群組之前，您應該先使用來自 Active Directory 網域服務 (AD DS) 、Configuration Manager 和 System Center Operations Manager 的數據填入資料庫。

通常，系統管理員會建立群組，以確保使用者只能存取指定的群組。 例如，在一個特定案例中您可能會建立事件的子集，例如會影響人力資源專員所使用之電腦的事件。 在此案例中，您可能只想讓特定人員檢視或修改敏感性伺服器的群組。 然後，您將需要建立一個供所有使用者存取的群組，以及一個供敏感性電腦存取的群組，然後確定安全性角色可同時存取「所有使用者」和「敏感性伺服器」群組。 當然，建立包含所有使用者的群組會導致效能影響，因為 Service Manager 經常檢查以判斷群組是否有變更。 這個檢查預設每隔 30 秒執行一次。 針對大型群組，檢查變更會在系統上建立大量負載，而且可能會大幅降低響應時間。

解決方案 1：您可以修改登錄機碼，手動指定 Service Manager 檢查群組變更的頻率。 例如，如果您將群組檢查頻率從 30 秒變更為 10 分鐘，將可大幅提高效能。 不過，佇列和服務層級目標是特殊類型的群組，其使用相同的群組計算輪詢間隔。 因此，增加輪詢間隔的值會導致佇列和服務等級目標計算的時間較長。

警告

不正確地編輯登錄可能會對系統造成嚴重的損害。 變更登錄之前，您應該先備份電腦所有的重要資料。

若要手動指定群組變更檢查間隔

1. 執行 Regedit，然後流覽至 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\。

2. 建立一個名為 GroupCalcPollingIntervalMilliseconds的新 DWORD 值。

3. 針對該值，指定以毫秒為單位的間隔。 產生的結果會乘以 6。 例如，若要將間隔設定為10分鐘，請輸入600000。

4. 重新啟動 System Center Management 服務。

解決方案 2：您可以使用 Windows PowerShell 腳稿，將類型的物件新增至使用者角色，例如「使用者」。 基本上，登入此角色的分析師可以存取類型等於 「User」 的所有物件。 如果您使用這個方法，就不需要大型群組 (「所有使用者」) ，以及 Service Manager 執行的昂貴檢查來判斷此群組成員資格。 在 Service Manager 管理伺服器上，您可以執行下列 Windows PowerShell 腳本，將 “user” 類型新增至角色 “RoleName”。 您必須修改環境的此範例腳本。

執行 Windows PowerShell 指令碼將物件新增至使用者角色

• 視需要修改以下指令碼，然後加以執行：

#  
# Insert a "type" scope in a role  
# Syntax:  
#   AddTypeToRoleScope -server "put_server_name_here" -RoleName "put display name of the role here" -TypeToAdd "put display name of the type to add to scope here"  
#  
# Note:  This is a simple demonstration script without error checking.   
#   

# set script parameter defaults  
param ([String]$Server = "localhost", [String]$RoleName="My Analyst Role", [String]$TypeToAdd="User")  

$a = [reflection.assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.Core")  

$m = new-object Microsoft.EnterpriseManagement.EnterpriseManagementGroup $Server   

# Get Type object  
#   Note:  If you need to get a list of all available classes related to (for example) "User",   use this command:  
#               $m.EntityTypes.GetClasses() | ?{ $_.Name -like '*user*'} | %{ $_.Name}  
#  
$type = $m.EntityTypes.GetClasses() | ?{ $_.DisplayName -eq $TypeToAdd}  

# Get role object, and insert the type GUID into scope  
$role = $m.Security.GetUserRoles()  | ?{ $_.DisplayName -eq $RoleName}  
$role.Scope.Objects.Add($type.Id)     
$role.Update()  

#   
# Get the value from the database again and validate it is there  
if ( $role.scope.objects.Contains($type.Id) ) {  
    write-host *** Successfully set the scope for role `" $role.DisplayName`" and it now contains all instances of $type.DisplayName `( $type.Name `)  
} else {  
    write-host "There was an error trying to insert the scope into the role."  
}  

檢視效能

當您建立檢視時，請儘可能規劃在系統中使用「一般」類別。 例如，事件管理的大部分物件類別都有兩種類型：「一般」和「進階」。 一般物件類型包含項目相關資料的小型子集簡易參照。 進階類型則包含許多項目相關資料的複雜參照。 一般類型為簡易投影，進階類型為複雜投影。 大部分進階物件類型都用來填入您通常不想在檢視中顯示的表單中填入不同的欄位。 每當您根據進階物件類型和開啟檢視時建立檢視時，Service Manager 查詢資料庫並讀取大量數據。 不過，幾乎不會顯示或使用擷取的數據。

如果您在檢視中使用進階物件類型時所定義的檢視遇到效能問題，請切換至使用一般類型。 或者，您可以建立自己的投影類型，只包含您需要根據檢視的數據。

Service Manager 資料庫效能

Service Manager 資料庫的效能會受到各種因素的影響，包括讀取或寫入數據的並行 Service Manager 控制台數目、群組變更檢查間隔，以及連接器插入的數據。 本文件將提供詳細的資訊。 以下為一些重點：

• 針對裝載 Service Manager 資料庫的管理伺服器，您至少應有 8 GB (GB 的 RAM) ，以便在一般案例中擁有可接受的回應時間。

• 在裝載 Service Manager 資料庫的計算機上，您應該至少有 8 個 CPU 核心。

• 您應盡可能地將記錄檔和資料檔分別存放於個別的實體磁碟中，以達到更佳的資料庫效能。 您可以將 tempdb 移至與 Service Manager 資料庫不同的實體 RAID 磁碟驅動器，以達到進一步的優點。 如果可行，請使用 RAID 1+0 磁碟系統來裝載 Service Manager 資料庫。

• 如果 Service Manager 資料庫是以較小的大小建立，而且其設定為自動成長，特別是以較小的增量建立，效能可能會受到負面影響。

請參閱 Service Manager 工作輔助檔集 (SM_job_aids.zip) 中包含的 Service Manager 重設大小協助程式工具，以取得評估資料庫大小的說明，以及建立大小較接近最終大小的資料庫。 這可藉由減少資料庫自動成長的次數來協助效能。

同樣地，高效能資料庫的所有其他最佳做法也適用於。 例如，如果您可以利用較佳的磁碟子系統，您可以受益於分割個別檔案群組上的數據表群組，並將其移至不同的實體磁碟驅動器。

Service Manager 管理伺服器效能

Service Manager 管理伺服器的效能主要受到作用中並行 Service Manager 主控台的數目影響。 由於所有 Service Manager 角色都會與管理伺服器互動，因此如果您打算擁有大量的並行控制台，請考慮新增其他管理伺服器。 您應配備 8 GB 的 RAM 供管理伺服器使用。 假設每個管理伺服器至少有 4 個 CPU 核心，假設每個 CPU 核心有 10 到 12 個作用中的控制台。

Service Manager 主控台效能

Service Manager 主控台的效能主要受到分析師通常已開啟的窗體數目和檢視所擷取的數據量影響。 在安裝 Service Manager 主控台的電腦上，您應該會有 4 GB 的 RAM。 如果您有擷取大量數據的檢視，則需要額外的 RAM。 安裝 Service Manager 主控台的電腦至少應有 4 核心 CPU。 因為 Service Manager 主控台是使用者應用程式，所以如果您看到過度耗用資源，建議您重新啟動它。 Service Manager 主控台會積極快取記憶體中的資訊，這可能會導致整體記憶體使用量。

Service Manager 數據倉儲資料庫效能

數據倉儲的效能會受到各種因素直接影響，包括並行 Service Manager 管理伺服器傳送數據、儲存的數據量或數據保留期間、數據變更率，以及擷取、轉換和載入 (ETL) 頻率。 儲存在資料倉儲中的資料數量會隨著時間不斷增加。 確定您是否已封存不需要的資料是相當重要的。 影響資料倉儲效能的另一個因素是 ETL 程序的 BatchSize 設定。

您可以將記錄檔和資料檔分別存放於個別的實體磁碟中，以達到更佳的效能。 不過，應避免將多個記錄檔放置在一個磁碟中。 同樣地，您可以將 tempdb 置於其他資料庫磁碟機以外的不同實體磁碟上，以達到更佳的輸送量。 最後，您還可以將不同的資料庫置於對應的實體磁碟上，以發揮效用。 如果可行，請使用 RAID 1+0 磁碟系統來裝載資料倉儲。 安裝資料倉儲資料庫的電腦上通常至少應有 8 GB 的 RAM。 如果您有來自 Operations Manager 或 Configuration Manager 的其他數據倉儲數據源，您應該增加資料庫的 RAM 數量。 如果在裝載資料倉儲的 SQL Server 上能有更多的記憶體，將可發揮更大的效用；如果 Datamart 和儲存機制資料庫位於相同伺服器上，效用會更為顯著。 不過，如果您在部署拓撲中有 4,000 部或更少的計算機，則 4 GB 就已足夠。 在安裝資料倉儲資料庫的電腦上至少應配備 8 顆 CPU 核心。 額外的核心對於 ETL 和報表效能將會很有幫助。

如果您以較小的空間建立系統中所有的資料庫，並設定為小型增量的自動成長，可能會對效能造成負面影響。 請參閱 Service Manager 重設大小協助程式工具，此工具包含在 Service Manager 作業輔助檔集 (SM_job_aids.zip) ，以評估資料庫的大小，並建立大小接近最終大小的資料庫，藉此減少資料庫必須自動成長的次數來協助效能。

Service Manager 包含檔案群組的內建支援。 您可以將檔案群組放置在不同的硬碟中，以發揮效用。 如需檔案群組最佳做法的詳細資訊，請參閱 SQL Server 檔。

Service Manager 數據倉儲伺服器效能

數據倉儲伺服器的效能會受到註冊至數據倉儲的 Service Manager 管理伺服器數目、部署大小和數據源數目的影響。 資料倉儲伺服器上通常應至少有 8 GB 的 RAM。 不過，對於進階部署案例，效能將會受益，其中多個 Service Manager 管理伺服器將數據插入數據倉儲。 如果您必須取得效能間的平衡，執行 SQL Server 之電腦的記憶體應置於最高的優先順序。 您至少應有 8 顆 CPU 核心，以避免發生效能問題。

自助入口網站效能

Self-Service 入口網站是專為輕鬆存取事件和服務要求提出而設計。 它並非設計來同時處理數千位使用者。

Self-Service 入口網站的效能測試特別著重於一般「星期一上午」案例，以確保在星期一上午數百位使用者可以在 5 到 10 分鐘內登入，並開啟可接受 (小於 4 到 5 秒) 回應時間的事件。 此目標是透過本文件中的最低硬體建議值所達成。

服務等級目標效能

Service Manager 支援的服務層級目標沒有特定數目。 例如，對於事件數量普遍較少的組織來說，它能支援的服務等級目標可能會比本身具備的能力來得多。 然而，大量的事件則必定會衍生服務等級目標減少的結果，或需要適當擴充額外的硬體和軟體。 建議您針對一般 50,000 部電腦 Service Manager 設定建立五個以上的服務等級目標。 您也許可以建立更多服務等級目標， 不過，由於條件與組織不同，因此 Microsoft 無法針對您不應超過的服務等級目標數目提供具體建議。 如果您的部署設定因服務等級目標數目而效能不佳，建議您使用下一個較大的部署案例相應放大，如本指南的部署 案例 設定一文中所述。

下一步

• 若要瞭解 Service Manager 部署案例的硬體和軟體組態，請檢閱建議的部署拓撲案例。