Så här gör du prestandajustering för NTLM-autentisering med inställningen MaxConcurrentApi

Den här artikeln beskriver hur du gör prestandajustering för NTLM-autentisering med hjälp av inställningen MaxConcurrentApi.

Gäller för: Windows Server 2012 R2
Ursprungligt KB-nummer: 2688798

Inledning

En ökning av konsumtionen av företagsinformationsteknik (ökning av konsumentorienterade enheter som smartphones och surfplattor som används i företaget) har lett till att antalet scenarier där företag kan uppleva en stor ökning av äldre autentisering i företagsmiljöer har ökat. Den här ökningen av äldre autentisering kan leda till prestandaproblem som fördröjningar eller tidsgränser för klienter.

När du upptäcker tidsgränser för autentisering eller fördröjningar (även kallat MaxConcurrentApi-flaskhalsar) i en miljö är det vanliga sättet att lösa problemet att skapa maximalt antal tillåtna arbetstrådar som hanterar den autentiseringen. Du gör det genom att ändra registervärdet MaxConcurrentApi och sedan starta om tjänsten Net Logon på servrarna.

Det kan vara svårt att identifiera vilka servrar som är offer för flaskhalsen och vilka servrar som faktiskt är orsaken till flaskhalsfördröjningarna. Den här artikeln beskriver hur du gör prestandajustering för NT LAN Manager-autentisering (NTLM) med hjälp av inställningen MaxConcurrentApi. Den här artikeln innehåller vägledning för administratörer när det gäller att identifiera vilka servrar som maxconcurrentApi-värdet ska höjas på och hur mycket värdet ska anges.

Åtgärd

För att lösa det här problemet måste du granska prestandadata som hämtats från alla servrar som är inblandade i scenariot. Sedan kan du försöka öka inställningen MaxConcurrentApi på de servrar som visar en förlust av prestanda.

Det finns Netlogon tillgängliga händelser som rapporterar NTLM-autentiseringsproblem, se:
2654097 Nya händelseloggposter som spårar fördröjningar och fel i NTLM-autentisering i Windows Server 2008 R2 är tillgängliga

Händelser indikerar aktivitet för två räknare:

• Händelser 5818/5819: Det finns "Semaphore Waiters" om händelserna är aktiverade.
• Händelser 5816/5817: Det finns "Semaphore Timeouts".

För att kunna fastställa det bästa MaxConcurrentApi-värdet för dina servrar måste flera datapunkter sammanföras och beräknas med hjälp av en formel. De data som ska användas för att uppskatta MaxConcurrentApi är följande:

• Net Logon semaphore förvärvar
• Net Logon semaphore time-outs
• Genomsnittlig semaforhållningstid för net-inloggning
• Varaktigheten för prestandaloggningen som har slutförts, mätt i sekunder

När data har hämtats kan följande formel användas för att beräkna rätt MaxConcurrentApi-värde:(semaphore_acquires + semaphore_time-outs) * average_semaphore_hold_time / time_collection_length = <New_MaxConcurrentApi_setting
När du har samlat in prestandadata för netinloggning från när servern var under autentiseringsbelastning bör du bestämma varaktigheten för datainsamlingsprocessen genom att titta på start- och sluttiderna för linjevyn.

Den genomsnittliga semaforlagringstiden kan fastställas genom att ändra standardvyn från linjevyn till rapportvyn i Perfmon.msc. Tänk dig exempelvis följande situation:

• Semaforen förvärvar värdet 8 286.
• Tidsgränsvärdet för semafor är 883.
• Den genomsnittliga semaforhållningstiden är .5 (d.v.s. en halv sekund).
• Rapporteringens varaktighet är 90 sekunder.

I det här scenariot skulle formeln vara följande:
(8 286 + 883) *.5 / 90 =< 51

Om värdet som härleds från formeln är 150 eller större bör du lägga till fler servrar för att hantera den äldre autentiseringsbelastningen.

Om värdet är mindre än 150 bör du ändra registervärdet MaxConcurrentApi på servern till det värde som föreslås av formeln eller till ett större värde.

Följ dessa steg om du vill ändra inställningen MaxConcurrentApi:

1. Klicka på Start och Kör, skriv regedit och klicka sedan på OK.

2. Lokalisera och klicka sedan på följande registerundernyckel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

3. Peka på Nytt i Redigera-menyn och klicka sedan på DWORD-värde.

4. Skriv MaxConcurrentApi och tryck sedan på Retur.

5. Klicka påÄndra på redigera-menyn.

6. Skriv den nya Inställningen MaxConcurrentApi i decimaltal och klicka sedan på OK.

7. I en kommandotolk skriver du följande kommando och trycker sedan på Retur:
   net stop netlogon

8. Skriv följande kommando och tryck sedan på Retur:
   net start netlogon

Mer information

Du kan använda följande knowledge base-artikel för att identifiera symptom på äldre autentiseringsflaskhalsar på klientsidan i detalj:
975363 Du uppmanas tillfälligt att ange autentiseringsuppgifter eller överskrida tidsgränsen när du ansluter till autentiserade tjänster Flaskhalsen för autentisering kan finnas på flera servrar i scenariot. Därför måste du se till att alla servrar i ett visst scenario får sina prestandadata granskade medan de är upptagna med att underhålla tunga belastningar.

Räknarna för semaforförvärv, för semafor-timeouter och för genomsnittlig semaforlagringstid måste granskas på alla programservrar, domänkontrollanter och betrodda domänkontrollanter som är inblandade i service av klientbegäranden.

Prestandadata måste spåras medan servrarna är hårt belastade. Hög belastning uppstår när servrarna ser flest klientbegäranden. I ett e-postserverscenario är till exempel den bästa tiden att samla in prestandadata när användarna kommer till jobbet och kontrollerar sina e-postmeddelanden.

Ytterligare saker att tänka på är följande:

• Inga värden innebär att ingen åtgärd behövs. Semaphore-innehavare och Semaphore Hold Time-räknarna visar inga värden om det inte finns en varaktig belastning på en server. Om det inte finns några värden behövs ingen ändring i maxconcurrentApi-värdet.

• En storlek passar inte alla. MaxConcurrentApi-värdet kan behöva vara ett annat värde för varje server. Den här situationen kan orsakas av att flera programservrar får autentisering från en enda domänkontrollant eller liknande scenarier där flera servrar ger en större belastningsvolym som domänkontrollanten måste hantera.

• Förtroenden. Om de användare som autentiseras kommer från betrodda domäner kan det orsaka längre fördröjningar eftersom den lokala domänkontrollanten måste vänta på svaret från den betrodda domänkontrollanten innan den lokala domänkontrollanten ger svar till programservern.

• Nätverksfördröjning. Nätverksfördröjning kan också spela en viktig roll när det gäller att orsaka flaskhalsar i MaxConcurrentApi. Det här problemet kan inträffa när MaxConcurrentApi-semaforen använder en tidsbaserad timeout-räknare så att klienterna inte väntar på obestämd tid för äldre autentisering.

• Samlokalisering. Om nätverksfördröjningen finns och orsakar fördröjningar och flaskhalsar i slutförandet av MaxConcurrentApi-trådar är en vanlig lösning att placera servrarna på samma fysiska plats så att nätverksfördröjningen minskar. I en domänmodell där en betrodd domän har Microsoft Exchange CAS-servrar, till exempel, och användarens domän finns i en annan region eller Active Directory-plats, skulle det innebära att användarens domänkontrollanter hamnar på samma fysiska plats och Active Directory-plats som Exchange CAS-servrarna och deras domänkontrollanter.

• Möjlig nedströmsfördröjning. Om Semaphore Waiters-räknarvärdet kontinuerligt är större än 0 (noll) under en tid och Semaphore Holders-värdet är mindre än MaxConcurrentApi-inställningen på servern, finns inte flaskhalsen på den servern. I det här fallet tittar du på domänkontrollanten som anges i räknarnamnet som anges som en värddators fullständigt kvalificerade domännamn. Den domänkontrollantens Prestandadata för Semaphore Waiters och Semaphore Holders bör granskas.

• Ändringar i inläsningen eller i nätverkskonfigurationen. Framtida ändringar i belastningen som hanteras eller i nätverkskonfigurationer kan ge nätverksfördröjning och kan leda till ett behov av att kontrollera rätt MaxConcurrentApi-inställning igen. För miljöer där äldre autentiseringsvolym ses i den utsträckning som MaxConcurrentApi-inställningar undersöks rekommenderar vi starkt att du kontinuerligt övervakar och granskar prestandaobjekträknare för net-inloggning. Du kan göra det med hjälp av schemalagda anpassade Perfmon.msc-datainsamlare, med hjälp av Microsoft System Center Operations Manager eller med hjälp av andra metoder.

• Maximalt för Windows Server 2008. Den maximala inställningen som tillåts för MaxConcurrentApi i Windows Server 2008 och i senare versioner av Windows är 150. Använd snabbkorrigeringen som beskrivs i följande knowledge base-artikel för att ha inställningen maximalt 150 tillgängliga om servern som du använder inte kör Windows Server 2008 R2:
  975363 Du uppmanas tillfälligt att ange autentiseringsuppgifter eller överskrida tidsgränsen när du ansluter till autentiserade tjänster

• Maximalt för Windows Server 2003. Den maximala inställningen som tillåts för MaxConcurrentApi i Windows Server 2003 och i tidigare versioner är 10.

• Windows Server 2012 och nyare standardvärden. Standardvärdet för MaxConcurrentApi har ändrats i Windows Server 2012. Det är 10 för medlemsservrar och domänkontrollanter. Den är kvar på 1 för medlemsarbetsstationer.

• Windows Server 2003 och prestandaräknare. Den ursprungliga versionen av Windows Server 2003 innehöll inte prestandaräknare för net-inloggning. Du kan använda en snabbkorrigering för att lägga till den.

Att identifiera obehöriga eller okända klienter eller tjänster som utför upprepad och kontinuerlig NTLM-autentisering kan vara användbart när du vill minska den totala NTLM-autentiseringsbelastningen och därför i slutändan minska antalet Semaphore-användningar för MaxConcurrentApi. Upprepad autentisering på det sättet kan identifieras med hjälp av felsökningsloggning för net-inloggningstjänsten. Om du vill ha mer information om hur du använder Netlogon.log-filen för att felsöka tjänsten Net Logon klickar du på följande artikelnummer för att visa artikeln i Microsoft Knowledge Base:
109626 Aktivera felsökningsloggning för tjänsten Net Logon

Räknaren Perfmon.msc för NTLM-autentiseringar under objektet Security System-Wide Statistics är inte en återspegling av antalet användningsområden för den spårade tråden MaxConcurrentApi. Det finns ingen en-till-en-korrelation mellan semaforanvändningen MaxConcurrentApi som visas i prestandaräknaren För net-inloggning och ökar NTLM-autentiseringsräknaren. NTLM-autentiseringsräknaren är inte användbar för att fastställa det bästa MaxConcurrentApi-värdet.

Dessutom är det troligt att tidsgränser för äldre autentiseringsprestanda som är relaterade till MaxConcurrentApi visas men inte återspeglas i någon annan prestandaräknare än räknaren för net-inloggning. Det innebär att andra prestandamått som CPU-användning och disk- och nätverksanvändning kanske inte visar någon belastning även om MaxConcurrentApi-belastningen är tung och användarna har problem.

En ytterligare minimerande procedur kan utföras på domänkontrollanter som har poster i felsökningsloggen för net-inloggningstjänsten som anger att klienter skickar <null>\username i stället för domainname\username. Den här proceduren beskrivs i följande artikel i Microsoft Knowledge Base:
923241 Processen Lsass.exe kan sluta svara om du har många externa förtroenden på en Active Directory-domänkontrollant