Delen via

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

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

Oorspronkelijk KB-nummer: 2688798

Inleiding

Een toename van de consumptie van bedrijfsinformatietechnologie (toename van consumentengeoriënteerde apparaten zoals smartphones en tablets die worden gebruikt in de onderneming) heeft geleid tot het verhogen van het aantal scenario's waarin bedrijven een grote toename van verouderde verificatie in hun bedrijfsomgevingen kunnen ervaren. Deze toename van 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 detecteert, is de gebruikelijke manier om het probleem op te lossen door de maximaal toegestane werkrolthreads te verhogen die door die verificatie worden gebruikt. U doet dit door de registerwaarde MaxConcurrentApi te wijzigen en vervolgens de Net-aanmeldingsservice op de servers opnieuw op te starten.

Het kan lastig zijn om te identificeren welke servers slachtoffers zijn van het knelpunt en welke servers daadwerkelijk de bron zijn van de knelpuntvertragingen. 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 gegenereerd 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. Zorg er daarom voor dat u de volgende stappen zorgvuldig volgt. Voor optimale veiligheid maakt u dagelijks een back-up van het register voordat u het wijzigt. U kunt dan het register herstellen als er een probleem optreedt. 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 reservekopie van het register maken en het register herstellen in Windows

U kunt dit probleem oplossen door de prestatiegegevens te bekijken die zijn opgehaald van alle servers die betrokken zijn in het scenario. Vervolgens kunt u proberen om de MaxConcurrentApi-instelling te verhogen op die servers die een verlies in prestaties laten zien.

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

De gebeurtenissen geven de activiteit voor twee tellers aan:

  • Gebeurtenissen 5818/5819: Er zijn 'Semaphore Waiters', als de gebeurtenissen zijn ingeschakeld.
  • Gebeurtenissen 5816/5817: Er zijn "Semaphore Time-outs".

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

  • Net Logon semaphore verkrijgt
  • Time-outs voor netaanmelding
  • Net Logon average semaphore hold time
  • 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 vanaf het moment dat de server werd belast met verificatie, moet u de duur van het proces voor het verzamelen van gegevens bepalen door naar de begin- en eindtijd van de lijnweergave te kijken.

Notitie

De tijdelijke aanduidingen semaphore_acquires en semaphore_time-outs vertegenwoordigen cumulatieve getallen die aangeven hoeveel time-outs er zijn opgetreden 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 in de prestatiemeter (Perfmon.msc) gebruikt. Vervolgens gebruikt u dit berekende getal in de formule voor de nieuwe MaxConcurrentApi-instelling. Als u het aantal time-outs wilt bepalen dat is opgetreden tijdens het verzamelen van gegevens, gebruikt u de lijnweergave 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. Dit resultaat is het getal dat in de vergelijking moet worden geplaatst.

De gemiddelde tijd van de semaphore bewaring kan worden bepaald door de standaardweergave te wijzigen van de regelweergave in de rapportweergave in Perfmon.msc. Kijk eens naar het volgende scenario:

  • De semaphore verkrijgt een waarde van 8.286.
  • De time-outwaarde van de semaphore is 883.
  • De gemiddelde semaphore bewaringstijd is .5 (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 verwerken.

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 een grotere waarde.

Notitie

Als u besluit de MaxConcurrentApi-waarde te verhogen naar 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 knelpunten voor resources veroorzaakt. Houd er bovendien rekening mee dat de belastingsvoorwaarden kunnen veranderen op basis van elk scenario en elke bedrijfsomgeving. Daarom moet de waarde MaxConcurrentApi op een latere datum mogelijk een andere instelling hebben als de servicebelasting verandert.

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. Wijs Nieuw aan in het menu Bewerken, en klik vervolgens op DWORD-waarde.

  4. Typ MaxConcurrentApi en druk op Enter.

  5. Klik in het menu Bewerken op Wijzigen.

  6. Typ de nieuwe instelling MaxConcurrentApi in decimaal 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 in 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 om referenties gevraagd of er time-outs optreden wanneer u verbinding maakt met geverifieerde services. Het knelpunt voor verificatie kan zich in het scenario op meerdere servers bevinden. Daarom moet u ervoor zorgen dat alle servers in een bepaald scenario hun prestatiegegevens hebben gecontroleerd terwijl ze druk bezig zijn met het verwerken van zware belasting.

De tellers voor semaphore acquire, voor time-outs van deemafore en voor de gemiddelde semaphore bewaringstijd moeten worden gecontroleerd op alle toepassingsservers, domeincontrollers en vertrouwde domeincontrollers die betrokken zijn bij het verwerken 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 kunt u bijvoorbeeld het beste de prestatiegegevens verzamelen wanneer gebruikers op het werk aankomen en hun e-mailberichten controleren.

Aanvullende items ter overweging zijn als volgt:

  • Geen waarden betekenen dat er geen actie nodig is. De Semaphore Holders en Semaphore Hold Time tellers tonen geen waarden tenzij er een aanhoudende belasting op een server is. Als er geen waarden aanwezig zijn, is er geen wijziging in de MaxConcurrentApi-waarde nodig.

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

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

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

  • Collocatie. Als 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 tellerwaarde Semaphore Waiters voortdurend groter is dan 0 (nul) en de waarde Semaphore Holders kleiner is dan de instelling MaxConcurrentApi op die server, bevindt het knelpunt zich niet op die server. Kijk in dit geval naar de domeincontroller die wordt genoemd in de tellernaam die wordt vermeld als een volledig gekwalificeerde domeinnaam van een hostcomputer. De prestatiegegevens van die domeincontroller Semaphore Waiters en Semaphore Holders moeten worden gecontroleerd.

  • Wijzigingen in de belasting of in de netwerkconfiguratie. Toekomstige wijzigingen in de belasting die wordt verwerkt of in netwerkconfiguraties, kunnen netwerklatentie veroorzaken en kunnen leiden tot een noodzaak om de juiste MaxConcurrentApi-instelling opnieuw te controleren. Voor omgevingen waarin het verouderde verificatievolume wordt gezien voor zover maxConcurrentApi-instellingen worden onderzocht, raden we u ten zeerste aan voortdurend de prestatiemeteritems van Net Logon 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 maximale instelling 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 maximaal beschikbare instelling van 150 te hebben als windows Server 2008 R2 niet wordt uitgevoerd op de server die u gebruikt:
    975363 U wordt af en toe om referenties gevraagd of er time-outs optreden wanneer u verbinding maakt met geverifieerde services

  • Windows Server 2003 maximum. De maximale instelling 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. Het is 10 voor lidservers en domeincontrollers. Het blijft op 1 voor lidwerkstations.

  • Windows Server 2003 en prestatiemeteritems. De oorspronkelijke versie van Windows Server 2003 bevat geen 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 MaxConcurrentApi-semaphore-toepassingen wilt verminderen. Herhaalde verificatie op die manier kan worden geïdentificeerd met behulp van logboekregistratie voor foutopsporing van net-aanmeldingsservice. Voor meer informatie over het gebruik van het Netlogon.log-bestand voor het opsporen van fouten in de Net-aanmeldingsservice, klikt u op het volgende artikelnummer om het artikel in de Microsoft Knowledge Base weer te geven:
109626 logboekregistratie voor foutopsporing inschakelen voor de Net-aanmeldingsservice

De prestatiemeteritem 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 MaxConcurrentApi-semaphore-gebruik dat wordt weergegeven in het prestatiemeteritem Net Logon en de NTLM-verificatieteller incrementen. Het NTLM-verificatiemeteritem is niet handig 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 andere prestatiemeteritems dan de netaanmeldingsteller. Dit betekent dat andere prestatiegegevens, zoals CPU-gebruik en schijf- en netwerkgebruik, mogelijk geen belasting vertonen, zelfs als de MaxConcurrentApi-belasting zwaar is en gebruikers problemen ondervinden.

Er kan een extra minimalisatieprocedure worden uitgevoerd op domeincontrollers met vermeldingen in het foutopsporingslogboek van de Net Logon-service die aangeven dat clients <null>\username verzenden 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 hebt op een Active Directory-domeincontroller

  • Last updated on