針對 System Center Operations Manager 中的灰色代理程式狀態進行疑難排解
本文說明如何針對 System Center Operations Manager （OpsMgr） 中的代理程式、管理伺服器或網關無法使用或 呈現灰色 的問題進行疑難解答。
原始產品版本： Microsoft System Center 2012 Operations Manager
原始 KB 編號： 2288515
代理程式、管理伺服器或網關可以具有下列其中一種狀態，如 [監視] 窗格中代理程式名稱和圖示的色彩所指示。
| 州/省 | 外觀 | 描述 |
|---|---|---|
| Healthy | 綠色的核取記號 | 代理程式或 Management 伺服器正常執行。 |
| 重大 | 紅色複選標記 | 代理程式或 Management 伺服器上發生問題。 |
| Unknown | 灰色代理程式名稱，灰色複選標記 | Management 伺服器上正在監視受監控電腦健全狀況服務的健全狀況服務監看員無法再從代理程式接收活動訊號。 健全狀況服務監看員先前已接收活動訊號且狀態報告為狀況良好。 這也表示管理伺服器不會再收到來自代理程式的任何資訊。 如果執行代理程式的電腦未執行或發生連線問題，就可能發生此問題。 |
| Unknown | 綠色圓形，無複選標記 | 探索到項目的狀態未知。 此特定探索到的項目沒有可用的監視器。 |
灰色狀態的原因
代理程式、Management 伺服器或閘道可能因為下列任何原因而無法使用：
- 活動訊號失敗
- 無效的組態
- 系統工作流程失敗
- Operations Manager 資料庫或資料倉儲效能問題
- Management 伺服器或閘道伺服器效能問題
- 網路或驗證問題
- 健全狀況服務未在執行
問題範圍
開始針對代理程式呈現灰色問題進行疑難解答之前，您應該先瞭解 Operations Manager 拓撲，然後定義問題的範圍。 下列問題可協助您定義問題的範圍：
- 有多少代理程式受到影響？
- 代理程式是否在相同的網路區段中遇到問題？
- 代理程式是否向相同的管理伺服器報告？
- 代理程式進入並維持灰色狀態的頻率為何？
- 您通常如何從這種情況中復原（例如，重新啟動代理程式健康情況服務、清除快取、依賴自動復原）？
- 這些代理程式是否產生活動訊號失敗警示？
- 此問題是否發生在一天的特定時間？
- 如果您將這些代理程式故障轉移到另一部管理伺服器或閘道，此問題是否會持續發生？
- 此問題何時開始發生?
- 代理程式、管理伺服器或閘道或管理群組是否有任何變更？
- 受影響的代理程式是否為 Windows 叢集系統？
- 健全狀況服務 狀態資料夾是否排除在防毒掃描之外？
疑難排解策略
您的疑難解答策略會根據哪個元件處於非使用中狀態、該元件落在拓撲內的位置，以及問題有多普遍。 考慮下列條件：
- 如果向特定管理伺服器或閘道回報的代理程式無法使用，疑難解答應該從管理伺服器或閘道層級開始。
- 如果向特定管理伺服器回報的閘道無法使用，疑難解答應該從管理伺服器層級開始。
- 針對無代理程式系統、網路裝置和 Unix 和 Linux 伺服器，疑難解答應該從監視這些物件的代理程式、管理伺服器或網關開始。
- 疑難解答通常會從位於無法使用元件上方的層級開始。
案例 1
只有少數代理程式會受到問題的影響。 這些代理程式會向不同的管理伺服器報告。 代理程式會定期無法使用。 雖然您可以清除代理程式快取以協助暫時解決問題，但問題會在幾天後重新發生。
案例 1 的解決方案
若要解決此問題，請遵循下列步驟：
- 將適當的 Hotfix 套用至受影響的作業系統。
- 從防病毒軟體掃描中排除代理程式快取。 如需詳細資訊，請參閱 與 Operations Manager 相關的防毒排除建議。
- 停止健康情況服務。
- 清除代理程式快取。
- 啟動健康情況服務。
案例 2
只有少數代理程式會受到問題的影響。 這些代理程式會向不同的管理伺服器報告。 代理程式會持續保持非使用中狀態。 雖然您可以清除代理程式快取，但這無法解決問題。
案例 2 的解決方案
若要解決此問題，請遵循下列步驟：
判斷健康情況服務是否已開啟，且目前正在管理伺服器或閘道上執行。 如果健全狀況服務已停止回應，請在服務停止回應模式中產生ADPlus傾印，以協助判斷問題的原因。 如需詳細資訊，請參閱 如何使用 ADPlus.vbs 針對「停止回應」和「當機」進行疑難解答
檢查代理程式上的 Operations Manager 事件記錄檔，以找出下列任何事件：
事件識別碼：1102
事件來源：HealthService
事件描述：
無法初始化標識碼為「%2」 實例 「%3」 的規則/監視器「%4」 ，而且不會載入。 管理群組 "%1"事件識別碼：1103
事件來源：HealthService
事件描述：
摘要：%2 規則/監視器失敗並卸除，其中 %3 已達到防止自動重載的失敗限制。 管理群組 "%1"。 這只是摘要事件，請參閱其他具有已卸載規則/監視器描述的事件。事件識別碼：1104
事件來源：HealthService
事件描述：
工作流程 %4 中的 RunAs 設定檔，無法解析標識碼為“%2” 的實例%3。 系統將不會載入工作流程。 管理群組 "%1"事件識別碼：1105
事件來源：HealthService
事件描述：
工作流程 %4 中 RunAs 設定檔的類型不符，針對標識碼為“%2” 的實例 %3 執行。 系統將不會載入工作流程。 管理群組 "%1"事件識別碼：1106
事件來源：HealthService
事件描述：
無法在工作流程 「%4」 中存取純文字 RunAs 配置檔，其為標識碼為「%2」 的實例 「%3」。 系統將不會載入工作流程。 管理群組 "%1"事件識別碼：1107
事件來源：HealthService
事件描述：
未定義標識碼為「%2」 的實體%3 工作流程%4 中的 RunAs 設定檔。 系統將不會載入工作流程。 請建立帳戶與設定檔的關聯。 管理群組 "%1"事件識別碼：1108
事件來源：HealthService
事件描述：
無法解析執行身分設定檔 %7 中指定的帳戶。 具體而言，此帳戶會用於安全參考覆寫 "%6"。 %n%n 發生這種狀況的原因可能是該帳戶未設定為散發至此電腦。 若要解決這個問題，您必須開啟以下指定的執行身分設定檔、依照指定的 SSID 找出帳戶項目，然後選擇依適當情況將帳戶散發至此電腦，或是變更設定檔中的設定，讓目標物件不要使用指定的帳戶。 %n%n管理群組：%1 %n執行身分設定檔：%7 %nSecureReferenceOverride 名稱：%6 %nSecureReferenceOverride 識別碼：%4 %n物件名稱：%3 %n物件識別碼：%2 %n帳戶 SSID：%5事件標識碼：4000
事件來源：HealthService
事件描述：
監視主機沒有回應或已當機。 主機失敗的狀態代碼為 %1。事件標識碼：21016
事件來源：OpsMgr 連接器
事件描述：
OpsMgr 無法將通道設定為 %1，而且沒有故障轉移主機。 當 %1 可用且允許來自這部電腦的通訊時，通訊將會繼續。事件標識碼：21006
事件來源：OpsMgr 連接器
事件描述：
OpsMgr 連接器無法連線到 %1：%2。 錯誤碼為 %3（%4）。 請確認有網路連線能力、伺服器正在執行，並已註冊其接聽埠，而且沒有防火牆封鎖目的地的流量。事件標識碼：20070
事件來源：OpsMgr 連接器
事件描述：
連線至 %1 的 OpsMgr 連接器，但在驗證發生後立即關閉連線。 發生此錯誤最可能的原因是代理程式未取得授權，無法與伺服器通訊，或是伺服器尚未接收到設定。 請檢查伺服器的事件記錄檔是否有 20000 事件，此類事件會指出未核准的代理程式正在嘗試連線。事件標識碼：20051
事件來源：OpsMgr 連接器
事件描述：
無法載入指定的憑證，因為憑證目前無效。 確認系統時間正確，並視需要重新發行憑證%n 憑證有效開始時間： %1%n 憑證有效結束時間 ： %2事件來源：ESE
事件類別：交易管理員
事件標識碼：623
描述：HealthService （<PID>） 實例><版本存放區（“<name>”） 已達到其最大值> Mb 的大小。< 長時間執行的交易可能會防止清除版本存放區，並導致其大小增加。 更新將會遭到拒絕，直到長時間執行的交易完全認可或回復為止。 可能長時間執行的交易：
SessionId： <value>
會話內容： <值>
會話內容 ThreadId：<value>。
清除： <值>如果您找到下列特定事件，則請遵循下列指導方針：
事件 1102 和 1103：這些事件指出無法載入一些工作流程。 如果這些是核心系統工作流程，則這些事件可能會導致問題。 在此情況下，請專注於解決這些事件。
事件 1104、1105、1106、1107 和 1108：這些事件可能會導致事件 1102 和 1103 發生。 一般而言，這是因執行身分帳戶設定錯誤而發生。 例如，執行身分帳戶設定為與錯誤的類別搭配使用，或未設定為散發至代理程式。
事件 4000：此事件表示Monitoringhost.exe進程當機。 如果此問題是由 DLL 不符或遺失登錄機碼所造成，您可以重新安裝代理程式來解決問題。 如果問題持續發生，請嘗試使用下列方法來解決此問題：
- 執行行程監視器擷取，直到行程當機為止。 如需詳細資訊，請參閱 進程監視器 v3.53。
- 在當機模式中產生ADPlus傾印。 如需詳細資訊，請參閱 如何使用 ADPlus.vbs 針對「停止回應」和「當機」進行疑難解答
事件標識碼 21006：此事件表示代理程式與管理伺服器之間存在通訊問題。 如果代理程式使用憑證進行相互驗證，請確認憑證未過期，且代理程式使用的是正確的憑證。 如果使用 Kerberos，請確認代理程式可以與 Active Directory 通訊。 如果驗證正常運作，這可能表示來自代理程式的封包未連線到管理伺服器或閘道。 嘗試建立從代理程式到管理伺服器的埠 5723 的 telnet。 此外，當您重現通訊失敗時，請在代理程式與管理伺服器之間執行同時的網路追蹤。 這可協助您判斷封包是否到達管理伺服器，以及兩個元件之間的任何裝置是否嘗試優化流量，或正在卸除某些封包。 如需詳細資訊，請參閱 使用網路監視器收集數據。
事件標識碼 623：此事件通常會發生在管理伺服器或代理程式計算機管理許多工作流程的大型 Operations Manager 環境中。 如需詳細資訊，請參閱 Operations Manager 控制台中的一或多部管理伺服器及其受管理裝置。
案例 3
向特定管理伺服器或閘道報告的所有代理程式都無法使用。
案例 3 的解決方案
若要解決此問題，請遵循下列步驟：
嘗試判斷管理伺服器或閘道正在監視的工作負載類型。 這類工作負載可能包括網路裝置、跨平臺代理程式、綜合交易、Windows 代理程式和無代理程序計算機。
判斷健康情況服務是在管理伺服器或閘道上執行。
判斷管理伺服器是否以維護模式執行。 如有必要，請從維護模式中移除伺服器。
檢查代理程式上的 Operations Manager 事件記錄檔中是否有案例 2 中列出的任何事件。 如果有事件標識碼 21006，請遵循案例 2 解析中所述的相同指導方針。 此外，在此情況下，此事件表示管理伺服器或閘道無法與其父伺服器通訊。 對於閘道，父伺服器可以是任何管理伺服器。 （請參閱 中的 步驟 3案例 2 的解決方式。
檢查 Operations Manager 事件記錄檔中是否有下列事件。 這些事件通常表示管理伺服器上或裝載 或
OperationsManagerDW資料庫的 SQL ServerOperationsManagerMicrosoft發生效能問題：事件識別碼：2115
事件來源：HealthService
事件描述：
管理群組 %1 中的系結數據源已將專案張貼至工作流程，但未在 %5 秒內收到回應。 這表示工作流程的效能或功能問題。%n 工作流程識別碼 ： %2%n 實例： %3%n 實例識別碼 ： %4%n事件標識碼：5300
事件來源：HealthService
事件描述：
本機健康情況服務狀況不良。 實體狀態變更流程會因為擱置通知而停滯。 %n%n管理群組： %2 %n管理群組識別碼： %1事件識別碼：4506
事件來源：HealthService
事件描述：Operations Manager
因為針對管理群組 %1 中標識碼為「%3」 的實例 「%3」 執行的規則 「%2」 中，數據已卸除。事件識別碼：31551
事件來源：健全狀況服務 模組
事件描述：
無法將數據儲存在數據倉儲中。 作業將會重試。%rException '%5'： %6 %n%n%n一或多個工作流程受到此影響。 %n%nWorkflow name： %2 %nInstance name： %3 %nInstance ID： %4 %nManagement group： %1事件標識碼：31552
事件來源：健全狀況服務 模組
事件描述：
無法將數據儲存在數據倉儲中。%rException '%5'： %6 %n%n%n一或多個工作流程受到此影響。 %n%nWorkflow name： %2 %nInstance name： %3 %nInstance ID： %4 %nManagement group： %1事件標識碼：31553
事件來源：健全狀況服務 模組
事件描述：
數據已寫入數據倉儲暫存區域，但後續作業的其中一個處理失敗。%rException '%5'： %6 %n%n一或多個工作流程會受到此影響。 %n%nWorkflow name： %2 %nInstance name： %3 %nInstance ID： %4 %nManagement group： %1事件標識碼：31557
事件來源：健全狀況服務 模組
事件描述：
無法從數據倉儲資料庫取得同步處理處理狀態資訊。 作業將會重試。%rException '%5'： %6 %n%n%n一或多個工作流程受到此影響。 %n%nWorkflow name： %2 %nInstance name： %3 %nInstance ID： %4 %nManagement group： %1事件標識碼 3155X 也可能因為執行身分帳戶設定不正確或執行身分帳戶的許可權遺失而記錄。
注意
若要針對管理伺服器或閘道效能和 SQL Server 效能進行疑難解答，請參閱 案例 4 的解決一節。
案例 4
報告給特定管理伺服器的所有代理程式會間歇性地在狀況良好和灰色狀態之間交替。 或者，環境中的所有代理程式會間歇性地在狀況良好和灰色狀態之間交替。
案例 4 的解決方案
若要解決此問題，請先判斷問題的原因。 暫時伺服器無法使用的常見原因包括：
- 代理程式的父伺服器暫時離線。
- 代理程式會大量使用作業數據來淹沒管理伺服器，例如警示、狀態、探索等等。 這可能會導致 Operations Manager 資料庫和 Operations Manager 伺服器上的系統資源使用量增加。
- 網路中斷導致父伺服器與代理程式之間的暫時通訊失敗。
- 發生管理元件 （MP） 變更。 在 Operations Manager 控制台中，這些變更需要 Operations Manager 組態和 MP 轉散發給代理程式。 如果變更會影響較大的代理程式基底，這可能會導致 Operations Manager 資料庫和 Operations Manager 伺服器上系統資源使用量增加。
在這些案例中進行疑難解答的關鍵是瞭解伺服器無法使用的持續時間及其發生時間。 這可協助您快速縮小問題的範圍。
針對 Management 伺服器和閘道效能進行疑難排解
管理伺服器
在組態更新高載期間（這是由 MP 匯入和探索所造成），典型的瓶頸是 Operations Manager 安裝磁碟 I/O，第一個是 CPU，第二個是 Operations Manager 安裝磁碟 I/O。 管理伺服器負責將設定檔轉接至目標代理程式。
操作資料收集的瓶頸通常是由 CPU 所造成。 也可能是因為磁碟 I/O 已達最大容量，但這個機率比較低。 管理伺服器負責解壓縮及解密傳入的操作資料，並將其插入操作資料庫。 該伺服器也會在收到操作資料之後，將認可 (ACK) 傳送回代理程式或網路閘道，並使用磁碟佇列暫時儲存這些傳出 ACK。
閘道
閘道同時是 CPU 系結和 I/O 系結。 當閘道轉接大量數據時，CPU 和 I/O 作業可能會顯示高使用量。 大部分的 CPU 使用量都是由傳入數據的解壓縮、壓縮、加密和解密所造成，以及該數據的傳輸所造成。 網關和代理程式接收的所有數據都會儲存在磁碟上的永續性佇列中，由網關健全狀況服務讀取和轉送至管理伺服器。 這可能會導致大量磁碟使用量。 當閘道暫時離線時，此使用方式可能會相當重要，然後必須處理代理程式所產生的累積代理程序數據，並在閘道仍然離線時嘗試傳送。
若要對此問題進行疑難排解，請針對每個受影響的管理伺服器或閘道收集下列資訊：
精確的 Windows 版本、版本和組建編號
處理器數目
RAM 數量
包含 健全狀況服務 State 資料夾的磁碟驅動器
防病毒軟體是否已設定為排除 健全狀況服務 存放區
注意
如需詳細資訊，請參閱 與 Operations Manager 相關的防毒排除建議。
健全狀況服務 狀態所使用的磁碟驅動器的RAID層級 （
0、、50+11或 ）1+0用於 RAID 的磁碟數目
數位控制器上是否啟用電池支援的寫入快取
針對 SQL Server 效能進行疑難排解
操作資料庫 （OperationsManager）
對 OperationsManager 資料庫而言，最可能造成瓶頸的是磁碟陣列。 如果磁碟陣列未達最大 I/O 容量，則下一個最有可能造成瓶頸的是 CPU。 資料庫偶爾會經歷速度變慢和操作資料風暴 (持續時間相對較長的事件、警報和效能資料或狀態變更的高發生率)。 短暫的高載通常不會造成任何長時間的重大延遲。
在操作資料插入期間，資料庫磁碟主要用於寫入。 CPU 使用量是由 SQL Server 流失所致。 當您有大型且複雜的查詢、大量資料插入，以及大型資料表的清理 (預設會在午夜發生) 時，便可能會發生此情況。 一般而言，即使是大型事件和效能資料表的清理也不會耗用過多的 CPU 或磁碟資源。 不過，對於大型資料表而言，清理警示和狀態變更資料表可能會耗用大量 CPU。
當資料庫處理組態轉散發高載時，也會受限於 CPU，這些高載是由 MP 匯入或大型執行個體空間變更所導致的。 在這些情況下，Config 服務會查詢資料庫以取得新的代理程式組態。 這通常會導致服務將組態更新傳送至代理程式前，在資料庫上出現 CPU 尖峰。
資料倉儲 （OperationsManagerDW）
對 OperationsManagerDW 資料庫而言，最可能造成瓶頸的是磁碟陣列。 這通常是因為大量操作資料插入而發生。 在這類情況下，磁碟大多忙於執行寫入。 通常，磁碟只會執行少量的讀取，除了處理手動產生的報表檢視以外，因為這類作業會在資料倉儲上執行查詢。
CPU 使用量是由 SQL Server 流失所致。 CPU 尖峰可能發生在繁重的資料分割活動 (當資料表變大而因此遭到分割時)、複雜報告的生成，以及資料庫中出現大量警報時，在這些情況下資料倉儲必須不斷進行同步處理。
一般疑難排解
若要對此問題進行疑難排解，請針對每個受影響的管理伺服器或閘道收集下列資訊：
精確的 Windows 版本、版本和組建編號
處理器數目
RAM 數量
配置給 SQL Server 的記憶體數量
SQL Server 是否為 32 位元且已啟用 AWE
您可以在 SQL Server Management Studio 或 SQL Server Enterprise Manager 中找到大部分資訊。 若要這樣做，請開啟伺服器的 [屬性] 視窗，然後選取 [一般] 和 [記憶體] 索引標籤。 [一般] 索引標籤包含 SQL Server 版本、Windows 版本、平台、RAM 數量和處理器數目。 [記憶體] 索引標籤包含配置給 SQL Server 的記憶體。 在 Microsoft SQL Server 2008 中，[記憶體] 索引標籤也包含 AWE 選項。
如果 OS 為 32 位元，且 RAM 為 4 GB 或更大，請檢查
/pae或/3gb參數是否存在於 Boot.ini 中。 檔的 SSDL 區段。 如果伺服器在原先安裝時具有 4 GB 或更小的 RAM，且後來升級了 RAM，則這些選項可能設定不正確。對於具有 4 GB RAM 的 32 位元伺服器，Boot.ini 中的
/3gb參數會增加 SQL Server 可以處理的記憶體 (從 2 GB 到 3 GB)。 對於具有超過 4 GB RAM 的 32 位元伺服器，Boot.ini 中的/3gb參數實際上能夠限制 SQL Server 可以處理的記憶體。 針對這些系統，請將/pae參數新增至 Boot.ini，然後在 SQL Server 中啟用 AWE。在多處理器系統上，請檢查平行處理原則的最大程度 (MAXDOP) 設定。 在 SQL Server 2008 中，此選項位於伺服器的 [屬性] 對話方塊中的 [進階] 索引標籤上。
預設值為 0，表示將使用所有可用的處理器。 0 的設定適用於具有八個或更少處理器的伺服器。 對於具有八個以上處理器的伺服器，SQL Server 協調使用所有處理器所花費的時間可能會適得其反。 因此，對於具有八個以上處理器的伺服器，您通常應該將平行處理原則的最大程度值設為 8。 若要這樣做，請在 SQL 查詢分析器中執行下列命令：
sp_configure 'show advanced options', 1 GO RECONFIGURE WITH OVERRIDE GO sp_configure 'max degree of parallelism', 8 GO RECONFIGURE WITH OVERRIDE GO包含數據倉儲、Operations Manager DB 和 Tempdb 檔案的驅動器號
防毒軟體是否設為排除 SQL 資料和記錄檔 (使用防毒軟體掃描 SQL Server 資料庫檔案可能會降低效能)。
磁碟驅動器上包含數據倉儲、Operations Manager DB 和 Tempdb 檔案的可用空間量
儲存體類型 (SAN 或本機)
SQL Server 所使用磁碟機的 RAID 層級 (0、1、5、0+1 或 1+0)
如果使用 SAN 儲存體：SQL Server 所使用的每個 LUN 上的主軸數目
如果使用已轉換的 Exchange 2007 管理元件，或曾經使用過：Operations Manager 資料庫中
EventPublisher數據表和數據倉儲資料庫中數據表中的數據列LocalizedText數目若要判斷資料列數量，請執行下列命令：
USE OperationsManager SELECT COUNT(*) FROM LocalizedText USE OperationsManagerDW SELECT COUNT(*) FROM EventPublisher
識別記憶體壓力的計數器
| 效能計數器名稱 | 描述 |
|---|---|
| MSSQL$<instance>： Buffer Manager： Page life expectancy | 頁面在緩衝集區中的保存時間長度。 如果此值低於 300 秒，則可能表示伺服器可以使用更多記憶體。 也可能是來自於索引片段。 |
| MSSQL$<instance>： Buffer Manager： Lazy writes/sec | 延遲寫入器會將頁面移至磁碟，以釋放緩衝區空間。 一般而言，此值不應持續超過每秒 20 筆寫入。 在理想情況下，此值應趨近於零。 |
| Memory: Available Mbytes | 低於 100 MB 的值可能表示記憶體壓力。 當此數量小於 10 MB 時，代表記憶體壓力明顯存在。 |
| Process: Private Bytes: _Total | 這是所有流程使用的記憶體量 (實體和頁面) 總和。 |
| Process: Working Set: _Total | 這是所有流程使用的實體記憶體量總和。 如果此計數器的值明顯低於 Process: Private Bytes: _Total 的值，則表示流程分頁過多。 超過 10% 的差異便可能影響重大。 |
識別磁碟壓力的計數器
為所有包含 SQL 資料或記錄檔的磁碟機，擷取這些實體磁碟計數器：
% Idle Time：回報多少磁碟閒置時間。 任何低於 50% 的項目都可能表示磁碟瓶頸。
平均磁碟佇列長度：此值不應超過 LUN 上主軸數目的兩倍。 例如，如果 LUN 有 25 個主軸，則可接受的值為 50。 不過，如果 LUN 有 10 個主軸，則值 25 太高。 您可以根據 RAID 設定中的 RAID 層級和磁碟數目，來使用下列公式：
RAID 0：所有磁碟都在 RAID 0 集中執行工作
平均磁碟佇列長度<= # （陣列中的磁碟） *2
RAID 1：磁片的一半正在執行工作;因此，只有其中一半可以計入磁片佇列中
平均磁碟佇列長度<= # （陣列中的磁碟/2） *2
RAID 10：磁片的一半正在「執行工作」;因此，只有其中一半可以計入磁片佇列中
平均磁碟佇列長度<= # （陣列中的磁碟/2） *2
RAID 5：所有磁碟都在 RAID 5 集中執行工作
平均磁碟佇列長度<= # 陣列中的磁碟 *2
平均磁碟秒數/傳輸：完成一個磁碟 I/O 所需的秒數
平均磁碟秒數/讀取：從磁碟讀取資料的平均時間 (秒)
平均磁碟秒數/寫入：將資料寫入至磁碟的平均時間 (秒)
此清單中的最後三個計數器應該始終保持在 .020 (20 毫秒) 或以下的值，而且絕對不應該超過 .050 (50 毫秒)。 下列閾值記載於 SQL Server 效能疑難排解指南中：
- 小於 10 毫秒：非常好
- 介於 10 至 20 毫秒之間：普通
- 介於 20 至 50 毫秒之間：緩慢，需要注意
- 大於 50 毫秒：嚴重 I/O 瓶頸
磁碟位元組/秒：每秒傳輸至磁碟或從磁碟傳出的位元組數目
磁碟傳輸/秒：每秒輸入和輸出作業數目 (IOPS)
當 % 閒置時間偏低 (10% 或更少) 時，表示磁碟已充分利用。 在此情況下，此清單中的最後兩個計數器 (磁碟位元組/秒和磁碟傳輸/秒) 分別以位元組和 IOPS 提供了磁碟機最大輸送量的良好指標。 根據主軸數目、磁碟機速度和通道速度，SAN 磁碟機的輸送量會有高度變動。 最好的辦法便是洽詢 SAN 廠商，了解磁碟機應該支援的位元組和 IOPS 數目。 如果 % Idle Time 太低，而且這兩個計數器的值不符合預期的磁碟機輸送量，請洽詢 SAN 廠商進行疑難排解。
SQL Server 效能疑難排解指南針對 SQL Server 效能疑難排解提供深入解析。
Operations Manager 性能計數器
下列各節說明可用來監視及疑難解答 Operations Manager 效能的性能計數器。
閘道伺服器角色
整體性能計數器
這些計數器表示閘道的整體效能：
| 效能計數器名稱 |
|---|
| Processor(_Total)\% Processor Time |
| Memory\% Committed Bytes In Use |
| 網路介面卡(*)\位元組總數/秒 |
| LogicalDisk}\% 閑置時間 |
| LogicalDisk\\Avg. Disk Queue Length |
Operations Manager 處理一般效能計數器
這些計數器表示閘道上 Operations Manager 進程的整體效能：
| 效能計數器名稱 | 描述 |
|---|---|
| Process（HealthService）\% Processor Time | |
| Process(HealthService)\Private Bytes | 視此閘道所管理的代理程式數目而定，此數目可能會有所不同，而且可能會有數百 MB |
| Process(HealthService)\Thread Count | |
| Process(HealthService)\Virtual Bytes | |
| Process(HealthService)\Working Set | |
| Process（MonitoringHost*）\% 處理器時間 | |
| Process(MonitoringHost*)\Private Bytes | |
| Process(MonitoringHost*)\Thread Count | |
| Process(MonitoringHost*)\Virtual Bytes | |
| Process(MonitoringHost*)\Working Set |
Operations Manager 特定效能計數器
這些計數器是 Operations Manager 特定計數器，指出閘道上 Operations Manager 特定層面的效能：
| 效能計數器名稱 | 描述 |
|---|---|
| Health Service\Workflow Count | |
| Health Service Management Groups(*)\Active File Uploads | 此閘道正在處理的檔案傳輸數目。 表示要上傳至代理程式的管理組件檔案數目。 如果此值一直都很大，且在特定時間沒有太多管理組件匯入，則這些條件可能會造成影響檔案傳輸的問題。 |
| Health Service Management Groups(*)\Send Queue % Used | 永續性佇列的大小。 如果此值長期大於 10 且不會卸除，則表示佇列已備份。 此狀況是由多載的 Operations Manager 系統所造成，因為管理伺服器或資料庫太忙碌或離線。 |
| OpsMgr Connector\Bytes Received | 閘道所接收的網路位元組數目 ，也就是解壓縮前的傳入位元組數目。 |
| OpsMgr Connector\Bytes Transmitted | 閘道傳送的網路位元組數目 ，也就是壓縮後的傳出位元組數目。 |
| OpsMgr Connector\Data Bytes Received | 閘道所接收的數據位元組數目 ，也就是解壓縮後傳入的數據量。 |
| OpsMgr Connector\Data Bytes Transmitted | 網關所傳送的數據位元組數目，也就是壓縮之前傳出的數據量。 |
| OpsMgr Connector\Open Connections | 閘道上開啟的連線數目。 此數目應該與直接連線至閘道的代理程式或管理伺服器數目相同。 |
管理伺服器角色
整體性能計數器
這些計數器表示管理伺服器的整體效能：
| 效能計數器名稱 |
|---|
| Processor(_Total)\% Processor Time |
| Memory\% Committed Bytes In Use |
| 網路介面卡(*)\位元組總數/秒 |
| LogicalDisk}\% 閑置時間 |
| LogicalDisk\\Avg. Disk Queue Length |
Operations Manager 處理一般效能計數器
這些計數器表示管理伺服器上 Operations Manager 流程的整體效能：
| 效能計數器名稱 | 描述 |
|---|---|
| Process（HealthService）\% Processor Time | |
| Process(HealthService)\Private Bytes | 根據此管理伺服器所管理的代理程式數目，此數字可能有所不同，而且可能達數百 MB。 |
| Process(HealthService)\Thread Count | |
| Process(HealthService)\Virtual Bytes | |
| Process(HealthService)\Working Set | |
| Process（MonitoringHost*）\% 處理器時間 | |
| Process(MonitoringHost*)\Private Bytes | |
| Process(MonitoringHost*)\Thread Count | |
| Process(MonitoringHost*)\Virtual Bytes | |
| Process(MonitoringHost*)\Working Set |
Operations Manager 特定效能計數器
這些計數器是 Operations Manager 的特定計數器，表示管理伺服器上 Operations Manager 特定層面的效能：
| 效能計數器名稱 | 描述 |
|---|---|
| Health Service\Workflow Count | 在此管理伺服器上執行的工作流程數目。 |
| Health Service Management Groups(*)\Active File Uploads | 此管理伺服器正在處理的檔案傳輸數目。 表示要上傳至代理程式的管理組件檔案數目。 如果此值一直都很大，且在特定時間沒有太多管理組件匯入，則這些條件可能會造成影響檔案傳輸的問題。 |
| Health Service Management Groups(*)\Send Queue % Used | 永續性佇列的大小。 如果此值長期大於 10 且不會卸除，則表示佇列已備份。 此條件是由多載的 Operations Manager 系統所造成，起因為 Operations Manager 系統 (如 Root Management Server) 過於忙碌或離線。 |
| Health Service Management Groups(*)\Bind Data Source Item Drop Rate | 為執行資料庫或資料倉儲資料收集寫入動作，管理伺服器所卸除的資料項目數目。 當這個計數器值不是 0時，管理伺服器或資料庫會多載，因為它無法處理足夠快的傳入數據項，或因為發生數據項高載。 代理程式會重新傳送卸除的資料項目。 多載或高載情況結束後，系統會將這些資料項目插入資料庫或資料倉儲。 |
| Health Service Management Groups(*)\Bind Data Source Item Incoming Rate | 為執行資料庫或資料倉儲資料收集寫入動作，管理伺服器所接收的資料項目數目。 |
| Health Service Management Groups(*)\Bind Data Source Item Post Rate | 為執行資料收集寫入動作，管理伺服器寫入至資料庫或資料倉儲的資料項目數目。 |
| OpsMgr Connector\Bytes Received | 管理伺服器所接收的網路位元組數目，也就是解壓縮之前傳入的位元組大小。 |
| OpsMgr Connector\Bytes Transmitted | 管理伺服器所傳送的網路位元組數目，也就是壓縮之後傳出的位元組大小。 |
| OpsMgr Connector\Data Bytes Received | 管理伺服器所接收的數據位元組數目，也就是解壓縮後傳入數據的大小。 |
| OpsMgr Connector\Data Bytes Transmitted | 管理伺服器傳送的數據位元組數目，也就是壓縮前傳出數據的大小。 |
| OpsMgr Connector\Open Connections | 管理伺服器上開啟的連線數目。 此數值應該與直接連線的代理程式或 Root Management Server 數目相同。 |
| OpsMgr database Write Action Modules(*)\Avg. Batch Size | 資料庫寫入動作模組所接收的資料項目或批次數目。 如果此數字為 5,000，就會發生資料項目高載。 |
| OpsMgr DB Write Action Modules(*)\Avg. Processing Time | 資料庫寫入動作模組在資料庫中批次插入所花費的秒數。 如果這個數字經常大於 60，就會發生資料庫插入效能問題。 |
| OpsMgr DW Writer Module(*)\Avg. Batch Processing Time, ms | 資料倉儲寫入動作將資料項目批次插入資料倉儲所花費的毫秒數。 |
| OpsMgr DW Writer Module(*)\Avg. Batch Size | 資料倉儲寫入動作模組所接收的平均資料項目或批次數目。 |
| OpsMgr DW Writer Module(*)\Batches/sec | 每秒由資料倉儲寫入動作模組所接收的批次數目。 |
| OpsMgr DW Writer Module(*)\Data Items/sec | 每秒由資料倉儲寫入動作模組所接收的資料項目數目。 |
| OpsMgr DW Writer Module(*)\Dropped Data Item Count | 由資料倉儲寫入動作模組所卸除的資料項目數目。 |
| OpsMgr DW Writer Module(*)\Total Error Count | 資料倉儲寫入動作模組中發生的錯誤數目。 |