共用方式為

  • 發行項

Service Manager 效能

 

發行︰ 2016年7月

適用於： System Center 2012 SP1 - Service Manager、System Center 2012 R2 Service Manager、System Center 2012 - Service Manager

System Center 2012 – Service Manager 伺服器角色的效能和功能會受到不同因素的影響。 一般來說，對於效能的正面和負面影響在 Service Manager 的三個區域中會最為明顯。

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

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

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

連接器效能

連接器初次同步處理會需要大量的時間。例如，在與 System Center Configuration Manager 進行大型的初次同步處理時將需要 8 到 12 小時。 當連接器初次同步處理時，您可以預期所有 Service Manager 伺服器角色和程序在這段時間內的效能耗損。 這是因為資料會循序輸入 Service Manager 資料庫 (同時也是 Microsoft SQL Server 資料庫) 中。 雖然您無法加快連接器初次同步處理程序的速度，您仍可以規劃初次同步處理以確保同步處理程序能在 Service Manager 進入生產程序之前完成。

完成初次同步處理時，Service Manager 會繼續進行差異的同步處理，這對於效能的影響並不明顯。

工作流程效能

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

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

  • 通常工作流程會在一分鐘之內開始及結束。Service Manager 伺服器角色的工作負載過重時，工作流程將無法如往常一般快速完成。

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

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

自 System Center 2012 – Service Manager 之後，System Center Service Manager 2010 的工作流程效能已獲得長足的改善，因為新的 ManagmentHostKeepAlive 管理組件能提升工作流程處理回應速度，所以幾乎所有工作流程都能在一分鐘之內完成處理。

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

您應提前進行群組和使用者角色的規劃。 您應謹慎建立群組，並且盡可能針對最小的領域建立群組。 此外，您應在一開始便將 Active Directory 網域服務 (AD DS)、System Center Configuration Manager 及 System Center Operations Manager 的資料填入資料庫，隨後再建立群組。

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

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

System_CAPS_ICON_caution.jpg 注意


不當編輯登錄可能會對系統造成嚴重損害。 在變更登錄前，您應先備份電腦上任何重要的資料。

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

  1. 執行 Regedit 並瀏覽至 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2012\Common\。

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

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

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

    System_CAPS_ICON_note.jpg 注意


    對於 System Center 2012 R2 Service Manager，System Center Management 服務已重新命名為 Microsoft Monitoring Agent。

解決方案 2：您可以使用 Windows PowerShell 指令碼將「使用者」等類型的物件新增至使用者角色。 原則上，登入此角色的分析師可存取類型等於「使用者」的所有物件。 如果您使用此方法，就不再需要建立非常大的群組 (「所有使用者」)，同時 Service Manager 也不再需要執行耗時的檢查以決定此群組員。 在 Service Manager 管理伺服器上，您可以執行以下 Windows PowerShell 指令碼，將「使用者」類型新增至「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 會查詢資料庫並讀取大量的資料。 不過，實際上只需要顯示或使用非常少量的擷取資料。

當您在檢視中使用進階物件類型時，如果已定義的檢視發生效能問題，應改為使用一般類型。 或者，您也可以建立您自己的投影類型，其中僅包含作為檢視之基礎的資料。 如需詳細資訊，請參閱 SCSM 工程小組部落格的建立使用相關內容準則 (類型投影) 的檢視：軟體檢視範例部落格文章 (英文) 部落格文章。

Service Manager 資料庫效能

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

  • 您至少應有 8 GB 的 RAM 供裝載 Service Manager 資料庫的管理伺服器之用，以在一般案例中達到可接受的回應時間。

  • 在裝載 Service Manager 資料庫的電腦上至少應有 8 顆 CPU 核心。

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

  • 如果您以較小的空間建立 Service Manager 資料庫，並設定為小型增量的自動成長，可能會對效能造成負面影響。

請參閱 Service Manager 工作輔助文件集 (SM_job_aids.zip) 中包含的可幫助評估資料庫大小的 Service Manager Sizing Helper 工具，並建立大小更接近最終大小的資料庫。 這將可減少資料庫自動成長的時間量以提高效能。

同樣地，您也可以使用其他適用於高效能資料庫的最佳作法。 例如，如果您可以利用高階磁碟子系統的效用，就可以在對應的檔案群組上分割表格群組，然後將其移至不同的實體磁碟機，以發揮效用。

Service Manager 管理伺服器效能

Service Manager 管理伺服器的效能主要會受到使用中的並行 Service Manager 主控台數量所影響。 因為所有的 Service Manager 角色都會與管理伺服器進行互動，因此如果您要規劃大量的並行主控台，則應考慮新增更多的管理伺服器。 您應配備 8 GB 的 RAM 供管理伺服器使用。 假設每個 CPU 核心可處理 10 到 12 個使用中的主控台，每部管理伺服器至少應有 4 顆 CPU 核心。

Service Manager 主控台效能

Service Manager 主控台的效能主要會受到分析師通常開啟的表單數量及檢視所擷取的資料量所影響。 在安裝 Service Manager 主控台的電腦上至少應有 4 GB 的 RAM。 如果您的檢視會擷取大量的資料，則您將需要額外的 RAM。 在安裝 Service Manager 主控台的電腦上至少應配備一顆四核心 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 工作輔助文件集 (SM_job_aids.zip) 中包含的 Service Manager Sizing Helper 工具，以評估資料庫大小並建立大小更接近最終大小的資料庫，這麼做將可減少資料庫必須自動成長的次數，而對效能有所幫助。

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

Service Manager 資料倉儲伺服器效能

資料倉儲伺服器的效能會受到登錄至資料倉儲的 Service Manager 管理伺服器數量、部署的大小及資料來源的數量所影響。 資料倉儲伺服器上通常應至少有 8 GB 的 RAM。 不過，如果您在進階部署案例 (有多部 Service Manager 管理伺服器會將資料插入資料倉儲中) 中額外配置記憶體，將可發揮更大的效用。 如果您必須取得效能間的平衡，執行 SQL Server 之電腦的記憶體應置於最高的優先順序。 您至少應有 8 顆 CPU 核心，以避免發生效能問題。

自助服務入口網站效能

自助入口網站的設計主要是用於快速存取事件和服務要求歸檔。 它並不適用於同時處理數千名的使用者。

自助入口網站的效能測試著重於「星期日早晨」案例。這主要是確保在星期一早上，數千名的使用者都能在 5 到 10 分鐘的時間內完成登入並開啟事件，而且達到可接受的回應時間 (低於 4 到 5 秒)。 此目標是透過本文件中的最低硬體建議值所達成。

服務等級目標效能

Service Manager支援的服務等級目標並沒有明確的數量。 例如，對於事件數量普遍較少的組織來說，它能支援的服務等級目標可能會比本身具備的能力來得多。 然而，大量的事件則必定會衍生服務等級目標減少的結果，或需要適當擴充額外的硬體和軟體。 在一般的 50,000 電腦 Service Manager 設定中，我們建議您建立五個以內的服務等級目標。 您也許可以建立更多服務等級目標， 不過由於組織的情況不盡相同，Microsoft 無法針對服務等級目標上限擬定明確的建議數量。 如果您的部署設定因服務等級目標的數量而導致效能不彰，我們建議您使用本指南部署案例的設定一節中下一個規模較大的部署案例來進行擴充。