Come eseguire l'ottimizzazione delle prestazioni per l'autenticazione NTLM usando l'impostazione MaxConcurrentApi

Questo articolo descrive come eseguire l'ottimizzazione delle prestazioni per l'autenticazione NTLM usando l'impostazione MaxConcurrentApi.

Si applica a: Windows Server 2012 R2
Numero KB originale: 2688798

Introduzione

Un aumento della consumerizzazione della tecnologia informatica aziendale (aumento dei dispositivi orientati ai consumatori come smartphone e tablet usati nell'azienda) ha portato ad aumentare il numero di scenari in cui le aziende possono riscontrare un notevole aumento dell'autenticazione legacy negli ambienti aziendali. Questo aumento dell'autenticazione legacy potrebbe causare problemi di prestazioni, ad esempio ritardi o timeout per i client.

Quando si individuano timeout o ritardi di autenticazione (noti anche come colli di bottiglia MaxConcurrentApi) in un ambiente, il modo tipico per risolvere il problema consiste nel generare il numero massimo di thread di lavoro consentiti che il servizio autentica. A tale scopo, modificare il valore del Registro di sistema MaxConcurrentApi e quindi riavviare il servizio Accesso rete nei server.

Identificare quali server sono vittime del collo di bottiglia e quali server sono effettivamente l'origine dei ritardi del collo di bottiglia può essere difficile. Questo articolo descrive come eseguire l'ottimizzazione delle prestazioni per l'autenticazione NT LAN Manager (NTLM) usando l'impostazione MaxConcurrentApi. Questo articolo contiene indicazioni per gli amministratori per identificare i server in cui generare il valore MaxConcurrentApi e la quantità su cui impostare tale valore.

Risoluzione

Per risolvere questo problema, è necessario esaminare i dati sulle prestazioni tratti da tutti i server coinvolti nello scenario. È quindi possibile provare ad aumentare l'impostazione MaxConcurrentApi nei server che mostrano una perdita di prestazioni.

Sono disponibili eventi che segnalano Netlogon problemi di autenticazione NTLM, vedere:
2654097 sono disponibili nuove voci del registro eventi che tengono traccia dei ritardi e degli errori di autenticazione NTLM in Windows Server 2008 R2

Gli eventi indicano l'attività per due contatori:

• Eventi 5818/5819: se gli eventi sono abilitati, sono presenti "Semaphore Waiters".
• Eventi 5816/5817: sono presenti "Timeout semaforo".

Per determinare il valore MaxConcurrentApi migliore per i server, è necessario riunire e calcolare diversi punti dati usando una formula. I dati da usare per stimare MaxConcurrentApi sono i seguenti:

• Net Logon semaphore acquisisce
• Timeout del semaforo net logon
• Tempo medio di attesa del semaforo per l'accesso alla rete
• Durata della registrazione delle prestazioni completata, misurata in secondi

Dopo aver ottenuto i dati, è possibile utilizzare la formula seguente per stimare il valore MaxConcurrentApi corretto:(semaphore_acquires + semaphore_time-out) * average_semaphore_hold_time / time_collection_length = <New_MaxConcurrentApi_setting
Dopo aver raccolto i dati sulle prestazioni di Accesso rete da quando il server è stato sottoposto a carico di autenticazione, è necessario determinare la durata del processo di raccolta dati esaminando l'ora di inizio e fine della visualizzazione riga.

Il tempo medio di attesa del semaforo può essere determinato modificando la visualizzazione predefinita da Visualizzazione riga a Visualizzazione report in Perfmon.msc. Si consideri, ad esempio, lo scenario seguente:

• Il valore acquisito dal semaforo è 8.286.
• Il valore di timeout del semaforo è 883.
• Il tempo medio di attesa del semaforo è .5 (ovvero mezzo secondo).
• La durata della creazione di report è di 90 secondi.

In questo scenario, la formula sarà la seguente:
(8.286 + 883) *.5 / 90 =< 51

Se il valore derivato dalla formula è 150 o superiore, è necessario aggiungere altri server per gestire il carico di autenticazione legacy.

Se il valore è minore di 150, è necessario modificare il valore del Registro di sistema MaxConcurrentApi in tale server sul valore suggerito dalla formula o su un valore più grande.

Per modificare l'impostazione MaxConcurrentApi, seguire questa procedura:

1. Fare clic su Start, scegliere Esegui, digitare regedit, quindi fare clic su OK.

2. Individuare e selezionare la seguente sottochiave del Registro di sistema: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

3. Scegliere Nuovo dal menu Modifica, quindi fare clic su Valore DWORD.

4. Digitare MaxConcurrentApi e quindi premere INVIO.

5. Scegliere Modifica dal menu Modifica.

6. Digitare la nuova impostazione MaxConcurrentApi in decimale e quindi fare clic su OK.

7. Al prompt dei comandi digitare il comando seguente e quindi premere INVIO:
   net stop netlogon

8. Digitare il comando seguente e quindi premere INVIO:
   net start netlogon

Ulteriori informazioni

È possibile usare il seguente articolo della Knowledge Base per identificare in modo più dettagliato i sintomi sul lato client dei colli di bottiglia dell'autenticazione legacy:
975363 Vengono richieste in modo intermittente credenziali o timeout dell'esperienza quando ci si connette ai servizi autenticati Il collo di bottiglia di autenticazione può trovarsi in più server nello scenario. Pertanto, è necessario assicurarsi che tutti i server in un determinato scenario abbiano i propri dati sulle prestazioni esaminati mentre sono occupati a gestire carichi pesanti.

I contatori per il semaforo acquisiscono, per i timeout del semaforo e per il tempo medio di attesa del semaforo devono essere esaminati in tutti i server applicazioni, i controller di dominio e i controller di dominio attendibili coinvolti nella manutenzione delle richieste client.

I dati sulle prestazioni devono essere monitorati mentre i server sono sottoposti a un carico elevato. Il carico elevato si verifica quando i server visualizzano la maggior parte delle richieste client. Ad esempio, in uno scenario di server di posta elettronica, il momento migliore per raccogliere i dati sulle prestazioni è quando gli utenti arrivano al lavoro e controllano i messaggi di posta elettronica.

Gli elementi aggiuntivi da considerare sono i seguenti:

• Nessun valore indica che non è necessaria alcuna azione. I contatori Semaphore Holders e Semaphore Hold Time non mostreranno alcun valore a meno che non vi sia un carico prolungato in un server. Se non sono presenti valori, non è necessaria alcuna modifica nel valore MaxConcurrentApi.

• Una dimensione non è adatta a tutte. Il valore MaxConcurrentApi potrebbe essere un valore diverso per ogni server. Questa situazione può essere causata da più server applicazioni che ottengono l'autenticazione da un singolo controller di dominio o da scenari simili in cui più server forniscono un volume maggiore di carico che il controller di dominio deve gestire.

• Trust. Se gli utenti autenticati provengono da domini attendibili, possono causare ritardi più lunghi, perché il controller di dominio locale deve attendere la risposta dal controller di dominio attendibile prima che il controller di dominio locale fornisca la risposta al server applicazioni.

• Latenza di rete. La latenza di rete può anche svolgere un ruolo importante nella causa dei colli di bottiglia MaxConcurrentApi. Questo problema può verificarsi quando il semaforo MaxConcurrentApi usa un contatore di timeout basato sul tempo in modo che i client non attendano a tempo indeterminato l'autenticazione legacy.

• Collocazione. Se la latenza di rete esiste e causa ritardi e colli di bottiglia nel completamento dei thread MaxConcurrentApi, una soluzione comune consiste nell'inserire i server nella stessa posizione fisica in modo da ridurre la latenza di rete. In un modello di dominio in cui un dominio attendibile ha server CAS di Microsoft Exchange, ad esempio, e il dominio dell'utente si trova in un'altra area o sito di Active Directory, significa inserire i controller di dominio dell'utente nella stessa posizione fisica e nel sito di Active Directory dei server CAS di Exchange e dei relativi controller di dominio.

• Possibile ritardo downstream. Se il valore del contatore Semaphore Waiters è continuamente maggiore di 0 (zero) per qualsiasi momento e il valore Semaphore Holders è minore dell'impostazione MaxConcurrentApi in tale server, il collo di bottiglia non si trova in tale server. In questo caso, esaminare il controller di dominio citato nel nome del contatore elencato come nome di dominio completo del computer host. I dati sulle prestazioni di Semaphore Waiters e Semaphore Holders di tale controller di dominio devono essere esaminati.

• Modifiche nel caricamento o nella configurazione di rete. Le modifiche future nel carico che viene eseguita o nelle configurazioni di rete potrebbero produrre latenza di rete e potrebbero comportare la necessità di valutare di nuovo l'impostazione MaxConcurrentApi corretta. Per gli ambienti in cui il volume di autenticazione legacy viene visualizzato nella misura in cui vengono esaminate le impostazioni MaxConcurrentApi, è consigliabile monitorare ed esaminare continuamente i contatori degli oggetti prestazioni Accesso rete. È possibile eseguire questa operazione usando agenti di raccolta dati Perfmon.msc personalizzati pianificati, Microsoft System Center Operations Manager o altri metodi.

• Windows Server 2008 massimo. L'impostazione massima consentita per MaxConcurrentApi in Windows Server 2008 e nelle versioni successive di Windows è 150. Applicare l'hotfix descritto nell'articolo della Knowledge Base seguente per avere l'impostazione 150 massima disponibile se il server in uso non esegue Windows Server 2008 R2:
  975363 Vengono richieste in modo intermittente credenziali o timeout di esperienza quando ci si connette ai servizi autenticati

• Windows Server 2003 massimo. L'impostazione massima consentita per MaxConcurrentApi in Windows Server 2003 e nelle versioni precedenti è 10.

• Windows Server 2012 e le impostazioni predefinite più recenti. Il valore predefinito per MaxConcurrentApi è stato modificato in Windows Server 2012. È 10 per i server membri e i controller di dominio. Rimane a 1 per le workstation membro.

• Windows Server 2003 e contatori delle prestazioni. La versione originale di Windows Server 2003 non contiene i contatori delle prestazioni di Accesso rete. È possibile applicare un hotfix per aggiungerlo.

L'identificazione di client o servizi non autorizzati o sconosciuti che eseguono l'autenticazione NTLM ripetuta e continua può essere utile quando si vuole ridurre il carico complessivo di autenticazione NTLM e quindi diminuire il numero di utilizzi del semaforo MaxConcurrentApi. L'autenticazione ripetuta in questo modo può essere identificata usando la registrazione di debug del servizio Net Logon. Per altre informazioni su come usare il file Netlogon.log per eseguire il debug del servizio Net Logon, fare clic sul numero dell'articolo della Microsoft Knowledge Base seguente:
109626 Abilitazione della registrazione di debug per il servizio Accesso rete

Il contatore Perfmon.msc per le autenticazioni NTLM nell'oggetto Security System-Wide Statistics non riflette il numero di utilizzi del thread di rilevamento MaxConcurrentApi. Non esiste alcuna correlazione uno-a-uno tra l'utilizzo del semaforo MaxConcurrentApi visualizzato nel contatore delle prestazioni Net Logon e gli incrementi del contatore di autenticazione NTLM. Il contatore dell'autenticazione NTLM non è utile per determinare il valore MaxConcurrentApi migliore.

Inoltre, è probabile che i timeout delle prestazioni di autenticazione legacy correlati a MaxConcurrentApi vengano visualizzati ma non rispecchiati in alcun contatore delle prestazioni diverso dal contatore Accesso rete. Ciò significa che altre metriche delle prestazioni, ad esempio l'uso della CPU e dell'uso del disco e della rete, potrebbero non mostrare alcun carico anche se il carico MaxConcurrentApi è elevato e gli utenti riscontrano problemi.

È possibile eseguire una procedura di riduzione al minimo aggiuntiva nei controller di dominio che dispongono di voci nel log di domainname\usernamedebug del servizio Net Logon che indicano che i client inviano <null>\username anziché . Questa procedura è descritta nell'articolo seguente della Microsoft Knowledge Base:
923241 Il processo di Lsass.exe potrebbe smettere di rispondere se si dispone di molti trust esterni in un controller di dominio Active Directory