共用方式為

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

  • 發行項

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

適用：Windows Server 2012 R2
原始 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 semaphore acquires
  • Net Logon semaphore time-outs
  • Net Logon 平均號誌保留時間
  • 已完成的效能記錄持續時間，以秒為單位

取得數據之後，可以使用下列公式來估計正確的 MaxConcurrentApi 值： (semaphore_acquires + semaphore_time輸出) * 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 持有者 值小於該伺服器上的 MaxConcurrentApi 設定，則瓶頸不會位於該伺服器上。 在此情況下，請查看計數器名稱中所引用的域控制器，此計數器名稱會列為主計算機完整功能變數名稱。 應檢閱域控制器的 號誌等候程式 和 號誌持有者 效能數據。

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

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

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

  • Windows Server 2012和更新的預設值。 MaxConcurrentApi 的預設值已在 Windows Server 2012 中變更。 成員伺服器和域控制器為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 性能計數器中顯示的 MaxConcurrentApi 號誌使用方式與 NTLM 驗證計數器遞增之間沒有一對一的相互關聯。 NTLM 驗證計數器不適用於判斷最佳的 MaxConcurrentApi 值。

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

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