Prestaties afstemmen voor NTLM-verificatie met behulp van de instelling MaxConcurrentApi

  • Artikel

In dit artikel wordt beschreven hoe u prestaties kunt afstemmen voor NTLM-verificatie met behulp van de instelling MaxConcurrentApi.

Van toepassing op: Windows Server 2012 R2
Origineel KB-nummer: 2688798

Inleiding

Een toename in consumerisering van bedrijfsinformatietechnologie (toename van consumentengeoriënteerde apparaten zoals smartphones en tablets die in de onderneming worden gebruikt) heeft geleid tot een toename van het aantal scenario's waarin bedrijven een grote toename van verouderde verificatie in hun bedrijfsomgevingen kunnen ervaren. Deze toename in verouderde verificatie kan leiden tot prestatieproblemen, zoals vertragingen of time-outs voor clients.

Wanneer u verificatietime-outs of vertragingen (ook wel MaxConcurrentApi-knelpunten genoemd) in een omgeving ontdekt, is de gebruikelijke manier om het probleem op te lossen het verhogen van het maximum aantal toegestane werkrolthreads die deze verificatie uitvoeren. U doet dit door de registerwaarde MaxConcurrentApi te wijzigen en vervolgens de netaanmeldingsservice op de servers opnieuw te starten.

Het kan lastig zijn om vast te stellen welke servers het slachtoffer zijn van het knelpunt en welke servers daadwerkelijk de oorzaak van de knelpuntvertragingen zijn. In dit artikel wordt beschreven hoe u prestaties kunt afstemmen voor NT LAN Manager -verificatie (NTLM) met behulp van de instelling MaxConcurrentApi. Dit artikel bevat richtlijnen voor beheerders bij het identificeren van de servers waarop de MaxConcurrentApi-waarde moet worden opgehaald en het bedrag waarop die waarde moet worden ingesteld.

Oplossing

Belangrijk

Deze sectie, methode of taak bevat stappen voor het bewerken van het register. Als u het register op onjuiste wijze wijzigt, kunnen er echter grote problemen optreden. Het is dan ook belangrijk dat u deze stappen zorgvuldig uitvoert. Maak een back-up van het register voordat u wijzigingen aanbrengt. Als er een probleem optreedt, kunt u het register altijd nog herstellen. Als u meer informatie wilt over het maken van een back-up van het register en het herstellen van het register, klikt u op de volgende artikelnummers in de Microsoft Knowledge Base:
322756 Een back-up van het register maken en het register terugzetten in Windows

Om dit probleem op te lossen, moet u de prestatiegegevens controleren die zijn genomen van alle servers die betrokken zijn bij het scenario. Vervolgens kunt u proberen de instelling MaxConcurrentApi te verhogen op die servers die een prestatieverlies vertonen.

Er zijn Netlogon gebeurtenissen beschikbaar die NTLM-verificatieproblemen melden. Zie:
2654097 Nieuwe gebeurtenislogboekvermeldingen die vertragingen en fouten in NTLM-verificatie bijhouden in Windows Server 2008 R2 beschikbaar zijn

De gebeurtenissen geven de activiteit voor twee tellers aan:

  • Gebeurtenissen 5818/5819: Er zijn 'Semafoorwachters', als de gebeurtenissen zijn ingeschakeld.
  • Gebeurtenissen 5816/5817: Er zijn 'Semafoor-time-outs'.

Als u de beste MaxConcurrentApi-waarde voor uw servers wilt bepalen, moeten verschillende gegevenspunten worden samengevoegd en berekend met behulp van een formule. De gegevens die moeten worden gebruikt voor het schatten van MaxConcurrentApi zijn als volgt:

  • Net Logon-semafoor verkrijgt
  • Time-outs voor netaanmeldmaafoor
  • Gemiddelde wachttijd van net-aanmeldingstijd van semafoor
  • Duur van de prestatielogboekregistratie die is voltooid, gemeten in seconden

Nadat de gegevens zijn verkregen, kan de volgende formule worden gebruikt om de juiste MaxConcurrentApi-waarde te schatten:(semaphore_acquires + semaphore_time-outs) * average_semaphore_hold_time / time_collection_length = <New_MaxConcurrentApi_setting
Nadat u de prestatiegegevens voor netaanmelding hebt verzameld op het moment dat de server onder de verificatiebelasting stond, moet u de duur van het gegevensverzamelingsproces bepalen door te kijken naar de begin- en eindtijd van de regelweergave.

Opmerking

De tijdelijke aanduidingen semaphore_acquires en semaphore_time-outs vertegenwoordigen cumulatieve getallen die aangeven hoeveel time-outs zich hebben voorgedaan tijdens de levensduur van een beveiligingskanaal. Daarom beginnen de getallen waarschijnlijk niet bij nul in de verzamelde gegevens. Het beginnummer moet worden afgetrokken van het eindnummer wanneer u De lijnweergave gebruikt in de prestatiemeter (Perfmon.msc). Vervolgens gebruikt u dit berekende getal in de formule voor de nieuwe instelling MaxConcurrentApi. Als u het aantal time-outs wilt bepalen dat is opgetreden tijdens het verzamelen van gegevens, gebruikt u Regelweergave in Perfmon.msc en plaatst u de muisaanwijzer op de regel voor die teller aan het einde en het begin en trekt u het beginnummer af van het eindnummer. Dat resultaat is het getal dat in de vergelijking moet worden opgenomen.

De gemiddelde tijd voor het bewaren van semafoor kan worden bepaald door de standaardweergave te wijzigen van Regelweergave in Rapportweergave in Perfmon.msc. Kijk eens naar het volgende scenario:

  • De semafoor krijgt een waarde van 8.286.
  • De time-outwaarde voor semafoor is 883.
  • De gemiddelde tijd van de semafoorbeschikbaarheid is .5 (dat wil gezegd, een halve seconde).
  • De duur van de rapportage is 90 seconden.

In dit scenario ziet de formule er als volgt uit:
(8.286 + 883) *.5 / 90 =< 51

Als de waarde die is afgeleid van de formule 150 of groter is, moet u meer servers toevoegen om de verouderde verificatiebelasting te onderhouden.

Als de waarde kleiner is dan 150, moet u de registerwaarde MaxConcurrentApi op die server wijzigen in de waarde die wordt voorgesteld door de formule of in een grotere waarde.

Opmerking

Als u besluit om de waarde MaxConcurrentApi te verhogen tot meer dan 10, moeten de belasting en de prestaties van de gewenste instelling worden getest in een niet-productieomgeving voordat u de wijziging in een productieomgeving implementeert. Dit wordt aanbevolen om ervoor te zorgen dat het verhogen van deze waarde geen andere resourceknelpunten veroorzaakt. Houd er ook rekening mee dat de belastingsvoorwaarden kunnen veranderen op basis van elk scenario en de bedrijfsomgeving. Daarom moet de waarde MaxConcurrentApi mogelijk op een later tijdstip een andere instelling hebben als de servicebelasting wordt gewijzigd.

Voer de volgende stappen uit om de instelling MaxConcurrentApi te wijzigen:

  1. Klik op Start, klik op Uitvoeren, geef regedit in en klik vervolgens op OK.

  2. Zoek en klik op de volgende registersubsleutel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

  3. Open het menu Bewerken, wijs Nieuw aan en klik op DWORD Value.

  4. Typ MaxConcurrentApi en druk op Enter.

  5. Klik in het menu Bewerken op Wijzigen.

  6. Typ de nieuwe instelling MaxConcurrentApi in decimalen en klik vervolgens op OK.

  7. Typ bij een opdrachtprompt de volgende opdracht en druk op Enter:
    net stop netlogon

  8. Typ de volgende opdracht en druk daarna op Enter.
    net start netlogon

Meer informatie

U kunt het volgende Knowledge Base-artikel gebruiken om de symptomen aan de clientzijde van verouderde verificatieknelpunten in meer detail te identificeren:
975363 U wordt af en toe gevraagd om referenties of ondervindt time-outs wanneer u verbinding maakt met geverifieerde services Het verificatieknelpunt kan zich op meerdere servers in het scenario bevinden. Daarom moet u ervoor zorgen dat op alle servers in een bepaald scenario de prestatiegegevens worden gecontroleerd terwijl ze bezig zijn met het verwerken van zware belasting.

De tellers voor semafoor-acquire, voor time-outs van semafoor en voor de gemiddelde bewaringstijd van semafoor moeten worden gecontroleerd op alle toepassingsservers, domeincontrollers en vertrouwde domeincontrollers die betrokken zijn bij het onderhoud van clientaanvragen.

De prestatiegegevens moeten worden bijgehouden terwijl de servers zwaar worden belast. Zware belasting treedt op wanneer de servers de meeste clientaanvragen zien. In een e-mailserverscenario is het beste moment om de prestatiegegevens te verzamelen wanneer gebruikers op het werk aankomen en hun e-mailberichten controleren.

Aanvullende items ter overweging zijn als volgt:

  • Geen waarden betekent dat er geen actie nodig is. De tellers semafoorhouders en Semafoor bewaringstijd geven geen waarden weer, tenzij er sprake is van aanhoudende belasting op een server. Als er geen waarden aanwezig zijn, is er geen wijziging in de waarde MaxConcurrentApi nodig.

  • Eén maat past niet op alles. De waarde MaxConcurrentApi moet mogelijk een andere waarde zijn voor elke server. Deze situatie kan worden veroorzaakt doordat meerdere toepassingsservers verificatie verkrijgen van één domeincontroller of door vergelijkbare scenario's waarin meerdere servers een grotere hoeveelheid belasting bieden waarmee de domeincontroller moet omgaan.

  • Vertrouwensrelaties. Als de gebruikers die worden geverifieerd afkomstig zijn van vertrouwde domeinen, kan dit leiden tot langere vertragingen, omdat de lokale domeincontroller moet wachten op het antwoord van de vertrouwde domeincontroller voordat de lokale domeincontroller het antwoord aan de toepassingsserver levert.

  • Netwerklatentie. Netwerklatentie kan ook een belangrijke rol spelen bij het veroorzaken van MaxConcurrentApi-knelpunten. Dit probleem kan optreden wanneer de MaxConcurrentApi-semafoor gebruikmaakt van een time-outteller op basis van tijd, zodat clients niet voor onbepaalde tijd op verouderde verificatie wachten.

  • Collocatie. Als er netwerklatentie bestaat en vertragingen en knelpunten veroorzaakt bij het voltooien van MaxConcurrentApi-threads, is een algemene oplossing om de servers op dezelfde fysieke locatie te plaatsen, zodat de netwerklatentie wordt verminderd. In een domeinmodel waarin een vertrouwd domein bijvoorbeeld Microsoft Exchange CAS-servers heeft en het domein van de gebruiker zich in een andere regio of Active Directory-site bevindt, betekent dit dat de domeincontrollers van de gebruiker op dezelfde fysieke locatie en Active Directory-site worden geplaatst als de Exchange CAS-servers en hun domeincontrollers.

  • Mogelijke downstreamvertraging. Als de waarde van de teller voor semafoorwachters voortdurend groter is dan 0 (nul) en de waarde semafoorhouders kleiner is dan de instelling MaxConcurrentApi op die server, bevindt het knelpunt zich niet op die server. In dit geval kijkt u naar de domeincontroller die wordt vermeld in de tellernaam die wordt vermeld als een volledig gekwalificeerde domeinnaam van de hostcomputer. De prestatiegegevens van de semafoorwachters en semafoorhouders van die domeincontroller moeten worden gecontroleerd.

  • Wijzigingen in de belasting of in de netwerkconfiguratie. Toekomstige wijzigingen in de belasting die wordt uitgevoerd of in netwerkconfiguraties kunnen leiden tot netwerklatentie en kunnen ertoe leiden dat de juiste MaxConcurrentApi-instelling opnieuw moet worden gecontroleerd. Voor omgevingen waarin een verouderd verificatievolume wordt gezien in de mate waarin MaxConcurrentApi-instellingen worden onderzocht, raden we u ten zeerste aan om de prestatiemeteritems voor netaanmelding voortdurend te controleren en te controleren. U kunt dit doen met behulp van geplande aangepaste Perfmon.msc-gegevensverzamelaars, met behulp van Microsoft System Center Operations Manager of met andere methoden.

  • Windows Server 2008 maximum. De maximuminstelling die is toegestaan voor MaxConcurrentApi in Windows Server 2008 en in latere versies van Windows is 150. Pas de hotfix toe die wordt beschreven in het volgende Knowledge Base-artikel om de instelling maximaal 150 beschikbaar te hebben als windows server 2008 R2 niet wordt uitgevoerd op de server die u gebruikt:
    975363 U wordt af en toe gevraagd om referenties of time-outs wanneer u verbinding maakt met geverifieerde services

  • Windows Server 2003 maximum. De maximuminstelling die is toegestaan voor MaxConcurrentApi in Windows Server 2003 en in eerdere versies is 10.

  • Windows Server 2012 en nieuwere standaardinstellingen. De standaardwaarde voor MaxConcurrentApi is gewijzigd in Windows Server 2012. Dit is 10 voor lidservers en domeincontrollers. Dit blijft op 1 voor lidwerkstations.

  • Windows Server 2003 en prestatiemeteritems. De oorspronkelijke versie van Windows Server 2003 bevatte niet de prestatiemeteritems voor netaanmelding. U kunt een hotfix toepassen om deze toe te voegen.

Het identificeren van niet-geautoriseerde of onbekende clients of services die herhaalde en continue NTLM-verificatie uitvoeren, kan handig zijn als u de totale belasting van NTLM-verificatie wilt verminderen en daarom uiteindelijk het aantal gebruik van MaxConcurrentApi-semafoor wilt verminderen. Herhaalde verificatie op die manier kan worden geïdentificeerd met behulp van logboekregistratie voor foutopsporing in de Net-aanmeldingsservice. Klik op het volgende artikelnummer om het artikel in de Microsoft Knowledge Base weer te geven voor meer informatie over het gebruik van het Netlogon.log-bestand om fouten op te sporen in de service Voor netaanmelding:
109626 Logboekregistratie voor foutopsporing inschakelen voor de netaanmeldingsservice

De teller Perfmon.msc voor NTLM-verificaties onder het object Security System-Wide Statistics is geen weerspiegeling van het aantal toepassingen van de bijgehouden thread MaxConcurrentApi. Er is geen een-op-een-correlatie tussen het gebruik van de Semafoor MaxConcurrentApi die wordt weergegeven in het prestatiemeteritem voor netaanmelding en de stappen van het NTLM-verificatiemeteritem. Het NTLM-verificatiemeteritem is niet nuttig bij het bepalen van de beste MaxConcurrentApi-waarde.

Bovendien is het waarschijnlijk dat verouderde time-outs voor verificatieprestaties die zijn gerelateerd aan MaxConcurrentApi worden weergegeven, maar niet worden weergegeven in een ander prestatiemeteritems dan de net-aanmeldingsteller. Dit betekent dat andere metrische prestatiegegevens, zoals CPU-gebruik en schijf- en netwerkgebruik, geen belasting kunnen vertonen, hoewel de MaxConcurrentApi-belasting zwaar is en gebruikers problemen ondervinden.

Een extra minimalisatieprocedure kan worden uitgevoerd op domeincontrollers met vermeldingen in het foutopsporingslogboek van de Net Logon-service die aangeven dat clients verzenden <null>\username in plaats van domainname\username. Deze procedure wordt beschreven in het volgende artikel in de Microsoft Knowledge Base:
923241 Het Lsass.exe-proces reageert mogelijk niet meer als u veel externe vertrouwensrelaties op een Active Directory-domeincontroller hebt