針對 System Center Operations Manager 中的灰色代理程式狀態進行疑難解答

本文說明如何針對 System Center Operations Manager (OpsMgr) 中代理程式、管理伺服器或網關無法使用或呈現 灰色 的問題進行疑難解答。

原始產品版本： Microsoft System Center 2012 Operations Manager
原始 KB 編號： 2288515

代理程式、管理伺服器或網關可以具有下列其中一種狀態，如 [ 監視 ] 窗格中代理程式名稱和圖示的色彩所示。

灰色狀態的原因

代理程式、管理伺服器或閘道可能會因為下列任何原因而變成無法使用：

• 活動訊號失敗
• 無效的設定
• 系統工作流程失敗
• Operations Manager 資料庫或數據倉儲效能問題
• 管理伺服器或閘道伺服器效能問題
• 網路或驗證問題
• 健康情況服務未執行

問題範圍

開始針對代理程序呈現灰色的問題進行疑難解答之前，您應該先瞭解 Operations Manager 拓撲，然後定義問題的範圍。 下列問題可協助您定義問題的範圍：

• 有多少代理程式受到影響？
• 代理程式是否在相同的網路區段中遇到問題？
• 代理程式是否向相同的管理伺服器報告？
• 代理程序進入並保持灰色狀態的頻率為何？
• 您通常要如何從這種情況復原 (例如，重新啟動代理程式健康情況服務、清除快取、依賴自動復原) ？
• 是否為這些代理程式產生活動訊號失敗警示？
• 此問題是否在一天的特定時間發生？
• 如果您將這些代理程式故障轉移至另一個管理伺服器或閘道，這個問題是否會持續發生？
• 這個問題何時開始？
• 是否對代理程式、管理伺服器或閘道或管理群組進行任何變更？
• 受影響的代理程式是否為 Windows 叢集系統？
• 健全狀況服務狀態資料夾是否從防病毒軟體掃描中排除？

疑難解答策略

您的疑難解答策略將取決於哪些元件處於非作用中狀態、該元件位於拓撲內的位置，以及問題有多普遍。 請考慮下列條件：

• 如果向特定管理伺服器或閘道回報的代理程式無法使用，疑難解答應該從管理伺服器或閘道層級開始。
• 如果無法向特定管理伺服器報告的網關，疑難解答應該從管理伺服器層級開始。
• 針對無代理程式系統、網路裝置，以及 Unix 和 Linux 伺服器，疑難解答應從監視這些物件的代理程式、管理伺服器或網關開始。
• 疑難解答通常會從緊接在無法使用的元件上方的層級開始。

案例 1

只有少數代理程式會受到此問題的影響。 這些代理程式會向不同的管理伺服器報告。 代理程式持續無法定期使用。 雖然您可以清除代理程式快取以協助暫時解決問題，但問題會在數天后重複發生。

案例 1 的解決方式

若要解決此案例中的問題，請遵循下列步驟：

1. 將適當的 Hotfix 套用至受影響的作業系統。
2. 從防病毒軟體掃描中排除代理程式快取。 如需詳細資訊，請參閱與 Operations Manager 相關的防病毒軟體排除建議。
3. 停止健康情況服務。
4. 清除代理程式快取。
5. 啟動健康情況服務。

案例 2

只有少數代理程式會受到此問題的影響。 這些代理程式會向不同的管理伺服器報告。 代理程式會持續保持非使用中狀態。 雖然您可以清除代理程式快取，但這無法解決問題。

案例 2 的解決方式

若要解決此案例中的問題，請遵循下列步驟：

1. 判斷健康情況服務是否已開啟，且目前正在管理伺服器或閘道上執行。 如果健康情況服務已停止回應，請在服務停止回應模式中產生ADPlus傾印，以協助判斷問題的原因。 如需詳細資訊，請 參閱如何使用 ADPlus.vbs 來針對「停止回應」和「當機」進行疑難解答

2. 檢查代理程式上的 Operations Manager 事件記錄檔，以找出下列任何事件：

   事件標識碼：1102
   事件來源：HealthService
   事件描述：
   無法初始化針對標識碼為：“%2” 的實例 %3“ 執行的規則/監視器”%4“，且不會載入。 管理群組 %1

   事件標識碼：1103
   事件來源：HealthService
   事件描述：
   摘要：%2 規則 () /monitor (的) 失敗並卸除，其中 %3 個已達到防止自動重載的失敗限制。 管理群組 %1。 這隻是摘要事件，請參閱其他事件，其中包含卸除規則 () /monitor () 的描述。

   事件標識碼：1104
   事件來源：HealthService
   事件描述：
   無法解析工作流程 「%4」 中執行且識別碼為 「%2」 之實例 「%3」 的 RunAs 設定檔。 不會載入工作流程。 管理群組 %1

   事件標識碼：1105
   事件來源：HealthService
   事件描述：
   工作流程 %4 中 RunAs 設定檔的類型不符，針對標識碼為 「%2」 的實例 「%3」 執行。 不會載入工作流程。 管理群組 %1

   事件標識碼：1106
   事件來源：HealthService
   事件描述：
   無法存取工作流程 %4 中的純文字 RunAs 設定檔，以識別碼 「%2」 執行實例 「%3」。 不會載入工作流程。 管理群組 %1

   事件標識碼：1107
   事件來源：HealthService
   事件描述：
   未定義工作流程 %4 中 RunAs 設定檔的帳戶，針對識別碼為 「%2」 的實例 「%3」 執行。 不會載入工作流程。 請將帳戶與配置檔建立關聯。 管理群組 %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 連接器
   事件描述：
   OpsMgr 連接器已連線至 %1，但連線在驗證發生后立即關閉。 此錯誤的最可能原因是代理程式未獲授權與伺服器通訊，或伺服器尚未收到設定。 檢查伺服器上的事件記錄檔是否有 20000 個事件，指出未核准的代理程式正在嘗試連線。

   事件標識碼：20051
   事件來源：OpsMgr 連接器
   事件描述：
   無法載入指定的憑證，因為憑證目前無效。 確認系統時間正確，並視需要重新發行憑證%n 憑證有效開始時間： %1%n 憑證有效結束時間 ： %2

   事件來源：ESE
   事件類別：交易管理員
   事件標識碼：623
   描述：HealthService (<PID>) 實例>< (“name>”<) 的版本存放區已達到其值> Mb 的<大小上限。 長時間執行的交易可能會阻止清除版本存放區，並導致它以大小建置。 匯報 會遭到拒絕，直到長時間執行的交易已完全認可或回復為止。 可能長時間執行的交易：
   SessionId： <值>
   會話內容： <值>
   會話內容 ThreadId： <值>。
   清除： <值>

3. 如果您找到下列特定事件，請遵循下列指導方針：

   • 事件 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 的解決方式

若要解決此案例中的問題，請遵循下列步驟：

1. 嘗試判斷管理伺服器或閘道正在監視的工作負載類型。 這類工作負載可能包括網路裝置、跨平臺代理程式、綜合交易、Windows 代理程式和無代理程序計算機。

2. 判斷健康情況服務是在管理伺服器或閘道上執行。

3. 判斷管理伺服器是否以維護模式執行。 如有必要，請從維護模式中移除伺服器。

4. 檢查代理程式上的 Operations Manager 事件記錄檔，以取得 案例 2 中所列的任何事件。 如果有事件標識碼 21006，請遵循 案例 2 的解決方式中所述的相同指導方針。 此外，在此情況下，此事件表示管理伺服器或閘道無法與其父伺服器通訊。 針對閘道，父伺服器可能是任何管理伺服器。 (請參閱 案例 2.) 解決方案中的步驟 3

5. 檢查下列事件的 Operations Manager 事件記錄檔。 這些事件通常表示裝載 或 OperationsManagerDW 資料庫的管理伺服器或 Microsoft SQL Server OperationsManager 上存在效能問題：

   事件標識碼：2115
   事件來源：HealthService
   事件描述：
   管理群組 %1 中的系結數據源已將專案張貼至工作流程，但尚未在 %5 秒內收到回應。 這表示工作流程的效能或功能問題。%n 工作流程識別碼： %2%n 實例 ： %3%n 實例識別碼 ： %4%n

   事件標識碼：5300
   事件來源：HealthService
   事件描述：
   本機健康情況服務狀況不良。 實體狀態變更流程因暫止通知而停止。 %n%n管理群組： %2 %n管理群組識別碼： %1

   事件標識碼：4506
   事件來源：HealthService
   事件描述：Operations Manager
   因為在管理群組 %1 中，針對標識碼為 「%4」 的實例 「%3」 執行的規則 「%2」 中有太多未處理的數據，所以數據已卸除。

   事件標識碼：31551
   事件來源：健全狀況服務模組
   事件描述：
   無法將數據儲存在 Data Warehouse 中。 作業將會重試。%rException '%5'： %6 %n%n一或多個工作流程受到此影響。 %n%n工作流程名稱： %2 %n實例名稱： %3 %n實例識別碼： %4 %n管理群組： %1

   事件標識碼：31552
   事件來源：健全狀況服務模組
   事件描述：
   無法將數據儲存在 Data Warehouse 中。%rException '%5'： %6 %n%n一或多個工作流程受到此影響。 %n%n工作流程名稱： %2 %n實例名稱： %3 %n實例識別碼： %4 %n管理群組： %1

   事件標識碼：31553
   事件來源：健全狀況服務模組
   事件描述：
   數據已寫入 Data Warehouse 暫存區域，但在其中一個後續作業上處理失敗。%rException '%5'： %6 %n%n一或多個工作流程受到此影響。 %n%n工作流程名稱： %2 %n實例名稱： %3 %n實例識別碼： %4 %n管理群組： %1

   事件標識碼：31557
   事件來源：健全狀況服務模組
   事件描述：
   無法從 Data Warehouse 資料庫取得同步處理程式狀態資訊。 作業將會重試。%rException '%5'： %6 %n%n一或多個工作流程受到此影響。 %n%n工作流程名稱： %2 %n實例名稱： %3 %n實例識別碼： %4 %n管理群組： %1

6. 事件標識碼 3155X 也可能因為執行身分帳戶設定不正確或缺少執行身分帳戶的許可權而記錄。

案例 4

所有向特定管理伺服器報告的代理程式，會在狀況良好和灰色狀態之間間歇性地替代。 或者，環境中的所有代理程式會間歇性地在狀況良好和灰色狀態之間交替。

案例 4 的解決方式

若要解決此問題，請先判斷問題的原因。 暫時伺服器無法使用的常見原因包括：

• 代理程式的父伺服器暫時離線。
• 代理程式會向管理伺服器大量散發作業數據，例如警示、狀態、探索等等。 這可能會導致 Operations Manager 資料庫和 Operations Manager 伺服器上的系統資源使用量增加。
• 網路中斷導致父伺服器與代理程式之間的暫時通訊失敗。
• 發生變更) 管理元件 (MP。 在 Operations Manager 控制台中，這些變更需要 Operations Manager 設定和 MP 轉散發給代理程式。 如果變更影響較大的代理程式基底，這可能會導致 Operations Manager 資料庫和 Operations Manager 伺服器上的系統資源使用量增加。

在這些案例中進行疑難解答的關鍵在於瞭解伺服器無法使用的持續時間，以及其發生期間的當日時間。 這可協助您快速縮小問題的範圍。

針對管理伺服器和閘道效能進行疑難解答

管理伺服器

在 MP 匯入和探索) 所造成的組態更新高載 (期間，典型的瓶頸包括：第一個、CPU，第二個，Operations Manager 安裝磁碟 I/O。 管理伺服器負責將組態檔轉送至目標代理程式。

針對作業數據收集，瓶頸通常是由CPU所造成。 磁碟 I/O 可能也處於最大容量，但這並不一樣可能。 管理伺服器負責解壓縮和解密傳入的作業數據，並將它插入至操作資料庫。 它也會在接收作業數據之後，將 (ACK) 傳回給代理程式或閘道，並使用磁碟佇列暫時儲存這些傳出的 ACK。

閘道

閘道是 CPU 系結和 I/O 系結。 當閘道正在轉送大量數據時，CPU 和 I/O 作業可能會顯示高使用量。 大部分的 CPU 使用量都是由解壓縮、壓縮、加密和解密連入數據，以及該數據的傳輸所造成。 網關和代理程式收到的所有數據都會儲存在磁碟上的永續性佇列中，由網關健康情況服務讀取並轉送到管理伺服器。 這可能會造成大量磁碟使用量。 當閘道暫時離線，然後必須處理代理程式在閘道仍然離線時所產生並嘗試傳送的累積代理程序數據時，此使用方式可能相當重要。

若要針對此情況的問題進行疑難解答，請針對每個受影響的管理伺服器或網關收集下列資訊：

• 確切的 Windows 版本、版本和組建編號

• 處理器數目

• RAM 數量

• 包含健全狀況服務狀態資料夾的磁碟驅動器

• 防病毒軟體是否設定為排除健全狀況服務存放區

  注意事項

  如需詳細資訊，請參閱與 Operations Manager 相關的防病毒軟體排除建議。

• 針對健全狀況0服務狀態所使用的磁碟驅動器， (、15、 0+1 或 1+0) 的RAID層級

• 用於 RAID 的磁碟數目

• 數位控制器上是否已啟用電池支援的寫入快取

針對 SQL Server 效能進行疑難解答

OperationsManager (操作資料庫)

OperationsManager針對資料庫，最有可能的瓶頸是磁碟陣列。 如果磁碟陣列未達到最大 I/O 容量，則下一個最有可能的瓶頸是 CPU。 資料庫偶爾會遇到速度變慢和操作數據暴攻擊， (事件、警示和效能數據或狀態變更的高發生率，而這些事件、警示或狀態變更會持續相當長的時間) 。 短高載通常不會造成很長一段時間的任何重大延遲。

在操作數據插入期間，資料庫磁碟主要用於寫入。 CPU 使用是由 SQL Server 變換所造成。 當您有大型且複雜的查詢、大量數據插入，以及清理大型數據表 (預設會在午夜) 時發生時，就會發生這種情況。 一般而言，即使是大型事件和效能數據表的清理也不會耗用過多的CPU或磁碟資源。 不過，針對大型數據表，警示和狀態變更數據表的清理可能會耗用大量CPU。

當資料庫處理由 MP 匯入或大型實例空間變更所造成的組態轉散發高載時，資料庫也會受到 CPU 系結。 在這些情況下，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 或更大，請檢查 或 /3gb 參數是否/pae存在於 Boot.ini 中。 檔。 如果原本安裝的伺服器是以 4 GB 或更少的 RAM 安裝，以及之後是否升級 RAM，這些選項可能會設定不正確。

  對於具有 4 GB RAM 的 32 位伺服器，/3gbBoot.ini 中的 參數會將 SQL Server 可處理 (的記憶體數量從 2 GB 增加到 3 GB) 。 對於 RAM 超過 4 GB 的 32 位伺服器，/3gbBoot.ini 中的參數實際上可能會限制 SQL Server 可尋址的記憶體數量。 針對這些系統，將 參數新/pae增至 Boot.ini，然後在 SQL Server 中啟用 AWE。

  在多處理器系統上，檢查 MaxDOP) 設定 (平行處理原則的最大程度 。 在 SQL Server 2008 中，此選項位於伺服器 [屬性] 對話方塊的 [進階] 索引標籤上。

  默認值為 0，表示將使用所有可用的處理器。 設定 0 適用於具有八個或更少處理器的伺服器。 對於擁有八個以上處理器的伺服器而言，SQL Server 協調使用所有處理器所需的時間可能會產生反作用。 因此，對於擁有超過八個處理器的伺服器，您通常應該將 Max Degree of Parallelism 設為 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 記憶體：每個 LUN 上由 SQL Server 使用的主軸數目

• 如果已轉換的 Exchange 2007 管理元件正在使用或曾經使用過：Operations Manager 資料庫和數據倉儲資料庫EventPublisher中數據表中的數據列數目LocalizedText

  若要判斷資料列數量，請執行下列命令：

  USE OperationsManager SELECT COUNT(*) FROM LocalizedText
  USE OperationsManagerDW SELECT COUNT(*) FROM EventPublisher
  

用來識別記憶體壓力的計數器

用來識別磁碟壓力的計數器

針對包含 SQL 資料或記錄檔的所有磁碟驅動器擷取這些實體磁碟計數器：

• % 空閒時間：報告多少磁碟閑置時間。 低於 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 瓶頸

  • Disk Bytes/sec：每秒在磁碟之間傳輸的位元元組數目

  • 磁碟傳輸/秒： (IOPS) 每秒輸入和輸出作業的數目

  當 %Idle Time (10% 或更少) 時，這表示磁碟已充分利用。 在此情況下，此清單中的最後兩個計數器會分別 (磁 碟位元組/秒 和 磁碟傳輸/秒) 分別以位元組和IOPS提供磁碟驅動器最大輸送量的良好指示。 SAN 磁碟驅動器的輸送量會高度變動，視主軸數目、磁碟驅動器速度和通道速度而定。 最好的選擇是洽詢 SAN 廠商，以瞭解磁碟驅動器應該支援多少個字節和 IOPS。 如果 %Idle Time 不足，而且這兩個計數器的值不符合磁碟驅動器的預期輸送量，請洽詢 SAN 廠商進行疑難解答。

SQL Server 效能疑難解答指南可讓您深入瞭解 SQL Server 效能的疑難解答。

Operations Manager 性能計數器

下列各節說明可用來監視 Operations Manager 效能並進行疑難解答的性能計數器。

閘道伺服器角色

整體性能計數器

這些計數器表示閘道的整體效能：

Operations Manager 進程一般性能計數器

這些計數器表示閘道上 Operations Manager 進程的整體效能：

Operations Manager 特定性能計數器

這些計數器是 Operations Manager 特定計數器，表示閘道上 Operations Manager 特定層面的效能：

管理伺服器角色

整體性能計數器

這些計數器表示管理伺服器的整體效能：

Operations Manager 進程一般性能計數器

這些計數器表示管理伺服器上 Operations Manager 進程的整體效能：

Operations Manager 特定性能計數器

這些計數器是 Operations Manager 特定計數器，表示管理伺服器上 Operations Manager 特定層面的效能：