本文件已封存並已停止維護。

Service Manager 效能

更新日期: 2010年12月

適用於: System Center Service Manager 2010

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

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

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

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

連接器效能

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

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

工作流程效能

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

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

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

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

如果您計劃建立大量的工作流程,其中一個可協助改善效能的解決方案就是使用隨附於 Service Manager 發行媒體中的 media.ManagmentHostKeepAlive 管理組件。

  • 您需要手動將兩個檔案從來源目錄複製到 Service Manager 安裝目錄中,然後匯入管理組件檔案。

  • 匯入這些管理組件檔案可大幅增加工作流程的處理回應速度,其中幾乎所有工作流程的處理都可在 1 分鐘之內完成。

  • 不過,匯入此管理組件可能會讓工作流程處理具有較高的優先順序,並在某些情況中會導致 Service Manager 主控台回應的速度變慢,因此您必須在生產環境進行部署之前測試它所造成的影響。

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

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

解決方案 1:您可以修改登錄機碼以手動指定 Service Manager 檢查群組變更的頻率。例如,如果您將群組檢查頻率從 30 秒變更為 10 分鐘,將可大幅提高效能。

Caution注意
不正確編輯登錄可能會造成系統嚴重的損壞。在變更登錄之前,您應該先備份電腦上任何重要的資料。

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

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

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

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

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

解決方案 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 Engineering 團隊部落格上的Creating Views That Use Related Property Criteria (Type Projections): Software Views Example (建立使用相關屬性準則的檢視 (一般投影):軟體檢視範例) 部落格文章 (http://go.microsoft.com/fwlink/?LinkId=184819) 部落格項目。

Service Manager 資料庫效能

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

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

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

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

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

請參閱包含在 Service Manager job aids (Service Manager 工作輔助) 文件集 (http://go.microsoft.com/fwlink/?LinkId=186291) 中的 Service Manager Sizing Helper 工具,以協助您評估資料庫的大小並建立最接近最終大小的資料庫,這將可減少資料庫自動成長的時間量以提高效能。

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

Service Manager 管理伺服器效能

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

Service Manager 主控台效能

Service Manager 主控台的效能主要會受到分析師通常開啟的表單數量及檢視所擷取的資料量所影響。在安裝 Service Manager 主控台的電腦上至少應有 2 GB 的 RAM。如果您的檢視會擷取大量的資料,則您將需要額外的 RAM。在安裝 Service Manager 主控台的電腦上至少應配備一顆雙核心 CPU。由於 Service Manager 主控台為一般使用者應用程式,因此,當您察覺 Service Manager 主控台大量快取記憶體中的資訊而造成過度的資源耗用,使得整體記憶體的使用量增加時,建議您重新啟動應用程式。

Service Manager 資料倉儲資料庫效能

資料倉儲的效能會受到各種因素的直接影響,包括並行 Service Manager 管理伺服器的資料傳送量、儲存的資料或保留期間的資料數量、資料變更率,以及 ETL 頻率等。儲存在資料倉儲中的資料數量會隨著時間不斷增加。確定您是否已封存不需要的資料是相當重要的。此外,您應將記錄檔和資料檔分別存放於個別的實體磁碟中,以達到更佳的效能。同樣地,您可以將 tempdb 置於其他資料庫磁碟機以外的不同實體磁碟上,以達到更佳的輸送量。最後,您可以將三種不同的資料庫置於對應的實體磁碟上,以發揮效用。如果可行,請使用 RAID 1+0 磁碟系統來裝載資料倉儲。在安裝資料倉儲資料庫的電腦上通常至少應有 8 GB 的 RAM。如果在裝載資料倉儲的 SQL Server 上能有更多的記憶體,將可發揮更大的效用。如果 Datamart 和儲存機制資料庫位於相同伺服器上,則效用會更為顯著。不過,如果您只有 4,000 部或更少的電腦,則 4 GB 已經足夠。在安裝資料倉儲資料庫的電腦上至少應配備 8 顆 CPU 核心。額外的核心對於 ETL 和報表效能將會很有幫助。

如果您以較小的空間建立系統中所有的資料庫,並設定為小型增量的自動成長,可能會對效能造成負面影響。請參閱包含在 Service Manager job aids (Service Manager 工作輔助) 文件集 (http://go.microsoft.com/fwlink/?LinkId=186291) 中的 Service Manager Sizing Helper 工具,以評估資料庫的大小並建立最接近最終大小的資料庫,這將可減少資料庫自動成長的時間量以提高效能。

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

Service Manager 資料倉儲伺服器效能

資料倉儲伺服器的效能會受到登錄至資料倉儲的 Service Manager 管理伺服器數量,以及部署的大小所影響。資料倉儲伺服器上通常應至少有 4 GB 的 RAM。不過,如果您在進階部署案例 (其中有多部 Service Manager 管理伺服器會將資料插入資料倉儲中) 中額外配置 8 GB 的 RAM,將可發揮更大的效用。如果您必須取得效能間的平衡,SQL Server 的記憶體應置於最高的優先順序。您至少應有 4 顆 CPU 核心,以避免發生效能問題。資料倉儲伺服器大部分處於無狀態模式,而且不太可能引起 I/O 問題,因此它通常不會是效能問題的主要原因。

自助服務入口網站效能

自助入口網站的設計主要是用於快速存取事件歸檔和軟體自助服務佈建。它並不適用於同時處理數千名的使用者。關於自助入口網站的詳細效能指南將於完成之後發佈。

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

這些資訊是否對您有所幫助?請將您對於 System Center Service Manager 文件的建議和意見傳送至 scsmdocs@microsoft.com。
顯示: