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.

Dotyczy: Windows Server 2012 R2
Oryginalny numer KB: 2688798

Wprowadzenie

Wzrost konsumpcji technologii informatycznych przedsiębiorstwa (wzrost liczby urządzeń zorientowanych na konsumentów, takich jak smartfony i tablety używane w przedsiębiorstwie korporacyjnym) doprowadził do zwiększenia liczby scenariuszy, w których firmy mogą doświadczyć dużego wzrostu uwierzytelniania w starszych wersjach w ś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 wykrycia limitów czasu uwierzytelniania lub opóźnień (znanych również jako wąskie gardła maxConcurrentApi) w środowisku typowym sposobem rozwiązania problemu jest podniesienie maksymalnej dozwolonej liczby wątków procesu roboczego, które obsługują to uwierzytelnianie. Można to zrobić, zmieniając wartość rejestru MaxConcurrentApi, a następnie ponownie uruchamiając usługę Net Logon na serwerach.

Ustalenie, które serwery są ofiarami wąskiego gardła i które serwery są w rzeczywistości źródłem opóźnień wąskiego gardła, może być trudne. W tym artykule opisano sposób dostrajania wydajności dla uwierzytelniania NT LAN Manager (NTLM) przy użyciu ustawienia MaxConcurrentApi. Ten artykuł zawiera wskazówki dla administratorów dotyczące identyfikowania serwerów, na których ma zostać podnoscona wartość MaxConcurrentApi, oraz ilości, na jaką należy ustawić tę wartość.

Rozwiązanie

Aby rozwiązać ten problem, należy przejrzeć dane dotyczące wydajności pobrane ze wszystkich serwerów biorących udział w scenariuszu. 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 Dostępne są nowe wpisy dziennika zdarzeń śledzące opóźnienia i błędy uwierzytelniania NTLM w systemie Windows Server 2008 R2

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

• Zdarzenia 5818/5819: Istnieją "Kelnerzy Semafora", jeśli zdarzenia są włączone.
• Zdarzenia 5816/5817: Istnieją "przekroczenia limitu czasu Semafora".

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

• Net Logon semaphore przejmuje
• Limity czasu semafora logowania do sieci
• Net Logon average semaphore hold time (Średni czas przechowywania semafora w usłudze Net Logon)
• Czas trwania ukończonego rejestrowania wydajności mierzony w sekundach

Po uzyskaniu danych można użyć następującej formuły do oszacowania poprawnej wartości MaxConcurrentApi:(semaphore_acquires + semaphore_time-out) * average_semaphore_hold_time / time_collection_length = <New_MaxConcurrentApi_setting
Po zebraniu danych dotyczących wydajności usługi Net Logon z okresu ładowania uwierzytelniania serwera należy określić czas trwania procesu zbierania danych, przeglądając godziny rozpoczęcia i zakończenia widoku wiersza.

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

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

W tym scenariuszu formuła będzie wyglądać następująco:
(8286 + 883) *.5 / 90 =< 51

Jeśli wartość pochodna 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 na większą wartość.

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 polecenie Wartość DWORD.

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

5. W menu Edytuj kliknij przycisk Modyfikuj.

6. Wpisz nowe ustawienie MaxConcurrentApi dziesiętne, a następnie kliknij przycisk OK.

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

8. Wpisz następujące polecenie i naciśnij klawisz ENTER:
   net start netlogon

Więcej informacji

Aby bardziej szczegółowo zidentyfikować objawy po stronie klienta związane ze starszymi wąskimi gardłami uwierzytelniania, możesz użyć następującego artykułu z bazy wiedzy Knowledge Base:
975363 Po nawiązaniu połączenia z usługami uwierzytelnionymi sporadycznie jest wyświetlany monit o podanie poświadczeń lub przekroczenia limitu czasu uwierzytelniania Wąskie gardło uwierzytelniania może występować na wielu serwerach w scenariuszu. W związku z tym należy upewnić się, że wszystkie serwery w danym scenariuszu mają dane dotyczące wydajności, gdy są zajęte obsługą dużych obciążeń.

Liczniki uzyskiwania semafora, limitów czasu semafora i średniego czasu przechowywania semafora należy przejrzeć na wszystkich serwerach aplikacji, kontrolerach domeny i zaufanych kontrolerach domeny, które są zaangażowane w obsługę żądań klientów.

Dane dotyczące 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 najlepszym czasem na zebranie danych wydajności jest to, kiedy użytkownicy przychodzą do pracy i sprawdzają swoje wiadomości e-mail.

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

• Brak wartości oznacza, że nie jest wymagana żadna akcja. Liczniki Semaphore Holders i Semaphore Hold Time 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 mieć inną wartość dla każdego serwera. Taka sytuacja może być spowodowana przez wiele serwerów aplikacji uzyskujących uwierzytelnianie z jednego kontrolera domeny lub w podobnych scenariuszach, w których wiele serwerów zapewnia większe obciążenie, z którym kontroler domeny musi się zajmować.

• Zaufania. Jeśli uwierzytelnieni użytkownicy pochodzą z zaufanych domen, może to spowodować dłuższe opóźnienia, ponieważ lokalny kontroler domeny musi poczekać na odpowiedź z zaufanego kontrolera domeny, zanim lokalny kontroler domeny udzieli odpowiedzi 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 przez czas nieokreślony na starsze uwierzytelnianie.

• Kolokacja. Jeśli opóźnienie sieci istnieje i powoduje opóźnienia i wąskie gardła podczas wykonywania 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 na przykład zaufana domena ma serwery CAS programu Microsoft Exchange, 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) przez dowolny czas, a wartość Semaphore Holders jest mniejsza niż ustawienie MaxConcurrentApi na tym serwerze, wąskie gardło nie znajduje się na tym serwerze. W tym przypadku przyjrzyj się kontrolerowi 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 kontrolera domeny Semaphore Waiters i Semaphore Holder .

• Zmiany obciążenia lub konfiguracji sieci. Przyszłe zmiany obciążenia, które jest obsługiwane lub w konfiguracjach sieci, mogą spowodować opóźnienie sieci i mogą spowodować konieczność ponownego oceny poprawnego ustawienia MaxConcurrentApi. W przypadku środowisk, w których starsza wersja woluminu uwierzytelniania jest widoczna w zakresie, w jakim są analizowane ustawienia maxConcurrentApi, zdecydowanie zalecamy ciągłe monitorowanie i przeglądanie liczników obiektów wydajności usługi Net Logon. 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 przy użyciu innych metod.

• Windows Server 2008 maksimum. Maksymalne ustawienie dozwolone dla parametru MaxConcurrentApi w systemie Windows Server 2008 i nowszych wersjach systemu Windows to 150. Zastosuj poprawkę opisaną w poniższym artykule bazy wiedzy, aby mieć maksymalną dostępną wartość 150, jeśli używany serwer nie ma systemu Windows Server 2008 R2:
  975363 Po nawiązaniu połączenia z usługami uwierzytelnionymi jest wyświetlany sporadyczny monit o podanie poświadczeń lub przekroczenia limitu czasu

• Windows Server 2003 maksimum. Maksymalne ustawienie dozwolone dla parametru MaxConcurrentApi w systemie Windows Server 2003 i starszych wersjach to 10.

• Windows Server 2012 i nowsze wartości domyślne. Wartość domyślna parametru MaxConcurrentApi została zmieniona w Windows Server 2012. Jest to 10 dla serwerów członkowskich i kontrolerów domeny. Pozostaje na poziomie 1 dla stacji roboczych będących członkami.

• Windows Server 2003 i liczniki wydajności. Oryginalna wersja systemu Windows Server 2003 nie zawierała liczników wydajności usługi Net Logon. Aby ją dodać, możesz zastosować poprawkę.

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 tym samym ostatecznie zmniejszyć liczbę zastosowań semafora MaxConcurrentApi. Powtarzające się uwierzytelnianie w ten sposób można zidentyfikować przy użyciu rejestrowania debugowania usługi Net Logon. 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 Net Logon

Licznik Perfmon.msc dla uwierzytelniania NTLM w obiekcie Security System-Wide Statistics nie jest odzwierciedleniem liczby zastosowań śledzonego wątku MaxConcurrentApi. Nie istnieje korelacja jeden do jednego między użyciem semafora MaxConcurrentApi, która jest wyświetlana w liczniku wydajności usługi Net Logon, a przyrostami licznika uwierzytelniania NTLM. Licznik uwierzytelniania NTLM nie jest przydatny podczas określania najlepszej wartości MaxConcurrentApi.

Ponadto jest prawdopodobne, że 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 do 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, nawet jeśli 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 została 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