Udostępnij przez

Jak dostrajać wydajność uwierzytelniania NTLM przy użyciu ustawienia MaxConcurrentApi

W tym artykule opisano sposób dostrajania wydajności uwierzytelniania NTLM przy użyciu ustawienia MaxConcurrentApi.

Oryginalny numer KB: 2688798

Wprowadzenie

Wzrost konsumpcji technologii informatycznych przedsiębiorstwa (wzrost urządzeń zorientowanych na konsumentów, takich jak smartfony i tablety używane w przedsiębiorstwie korporacyjnym), spowodował zwiększenie liczby scenariuszy, w których firmy mogą doświadczyć dużego wzrostu starszego uwierzytelniania w swoich środowiskach przedsiębiorstwa. Ten wzrost starszego uwierzytelniania może prowadzić do problemów z wydajnością, takich jak opóźnienia lub przekroczenia limitu czasu dla klientów.

W przypadku odnajdywania limitów czasu uwierzytelniania lub opóźnień (nazywanych również wąskimi gardłami MaxConcurrentApi) w środowisku typowe rozwiązanie problemu polega na podniesieniu maksymalnej dozwolonej liczby wątków procesów roboczych obsługujących to uwierzytelnianie. Można to zrobić, zmieniając wartość rejestru MaxConcurrentApi, a następnie ponownie uruchamiając usługę Net Logon na serwerach.

Określenie, które serwery są ofiarami wąskiego gardła i które serwery są w rzeczywistości źródłem opóźnień wąskich gardeł, może być trudne. W tym artykule opisano sposób dostrajania wydajności uwierzytelniania NT LAN Manager (NTLM) przy użyciu ustawienia MaxConcurrentApi. Ten artykuł zawiera wskazówki dla administratorów w identyfikowaniu serwerów, na których należy podnieść wartość MaxConcurrentApi i kwotę, do której należy ustawić tę wartość.

Rozwiązanie

Ważne

W tej sekcji, metodzie lub w tym zadaniu podano informacje dotyczące modyfikowania rejestru. Niepoprawne zmodyfikowanie rejestru może jednak być przyczyną poważnych problemów. Dlatego należy uważnie wykonać poniższe kroki. Aby zapewnić dodatkową ochronę, utwórz kopię zapasową rejestru przed przystąpieniem do jego modyfikacji. Dzięki temu będzie można przywrócić rejestr w przypadku wystąpienia problemu. Aby uzyskać więcej informacji dotyczących wykonywania kopii zapasowej i przywracania rejestru, kliknij następujący numer artykułu w celu wyświetlenia tego artykułu z bazy wiedzy Microsoft Knowledge Base:
322756 Jak wykonać kopię zapasową rejestru i przywrócić go w systemie Windows

Aby rozwiązać ten problem, należy przejrzeć dane wydajności pobrane ze wszystkich serwerów, które są zaangażowane w scenariusz. Następnie możesz spróbować zwiększyć ustawienie MaxConcurrentApi na tych serwerach, które wykazują utratę wydajności.

Dostępne są Netlogon zdarzenia, które zgłaszają problemy z uwierzytelnianiem NTLM, zobacz:
2654097 Nowe wpisy dziennika zdarzeń, które śledzą opóźnienia i błędy uwierzytelniania NTLM w systemie Windows Server 2008 R2 są dostępne

Zdarzenia wskazują działanie dla dwóch liczników:

  • Zdarzenia 5818/5819: Istnieją "Semaphore Waiters", jeśli zdarzenia są włączone.
  • Zdarzenia 5816/5817: Istnieją "Limity czasu semafora".

Aby określić najlepszą wartość MaxConcurrentApi dla serwerów, należy połączyć i obliczyć kilka punktów danych przy użyciu formuły. Dane, które mają być używane do oszacowania parametru MaxConcurrentApi, są następujące:

  • Net Logon semaphore uzyskuje
  • Limity czasu semafora logowania sieci
  • Średni czas wstrzymania semafora logowania netto
  • Czas trwania rejestrowania wydajności, który został ukończony, mierzony w sekundach

Po uzyskaniu danych można użyć następującej formuły do oszacowania prawidłowej wartości MaxConcurrentApi:(semaphore_acquires + semaphore_time-outs) * average_semaphore_hold_time / time_collection_length = New_MaxConcurrentApi_setting <
Po zebraniu danych wydajności logowania net z momentu, gdy serwer był obciążony uwierzytelnianiem, należy określić czas trwania procesu zbierania danych, patrząc na początek i czas zakończenia widoku wiersza.

Uwaga 16.

Symbole zastępcze semaphore_acquires i semaphore_time-out reprezentują liczby skumulowane, które wskazują, ile limitów czasu wystąpiło w okresie istnienia kanału zabezpieczeń. W związku z tym liczby najprawdopodobniej nie będą rozpoczynać się od zera w zebranych danych. Numer początkowy musi zostać odejmowany od numeru końcowego, gdy użyjesz widoku wiersza w monitor wydajności (Perfmon.msc). Następnie użyjesz tej liczby obliczeniowej w formule dla nowego ustawienia MaxConcurrentApi. Aby określić liczbę limitów czasu, które wystąpiły podczas zbierania danych, użyj widoku wiersza w pliku Perfmon.msc, a następnie odejmij wskaźnik myszy nad linią tego licznika na końcu i początku, a następnie odejmij liczbę początkową od liczby końcowej. Wynik ten jest liczbą, którą należy umieścić w równaniu.

Średni czas wstrzymania semafora można określić, zmieniając domyślny widok z Widoku wiersza na Widok raportu w pliku Perfmon.msc. Na przykład rozpatrzmy następujący scenariusz.

  • Semafor uzyskuje wartość 8286.
  • Wartość limitu czasu semafora wynosi 883.
  • Średni czas przechowywania semafora wynosi .5 (czyli pół sekundy).
  • Czas trwania raportowania wynosi 90 sekund.

W tym scenariuszu formuła będzie następująca:
(8,286 + 883) *.5 / 90 =< 51

Jeśli wartość pochodząca z formuły to 150 lub większa, należy dodać więcej serwerów do obsługi starszego obciążenia uwierzytelniania.

Jeśli wartość jest mniejsza niż 150, należy zmienić wartość rejestru MaxConcurrentApi na tym serwerze na wartość sugerowaną przez formułę lub większą wartość.

Uwaga 16.

Jeśli zdecydujesz się zwiększyć wartość MaxConcurrentApi do większej niż 10, obciążenie i wydajność żądanego ustawienia powinny być testowane w środowisku nieprodukcyjnym przed wdrożeniem zmiany w środowisku produkcyjnym. Zaleca się upewnienie się, że zwiększenie tej wartości nie powoduje innych wąskich gardeł zasobów. Ponadto należy pamiętać, że warunki obciążenia mogą ulec zmianie w zależności od każdego scenariusza i środowiska biznesowego. W związku z tym wartość MaxConcurrentApi może wymagać innego ustawienia w późniejszym terminie, jeśli obciążenie usługi ulegnie zmianie.

Aby zmienić ustawienie MaxConcurrentApi, wykonaj następujące kroki:

  1. Kliknij przycisk Start, kliknij polecenie Uruchom, wpisz polecenie regedit, a następnie kliknij przycisk OK.

  2. Odszukaj, a następnie kliknij następujący podklucz rejestru: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

  3. W menu Edycja wskaż polecenie Nowy, a następnie kliknij pozycję Wartość DWORD.

  4. Wpisz MaxConcurrentApi, a następnie naciśnij Enter.

  5. W menu Edycja kliknij pozycję Modyfikuj.

  6. Wpisz nowe ustawienie MaxConcurrentApi w przecinku, a następnie kliknij przycisk OK.

  7. W wierszu polecenia wpisz następujące polecenie, a następnie naciśnij Enter:
    net stop netlogon

  8. Wprowadź następujące polecenie i naciśnij klawisz Enter:
    net start netlogon

Więcej informacji

Poniższy artykuł z bazy wiedzy umożliwia bardziej szczegółowe zidentyfikowanie objawów po stronie klienta starszych wąskich gardeł uwierzytelniania:
975363 Sporadycznie pojawia się monit o podanie poświadczeń lub przekroczenia limitu czasu podczas nawiązywania połączenia z uwierzytelnionymi usługami Wąskie gardło uwierzytelniania może znajdować się na wielu serwerach w tym scenariuszu. W związku z tym należy upewnić się, że wszystkie serwery w danym scenariuszu mają przejrzene dane dotyczące wydajności, podczas gdy są zajęte dużym obciążeniem obsługi.

Liczniki pozyskiwania semaforów, przekroczenia limitu czasu semafora i średni czas wstrzymania semafora muszą być sprawdzane na wszystkich serwerach aplikacji, kontrolerach domeny i zaufanych kontrolerach domeny, które są zaangażowane w obsługę żądań klientów.

Dane wydajności muszą być śledzone, gdy serwery są obciążone dużym obciążeniem. Duże obciążenie występuje, gdy serwery widzą najwięcej żądań klientów. Na przykład w scenariuszu serwera poczty e-mail najlepszy czas zbierania danych wydajności to czas, w jaki użytkownicy przychodzą do pracy i sprawdzają swoje wiadomości e-mail.

Dodatkowe elementy do rozważenia są następujące:

  • Żadne wartości nie oznaczają, że nie jest wymagana żadna akcja. Liczniki Czas wstrzymania semafora i semafora nie będą pokazywać żadnych wartości, chyba że na serwerze występuje trwałe obciążenie. Jeśli nie ma żadnych wartości, nie jest wymagana żadna zmiana wartości MaxConcurrentApi.

  • Jeden rozmiar nie pasuje do wszystkich. Wartość MaxConcurrentApi może być inna dla każdego serwera. Taka sytuacja może być spowodowana przez wiele serwerów aplikacji uzyskujących uwierzytelnianie z jednego kontrolera domeny lub podobnych scenariuszy, w których wiele serwerów zapewnia większą ilość obciążenia, z którym kontroler domeny musi obsługiwać.

  • Zaufania. Jeśli użytkownicy, którzy są uwierzytelnieni, pochodzą z zaufanych domen, może to spowodować dłuższe opóźnienia, ponieważ lokalny kontroler domeny musi czekać na odpowiedź z zaufanego kontrolera domeny, zanim lokalny kontroler domeny udostępni odpowiedź na serwer aplikacji.

  • Opóźnienie sieci. Opóźnienie sieci może również odgrywać ważną rolę w wywoływaniu wąskich gardeł MaxConcurrentApi. Ten problem może wystąpić, gdy semafor MaxConcurrentApi używa licznika limitu czasu opartego na czasie, aby klienci nie czekali na czas nieokreślony na potrzeby starszego uwierzytelniania.

  • Kolokacja. Jeśli opóźnienie sieci istnieje i powoduje opóźnienia i wąskie gardła podczas kończenia wątków MaxConcurrentApi, typowym rozwiązaniem jest umieszczenie serwerów w tej samej lokalizacji fizycznej, aby zmniejszyć opóźnienie sieci. W modelu domeny, w którym zaufana domena ma serwery CAS programu Microsoft Exchange, na przykład, a domena użytkownika znajduje się w innym regionie lub lokacji usługi Active Directory, oznaczałoby to umieszczenie kontrolerów domeny użytkownika w tej samej lokalizacji fizycznej i lokacji usługi Active Directory co serwery CAS programu Exchange i ich kontrolery domeny.

  • Możliwe opóźnienie podrzędne. Jeśli wartość licznika Semaphore Waiters jest stale większa niż 0 (zero) w dowolnym momencie, a wartość Posiadacze semafora jest mniejsza niż ustawienie MaxConcurrentApi na tym serwerze, wąskie gardło nie znajduje się na tym serwerze. W takim przypadku należy zwrócić uwagę na kontroler domeny, który jest cytowany w nazwie licznika, który jest wymieniony jako w pełni kwalifikowana nazwa domeny komputera hosta. Należy przejrzeć dane wydajności semaforów i posiadaczy semaforów kontrolera domeny.

  • Zmiany obciążenia lub konfiguracji sieci. Przyszłe zmiany obciążenia, które są obsługiwane lub w konfiguracjach sieci mogą powodować opóźnienie sieci i mogą prowadzić do konieczności ponownego określenia prawidłowego ustawienia MaxConcurrentApi. W przypadku środowisk, w których widoczny jest starszy wolumin uwierzytelniania w zakresie, w jakim są badane ustawienia MaxConcurrentApi, zdecydowanie zalecamy ciągłe monitorowanie i przeglądanie liczników obiektów wydajności logowania net. Można to zrobić przy użyciu zaplanowanych niestandardowych modułów zbierających dane Perfmon.msc przy użyciu programu Microsoft System Center Operations Manager lub innych metod.

  • Maksymalna wartość systemu Windows Server 2008. Ustawienie maksymalne dozwolone dla parametru MaxConcurrentApi w systemie Windows Server 2008 i nowszych wersjach systemu Windows to 150. Zastosuj poprawkę opisaną w następującym artykule z bazy wiedzy, aby mieć 150 maksymalnych dostępnych ustawień, jeśli używany serwer nie jest uruchomiony w systemie Windows Server 2008 R2:
    975363 Po nawiązaniu połączenia z uwierzytelnionymi usługami jest wyświetlany sporadycznie monit o przekroczenie limitu czasu poświadczeń lub środowiska

  • Maksymalna wartość systemu Windows Server 2003. Maksymalnym ustawieniem dozwolonym dla parametru MaxConcurrentApi w systemie Windows Server 2003 i we wcześniejszych wersjach jest 10.

  • Windows Server 2012 i nowsze wartości domyślne. Wartość domyślna maxConcurrentApi została zmieniona w systemie Windows Server 2012. Jest to 10 dla serwerów członkowskich i kontrolerów domeny. Pozostaje na 1 dla stacji roboczych składowych.

  • Windows Server 2003 i liczniki wydajności. Oryginalna wersja systemu Windows Server 2003 nie zawiera liczników wydajności net logon. Możesz zastosować poprawkę, aby ją dodać.

Identyfikowanie nieautoryzowanych lub nieznanych klientów lub usług, które wykonują powtarzające się i ciągłe uwierzytelnianie NTLM, może być przydatne, gdy chcesz zmniejszyć ogólne obciążenie uwierzytelniania NTLM, a zatem ostatecznie zmniejszyć liczbę zastosowań semafora MaxConcurrentApi. Powtórzone uwierzytelnianie w ten sposób można zidentyfikować przy użyciu rejestrowania debugowania usługi logowania net. Aby uzyskać więcej informacji na temat używania pliku Netlogon.log do debugowania usługi Net Logon, kliknij następujący numer artykułu, aby wyświetlić artykuł w bazie wiedzy Microsoft Knowledge Base:
109626 Włączanie rejestrowania debugowania dla usługi logowania net

Licznik Perfmon.msc dla uwierzytelniania NTLM w obiekcie Security System-Wide Statistics nie jest odzwierciedleniem liczby zastosowań śledzonego wątku MaxConcurrentApi. Nie ma korelacji "jeden do jednego" między użyciem semafora MaxConcurrentApi, które jest wyświetlane w liczniku wydajności logowania net i przyrostach licznika uwierzytelniania NTLM. Licznik uwierzytelniania NTLM nie jest przydatny podczas określania najlepszej wartości MaxConcurrentApi.

Ponadto prawdopodobnie starsze limity czasu wydajności uwierzytelniania powiązane z parametrem MaxConcurrentApi będą widoczne, ale nie zostaną odzwierciedlone w żadnym liczniku wydajności innym niż licznik logowania sieci. Oznacza to, że inne metryki wydajności, takie jak użycie procesora CPU i użycie dysku i sieci, mogą nie wykazywać obciążenia, mimo że obciążenie MaxConcurrentApi jest duże, a użytkownicy mają problemy.

Dodatkową procedurę minimalizacji można wykonać na kontrolerach domeny, które mają wpisy w dzienniku debugowania usługi Net Logon, które wskazują, że klienci przesyłają <null>\username zamiast domainname\username. Ta procedura jest opisana w następującym artykule w bazie wiedzy Microsoft Knowledge Base:
923241 Proces Lsass.exe może przestać odpowiadać, jeśli masz wiele zewnętrznych relacji zaufania na kontrolerze domeny usługi Active Directory

  • Last updated on