共用方式為

如何使用 MaxConcurrentApi 設定執行NTLM驗證的效能微調

  • 發行項

本文說明如何使用 MaxConcurrentApi 設定來執行NTLM驗證的效能微調。

原始 KB 編號： 2688798

簡介

企業資訊技術消費化增加（企業中使用的智能手機和平板計算機等消費者導向裝置的增加）導致企業在企業環境中可能會遇到大量傳統驗證的案例數量增加。 舊版驗證的增加可能會導致效能問題，例如客戶端的延遲或逾時。

當您在環境中探索驗證逾時或延遲（也稱為 MaxConcurrentApi 瓶頸）時，解決問題的一般方法是提高服務該驗證的最大允許背景工作線程。 您可以藉由變更 MaxConcurrentApi 登錄值，然後在伺服器上重新啟動 Net Logon 服務來進行。

識別哪些伺服器是瓶頸的受害者，哪些伺服器實際上是瓶頸延遲的來源，可能會很困難。 本文說明如何使用 MaxConcurrentApi 設定來執行NT LAN Manager （NTLM） 驗證的效能微調。 本文包含系統管理員識別要引發 MaxConcurrentApi 值之伺服器的指引，以及應設定該值的數量。

解決方法

重要

這個章節、方法或工作包含修改登錄的步驟。 然而，不當修改登錄可能會發生嚴重的問題。 因此，請務必小心執行下列步驟。 為增加保護起見，請先備份登錄，再進行修改。 然後，如果發生問題，您就可以還原登錄。 如需有關如何備份和還原登錄的詳細資訊，請按一下以下文章編號來檢視 Microsoft 知識庫 文章：
322756 如何在 Windows 中備份和還原登錄

若要解決此問題，您必須檢閱從案例中涉及之所有伺服器的效能數據。 然後，您可以嘗試在顯示效能遺失的伺服器上增加 MaxConcurrentApi 設定。

有事件 Netlogon 可以報告 NTLM 驗證問題，請參閱：
2654097 Windows Server 2008 R2 中追蹤 NTLM 驗證延遲和失敗的新事件記錄檔專案可供使用

事件指出兩個計數器的活動：

  • 事件 5818/5819：如果已啟用事件，則會有「號志等候者」。
  • 事件 5816/5817：有「號誌逾時」。

若要判斷伺服器的最佳 MaxConcurrentApi 值，必須使用公式來結合和計算數個數據點。 要用來估計 MaxConcurrentApi 的數據如下所示：

  • Net Logon 旗號取得
  • Net Logon 號誌逾時
  • Net Logon 平均號誌保留時間
  • 完成的效能記錄持續時間，以秒為單位

取得數據之後，可以使用下列公式來估計正確的 MaxConcurrentApi 值：（semaphore_acquires semaphore_time + outs） * average_semaphore_hold_time time_collection_length / = New_MaxConcurrentApi_setting <
當您從伺服器在驗證載入時收集 Net Logon 效能資料之後，您應該查看行檢視開始和結束時間來判斷資料收集程式的持續時間。

注意

佔位元 semaphore_acquires 和 semaphore_time 輸出代表在安全性通道存留期間發生的逾時次數的累計數位。 因此，在收集的數據中，數位很可能不會從零開始。 當您在 效能監視器 （Perfmon.msc） 中使用行檢視時，必須從結束編號減去起始編號。 然後，您會在公式中針對新的 MaxConcurrentApi 設定使用此計算數位。 若要判斷數據收集期間發生的逾時次數，請使用 Perfmon.msc 中的 [行檢視]，然後將滑鼠指標放在該計數器的行尾和開始處，然後從結束編號減去起始編號。 結果是要放入方程序的數位。

您可以將預設檢視從 [折線檢視] 變更為 Perfmon.msc 中的 [報表檢視] 來判斷平均號誌保留時間。 例如，請考慮下列案例：

  • 信號取得值為 8,286。
  • 號誌逾時值為883。
  • 平均信號保留時間是 .5 （也就是半秒）。
  • 報告的持續時間為90秒。

在此案例中，公式如下所示：
（8,286 + 883） *.5 / 90 =< 51

如果衍生自公式的值是 150 或更大，您應該新增更多伺服器來服務舊版驗證負載。

如果值小於 150，您應該在該伺服器上將 MaxConcurrentApi 登錄值變更為公式建議的值或較大的值。

注意

如果您決定將 MaxConcurrentApi 值增加到大於 10，則應該先在非生產環境中測試所需設定的負載和效能，再於生產環境中實作變更。 建議您確保增加此值不會造成其他資源瓶頸。 此外，請注意，負載條件可能會根據每個案例和商務環境而變更。 因此，如果服務負載變更，MaxConcurrentApi 值在稍後可能必須有不同的設定。

若要變更 MaxConcurrentApi 設定，請遵循下列步驟：

  1. 按一下 [開始]，按一下 [執行]，輸入 regedit，然後按一下 [確定]。

  2. 找出並按一下下列登錄子機碼：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

  3. 在 [編輯] 功能表中，指向 [新增]，然後按一下 [DWORD 值]。

  4. 輸入 MaxConcurrentApi，然後按 Enter。

  5. 在 [ 編輯] 功能表上，按兩下 [ 修改]。

  6. 在十進位中輸入新的 MaxConcurrentApi 設定，然後按兩下 [ 確定]。

  7. 在命令提示字元中，輸入下列命令，然後按 Enter：
    net stop netlogon

  8. 輸入下列命令，然後按 Enter：
    net start netlogon

其他相關資訊

您可以使用下列知識庫文章，更詳細地識別舊版驗證瓶頸的用戶端徵兆：
975363 當您連線到已驗證的服務時，系統間歇性地提示您輸入認證或體驗逾時。在案例中，驗證瓶頸可能位於多部伺服器上。 因此，您必須確定指定案例中的所有伺服器在忙於維護大量負載時，都會檢閱其效能數據。

信號取得的計數器、信號逾時，以及平均號誌保留時間，都必須在所有應用程式伺服器、域控制器和參與維護用戶端要求的受信任域控制器上檢閱。

當伺服器負載過重時，必須追蹤效能數據。 當伺服器看到大部分的用戶端要求時，就會發生大量負載。 例如，在電子郵件伺服器案例中，收集效能數據的最佳時機是用戶到達工作並檢查其電子郵件訊息。

其他考慮專案如下：

  • 沒有任何值表示不需要採取任何動作。 除非伺服器上有持續負載，否則旗號持有人和旗號保留時間計數器將不會顯示任何值。 如果沒有值存在，則不需要任何 MaxConcurrentApi 值變更。

  • 一個大小不適合全部。 MaxConcurrentApi 值可能必須是每部伺服器不同的值。 這種情況可能是多部應用程式伺服器從單一域控制器取得驗證，或由多個伺服器提供較大量的負載，而域控制器必須處理的類似案例所造成。

  • 信託。 如果正在驗證的使用者來自受信任的網域，可能會導致較長的延遲，因為本機域控制器必須在本機域控制器提供對應用程式伺服器的回應之前，等候來自受信任域控制器的回復。

  • 網路延遲。 網路等待時間也可能在造成 MaxConcurrentApi 瓶頸方面扮演主要角色。 當 MaxConcurrentApi 旗號使用以時間為基礎的逾時計數器，讓用戶端不會無限期等候舊版驗證時，就會發生此問題。

  • 搭配。 如果網路等待時間存在且導致完成 MaxConcurrentApi 線程的延遲和瓶頸，常見的解決方案是將伺服器放在相同的實體位置，以便降低網路等待時間。 例如，在信任網域Microsoft Exchange CAS 伺服器且使用者的網域位於另一個區域或 Active Directory 月臺的網域模型中，這表示將使用者的域控制器放在與 Exchange CAS 伺服器及其域控制器相同的實體位置和 Active Directory 月臺。

  • 可能的下游延遲。 如果 Semaphore Waiters 計數器值隨時持續大於 0（零），而 Semaphore Holders 值小於該伺服器上的 MaxConcurrentApi 設定，則瓶頸不會位於該伺服器上。 在此情況下，請查看列為主計算機完整功能變數名稱之計數器名稱中所引用的域控制器。 應該檢閱該域控制器的 信號服務員 和 旗號持有人 效能數據。

  • 負載或網路組態中的變更。 正在服務或網路組態負載的未來變更可能會產生網路等待時間，並可能導致需要再次擷取正確的 MaxConcurrentApi 設定。 對於在檢查 MaxConcurrentApi 設定的範圍來看舊版驗證磁碟區的環境，強烈建議您持續監視及檢閱 Net Logon 性能物件計數器。 您可以使用排程的自定義 Perfmon.msc 數據收集器、使用 Microsoft System Center Operations Manager，或使用其他方法來執行此作業。

  • Windows Server 2008 最大值。 Windows Server 2008 和更新版本中的 MaxConcurrentApi 允許的最大設定是 150。 如果所使用的伺服器未執行 Windows Server 2008 R2，請套用下列知識庫文章中所述的 Hotfix，以擁有 150 個可用設定：
    975363 當您連線到已驗證的服務時，系統會間歇地提示您輸入認證或體驗逾時

  • Windows Server 2003 上限。 Windows Server 2003 和舊版中 MaxConcurrentApi 允許的最大設定為 10。

  • Windows Server 2012 和更新的預設值。 Windows Server 2012 中 MaxConcurrentApi 的預設值已變更。 成員伺服器和域控制器為10個。 它仍為成員工作站的 1。

  • Windows Server 2003 和性能計數器。 Windows Server 2003 的原始版本未包含 Net Logon 性能計數器。 您可以套用 Hotfix 來新增它。

當您想要減少整體NTLM驗證負載，因而最終減少 MaxConcurrentApi號誌使用次數時，識別執行重複和連續NTLM驗證的未經授權或未知客戶端或服務可能會很有用。 您可以使用 Net Logon 服務偵錯記錄來識別重複的驗證。 如需如何使用 Netlogon.log 檔案偵錯 Net Logon 服務的詳細資訊，請按兩下列文章編號，以檢視Microsoft知識庫中的文章：
109626啟用 Net Logon 服務的偵錯記錄

Security System-Wide Statistics 物件下 NTLM 驗證的 Perfmon.msc 計數器不是 MaxConcurrentApi 追蹤線程使用次數的反映。 在 Net Logon 性能計數器和 NTLM 驗證計數器遞增中顯示的 MaxConcurrentApi 號誌使用方式之間沒有一對一的相互關聯。 NTLM 驗證計數器不適用於判斷最佳 MaxConcurrentApi 值。

此外，可能會看到與 MaxConcurrentApi 相關的舊版驗證效能逾時，但不會反映在 Net Logon 計數器以外的任何性能計數器中。 這表示其他效能計量，例如 CPU 使用和磁碟和網路使用，即使 MaxConcurrentApi 負載很重，而且使用者遇到問題，也可能不會顯示負載。

您可以在具有 Net Logon 服務偵錯記錄中專案的網域控制器執行額外的最小化程式，指出用戶端正在提交 <null>\username ，而不是 domainname\username。 此程式會在下列Microsoft知識庫文章中說明：
923241 如果您的 Active Directory 域控制器上有許多外部信任，Lsass.exe程式可能會停止回應