Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo discute como coletar e analisar dados para determinar se você tem um problema que pode ser corrigido usando a entrada do MaxConcurrentApi Registro. Esse tipo de problema também é conhecido como problema MCA. Esse processo ajuda a determinar quais computadores em sua infraestrutura são afetados por esse problema.
Aplica-se a: Windows Server 2012 e versões posteriores, Windows 8 e versões posteriores
Resumo
Tecnicamente, MaxConcurrentApi define o número de threads de lsass.exe por canal seguro que estão disponíveis para o serviço Netlogon. Esse valor é definido no registro de cada servidor. Você não deve alterá-lo a menos que tenha feito o seguinte:
- Servidores específicos identificados que mostram evidências de um problema de MCA
- Calculou um valor específico
MaxConcurrentApipara cada servidor afetado
Se você alterar o valor sem seguir essas regras, talvez não corrija o problema. Na verdade, você pode causar outros problemas.
Este artigo descreve como identificar os servidores que você deve modificar usando o seguinte processo:
- Identifique os dados que você precisa coletar.
- Identifique os computadores nos quais você precisa coletar dados
- Determine se sua infraestrutura tem um problema de MCA.
- Identifique servidores específicos que podem se beneficiar de um valor ajustado
MaxConcurrentApi.
Tipos de dados úteis
A tabela a seguir lista os tipos de dados que você deve ter para os métodos discutidos neste artigo.
| Tipo de dados | Source | Mais útil para |
|---|---|---|
| Mensagens de erro Mais informações sobre logs e mensagens de erro do Netlogon |
Logs do Netlogon | Identificando um problema de MCA |
| Mensagens de conexão do servidor | Logs do Netlogon | Identificando quais controladores de domínio participam de transações de autenticação |
| Eventos Mais informações sobre eventos |
Log de eventos do sistema Logs do Netlogon |
Identificando um problema de MCA Identificando possíveis causas de atrasos de autenticação |
| Contadores de desempenho Mais informações sobre contadores de desempenho Netlogon |
Monitor de desempenho Logs do Netlogon Log de eventos do sistema |
Identificando um problema de MCA Ajustar valores de MCA |
| Detalhes da transação de servidor para servidor, incluindo interações do controlador de domínio Como iniciar e parar rastreamentos de rede |
netsh Monitor de Rede |
Identificando quais controladores de domínio participam de transações de autenticação Identificando possíveis causas de atrasos de autenticação |
| Relatórios de usuário | Usuários | Indicando que um problema de MCA pode estar ocorrendo |
Observação
Esta lista de dados e fontes de dados não é exaustiva. Outros tipos de dados e fontes de dados, como ETW (rastreamento de eventos para janelas) e o log de eventos operacional do NTLM, estão além do escopo deste artigo.
Como iniciar e parar rastreamentos de rede
Você pode usar a ferramenta netsh (shell de rede nativa ) do Windows para coletar rastreamentos de rede. Para iniciar o rastreamento, abra uma janela do Prompt de Comando no servidor afetado e digite o seguinte comando:
netsh trace start capture=yes tracefile=c:\temp\<Filename>.etl
Observação
Nesse comando, <Filename> representa o nome do arquivo que armazena os dados de rastreamento.
Para interromper o rastreamento, entre no servidor usando a mesma conta que você usou quando iniciou o rastreamento. No prompt de comando, digite o seguinte comando:
netsh trace stop
Depois que o rastreamento é interrompido, o netsh gera arquivos ETL e CAB no local fornecido. Você pode usar o Monitor de Rede ou o Analisador de Mensagens (preterido, não está mais disponível para download) para revisar os arquivos.
Mais informações sobre contadores de desempenho Netlogon
Os contadores de desempenho do Netlogon fornecem dados mais precisos para ajustar o MaxConcurrentApi valor.
Observação
- O objeto Security System-Wide Statistics no Monitor de Desempenho fornece vários contadores relacionados à autenticação. No entanto, eles não fornecem dados que você possa aplicar diretamente ao
MaxConcurrentApi. - Outros contadores de desempenho, como contadores de CPU e rede, não refletem informações de desempenho relevantes para o
MaxConcurrentApi.
A tabela a seguir descreve os contadores mais relevantes. (No Monitor de Desempenho, esses contadores pertencem ao Netlogon .) O "cenário da mercearia" é uma versão mais relacionável da explicação técnica.
| Contador de desempenho | Explicação técnica | Cenário de mercearia |
|---|---|---|
| Suportes de Semáforo | O número de threads que estão segurando o semáforo. Esse número pode ser qualquer valor até o valor atualmente configurado de MaxConcurrentApi. | O número de pessoas que estão atualmente fazendo check-out nas caixas registradoras. |
| Garçons de semáforo | O número de threads que estão aguardando para obter o semáforo. | O número de pessoas que estão esperando na fila para fazer o check-out. |
| Tempos limite de semáforo | O número total de vezes que um thread atingiu o tempo limite enquanto aguardava o semáforo, medido ao longo do tempo de vida do canal seguro (ou desde a inicialização do sistema). | O número total de pessoas que abandonam a fila do caixa porque ficaram sem tempo. (Se a linha fosse mais rápida ou houvesse linhas adicionais, isso poderia não ocorrer.) |
| Tempo médio de espera do semáforo | O tempo médio (medido em segundos) que o semáforo é mantido sobre a última amostra. | O tempo médio que cada pessoa leva para passar pela fila e fazer o check-out. |
| Aquisição de semáforo | O número total de vezes que o semáforo é obtido durante o tempo de vida do canal seguro (ou desde a inicialização do sistema). | O número total de pessoas que fizeram check-out com sucesso. |
Mais informações sobre eventos
A tabela a seguir lista os eventos associados a problemas de MCA. Você pode encontrar esses eventos usando o Visualizador de Eventos ou os arquivos de log do Netlogon para obter uma indicação rápida se um computador pode ter um problema de MCA.
| Origem e ID do evento | Descrição do evento | Contadores de desempenho relacionados |
|---|---|---|
| Netlogon 5816 | O Netlogon falhou em uma solicitação de autenticação do nome de usuário> da conta< no FQDN> do domínio do usuário do domínio<. A solicitação atingiu o tempo limite antes que pudesse ser enviada ao controlador <de domínio FQDN> do controlador de domínio diretamente confiável no nome<> de domínio diretamente confiável. Este é o primeiro fracasso. Se o problema persistir, os eventos consolidados serão registrados sobre cada <frequência de log de eventos em minutos>. | Tempos limite de semáforo tem um valor diferente de zero. As solicitações de autenticação estão falhando. |
| Netlogon 5817 | O Netlogon falhou em uma contagem> adicional <de solicitações de autenticação na última< frequência de log de eventos em minutos>, minutos. As solicitações atingiram o tempo limite antes que pudessem ser enviadas ao controlador <de domínio FQDN> do controlador de domínio diretamente confiável no nome<> de domínio diretamente confiável. | Tempos limite de semáforo tem um valor diferente de zero. As solicitações de autenticação estão falhando. |
| Netlogon 5818 | O Netlogon levou mais de segundos de <limite> de evento de aviso para uma solicitação de autenticação do nome de usuário> da conta< no FQDN> do domínio do usuário do domínio<, por meio do controlador< de domínio FQDN> do controlador de domínio diretamente confiável no nome <>de domínio diretamente confiável. Este é o primeiro aviso. Se o problema persistir, um evento recorrente será registrado a cada <frequência de log de eventos em minutos> . | Garçons de semáforo tem um valor diferente de zero. As solicitações de autenticação estão diminuindo. |
| Netlogon 5819 | O Netlogon levou mais de segundos de limite de evento de aviso para <solicitações de autenticação de contagem> por meio do <controlador <de domínio FQDN> do controlador de domínio diretamente confiável no domínio< diretamente confiável nome de domínio> na última< frequência de log de eventos em minutos>.> | Garçons de semáforo tem um valor diferente de zero. As solicitações de autenticação estão diminuindo. |
Observação
A ID de evento 7 do Kerberos pode indicar um problema de MCA. O evento tem a seguinte descrição:
O subsistema Kerberos encontrou uma falha de verificação de PAC. Isso indica que o PAC do cliente no realm tinha um PAC que não foi verificado ou modificado. Entre em contato com o administrador do sistema.
No entanto, outras situações além de um problema de MCA também podem acionar esse evento.
Para obter informações sobre como modificar a freqüência de log e o limite de aviso das IDs de evento 5816–5819, consulte Novas entradas de log de eventos que rastreiam atrasos e falhas de autenticação NTLM no Windows Server 2008 R2 estão disponíveis.
Mais informações sobre logs e mensagens de erro do Netlogon
Quando o log do Netlogon está habilitado em um servidor, o serviço Netlogon gera arquivos Netlogon.log e Netlogon.bak. Para obter mais informações, consulte Habilitando o log de depuração para o serviço Netlogon. Você pode usar as mensagens de erro e os eventos para identificar problemas de MCA quando eles ocorrem, para identificar quais controladores de domínio estão respondendo a solicitações de autenticação e para ajudar a identificar tendências no tempo de problema.
Você pode usar um editor de texto para revisar os arquivos de log. Se Netlogon.bak arquivos estiverem disponíveis, revise esses arquivos além dos arquivos Netlogon.log. Quando uma solicitação de autenticação atinge o tempo limite devido a um problema de MCA, você vê um padrão de entradas de log semelhante ao seguinte trecho:
06/03 14:16:58 [LOGON] SamLogon: Network logon of <Domain>\User1 from WORKSTATION1 Entered
06/03 14:17:43 [CRITICAL] <Domain>: NlAllocateClientApi timed out: 0 258
06/03 14:17:43 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.
06/03 14:17:43 [LOGON] SamLogon: Network logon of <Domain>\User1 from WORKSTATION1 Returns 0xC000005E
A primeira linha do trecho registra a solicitação de autenticação. A segunda linha é gerada 45 segundos depois e documenta o tempo limite.
Observação
Em um arquivo de log típico, pode haver centenas de entradas de log não relacionadas entre essas duas linhas.
Duas mensagens de erro seguem a linha de tempo limite:
- Não é possível alocar o slot da API do cliente. Esta mensagem é um diagnóstico de um problema de MCA.
- Logon de rede... Devoluções 0xC000005E. Essa mensagem sempre acompanha a mensagem anterior. No entanto, outros problemas também podem gerar essa mensagem, portanto, ela não é considerada diagnóstica por si só.
Quando ocorre um problema de MCA, o log do Netlogon também pode registrar eventos do Netlogon (ID do evento 5816-5819).
As entradas de log semelhantes ao exemplo a seguir podem ajudá-lo a rastrear os caminhos que as solicitações de autenticação estão seguindo por meio de seus sistemas:
12/25 01:39:03 [PERF] NlSetServerClientSession: Not changing connection (000000000A10FA48): "\\DC01.FAKEDOMAIN.LOCAL"
Por onde começar a procurar o problema
Semelhante a qualquer gargalo, seu ambiente — particularmente sua topologia de domínio e sua infraestrutura de rede — afeta a forma como um problema de MCA se manifesta. Um problema que ocorre em um servidor pode induzir problemas relacionados em outros servidores. Os servidores mais prováveis de ter problemas de MCA são os controladores de domínio e os servidores de aplicativos (servidores front-end ou back-end). Problemas de MCA são raros em estações de trabalho.
Observação
Se você souber de um usuário e de uma estação de trabalho que tenha problemas de autenticação, também poderá revisar os logs detalhados do Netlogon na estação de trabalho. Esses logs podem fornecer informações sobre o problema. No entanto, é improvável que revelem a causa raiz do problema.
Identifique seus possíveis caminhos de autenticação e pontos de estrangulamento
Um caminho de autenticação é o caminho de um servidor para o próximo que uma solicitação de autenticação baseada em Netlogon segue. Para os fins desta discussão, o servidor de aplicativos recebe a solicitação primeiro. A solicitação viaja para um controlador de domínio que conclui a autenticação e retorna a resposta ao servidor de aplicativos. No entanto, esta é a visão altamente simplificada. Os detalhes do processo dependem da sua infraestrutura e da topologia do domínio, entre outros fatores. Esse processo é importante porque, para identificar um problema de MCA, você precisa analisar os dados de cada servidor de aplicativos e controlador de domínio que pode manipular uma solicitação de autenticação.
Importante
Qualquer um dos servidores que estão no caminho de autenticação pode criar um ponto de estrangulamento em que um problema de MCA pode retardar as solicitações de autenticação. Além disso, mais de um servidor pode ter um problema de MCA ao mesmo tempo.
Quando o servidor de aplicativos precisa autenticar um usuário, o servidor de aplicativos primeiro tenta entrar em contato com um controlador de domínio próximo (ou seja, dentro do mesmo site lógico do Active Directory). Se não houver um controlador de domínio no mesmo site, o servidor de aplicativos enviará a solicitação de autenticação para qualquer controlador de domínio disponível no domínio local. Se o usuário não for membro do domínio, o controlador de domínio precisará passar a solicitação. O sistema usa vários critérios para determinar para onde a solicitação vai em seguida:
- Se o domínio tiver uma relação de confiança de atalho ou uma relação de confiança externa que se conecta a outro domínio, o próximo controlador de domínio no caminho pertencerá ao domínio que a relação de confiança determina.
- Se o domínio não for o domínio raiz da floresta, o próximo controlador de domínio pertencerá ao domínio raiz da floresta.
- Se o usuário não for membro do domínio raiz da floresta, esse controlador de domínio determinará se o usuário pertence a outro domínio na mesma floresta.
- Se o usuário pertencer a outro domínio na floresta, o próximo controlador de domínio pertencerá ao domínio do usuário.
- Se o usuário não pertencer à floresta, a solicitação será enviada ao lado do domínio raiz de qualquer floresta confiável.
- Se o domínio do usuário estiver em uma floresta confiável, um controlador de domínio no domínio raiz dessa floresta enviará a solicitação a um controlador de domínio no domínio do usuário.
Quando o controlador de domínio final no caminho autentica o usuário, ele retorna a resposta de autenticação para o servidor de aplicativos. A resposta segue o mesmo caminho da solicitação, mas ao contrário.
Importante
Quando você usa o DNS integrado aos Serviços de Domínio Active Directory (AD DS), a topologia do site do AD DS pode simplificar ou complicar o caminho de autenticação. Os registros DNS dos controladores de domínio contêm informações do site. Portanto, quando um controlador de domínio consulta o DNS para localizar um controlador de domínio em um domínio de destino, ele pode realmente enviar duas consultas DNS, da seguinte maneira:
- A primeira consulta solicita uma lista de controladores de domínio que pertencem ao mesmo site do AD DS no domínio de destino.
- Se a primeira solicitação falhar, o controlador de domínio consultará novamente para obter uma lista de todos os controladores de domínio que estão no domínio de destino.
Em ambos os casos, qualquer um dos controladores de domínio na lista pode receber a solicitação de autenticação. O algoritmo de seleção não leva em conta outros fatores, como a velocidade da conexão. Em topologias complexas, os sites podem restringir possíveis caminhos de autenticação a subconjuntos selecionados de controladores de domínio que têm conexões de alta capacidade.
Para obter mais informações sobre como o Windows direciona solicitações de autenticação quando você usa nomes de sites em várias florestas, consulte Localizador de domínio em uma relação de confiança de floresta.
Para obter mais informações sobre o DNS integrado ao Active Directory, consulte Revisando conceitos de DNS.
O diagrama a seguir fornece uma visão geral de alto nível dos critérios que determinam um caminho de autenticação.
Exemplos de como identificar caminhos de autenticação e possíveis pontos de estrangulamento
Os exemplos a seguir ilustram como identificar os servidores que você deve verificar em busca de problemas de MCA.
Exemplo 1: topologia de floresta única
Considere a topologia a seguir.
O servidor Web no Domínio B atende aos usuários do Domínio C e usa a autenticação NTLM. O Domínio B e o Domínio C estão na mesma floresta. O domínio A é o domínio raiz da floresta.
Sempre que um usuário acessa um recurso do servidor Web, uma solicitação de autenticação segue estas etapas:
O servidor Web recebe a solicitação de autenticação e a envia para um controlador de domínio "próximo" (um controlador de domínio no mesmo site lógico no domínio do servidor Web).
Se não houver um controlador de domínio no mesmo site, o servidor Web reenviará a solicitação para qualquer controlador de domínio no Domínio B.
O controlador de domínio do Domínio B determina que o usuário não está no Domínio B e passa a solicitação de autenticação para a raiz da floresta (Domínio A).
Novamente, o controlador de domínio do Domínio B primeiro tenta enviar a solicitação para um controlador de domínio no mesmo site e, se isso não funcionar, ele envia a solicitação para qualquer controlador de domínio disponível no Domínio A.
O controlador de domínio do Domínio A determina que o usuário não pertence ao Domínio A, mas pertence ao Domínio C na mesma floresta. Ele envia a solicitação para o Domínio C (um controlador de domínio do mesmo site ou qualquer controlador de domínio no domínio).
O controlador de domínio Domínio C autentica o usuário e envia a resposta de autenticação.
Para concluir o processo de autenticação, a resposta viaja de volta ao longo da mesma cadeia para o servidor web no Domínio B.
Dependendo da topologia do site, os servidores a seguir são os possíveis pontos de estrangulamento.
| Segmento de canal horário | Servidores de envio e recebimento em um site | Servidores de envio e recebimento em sites diferentes |
|---|---|---|
| 1 | Servidor Web Controladores de domínio B no site |
Servidor Web Todos os controladores de domínio do Domínio B |
| 2 | Controladores de domínio do domínio A no site | Todos os controladores de domínio do Domínio A |
| 3 | Controladores de domínio C no site | Todos os controladores de domínio C do Domínio |
Exemplo 2: topologia simples de duas florestas
Considere a seguinte topologia:
O domínio A é o domínio raiz da floresta A e o domínio D é o domínio raiz da floresta B. Os domínios A e B têm uma relação de confiança de floresta.
Os domínios B e C pertencem à floresta A e os domínios E e F pertencem à floresta B. Um servidor Web no Domínio B usa a autenticação NTLM para atender usuários no Domínio E.
O servidor Web no Domínio B atende aos usuários do Domínio E e usa autenticação NTLM. O Domínio B é um domínio filho do Domínio A (raiz da floresta), com o Domínio A mantendo uma relação de confiança de floresta com o Domínio D, que contém o Domínio E (o domínio filho que contém as contas de usuário).
Cada vez que um usuário acessa um recurso de servidor da Web, uma solicitação de autenticação segue estas etapas:
O servidor Web recebe a solicitação de autenticação e a envia para um controlador de domínio "próximo" (um controlador de domínio no mesmo site lógico no domínio do servidor Web).
Se não houver um controlador de domínio no mesmo site, o servidor Web reenviará a solicitação para qualquer controlador de domínio no Domínio B.
O controlador de domínio do Domínio B determina que o usuário não está no Domínio B. Ele passa a solicitação de autenticação até a raiz da floresta (Domínio A).
Novamente, o controlador de domínio do Domínio B primeiro tenta enviar a solicitação para um controlador de domínio no mesmo site. Se isso não funcionar, o controlador de domínio do Domínio B enviará a solicitação para qualquer controlador de domínio disponível no Domínio A.
O controlador de domínio do Domínio A determina que o usuário não pertence ao Domínio A e que o domínio do usuário não está na floresta A. Ele encaminha a solicitação de autenticação através da relação de confiança da floresta para o Domínio D (um controlador de domínio do mesmo site ou qualquer controlador de domínio no domínio).
O controlador de domínio do Domínio D determina que o usuário não pertence ao Domínio D, mas pertence ao Domínio E na mesma floresta. Ele envia a solicitação para o Domínio E (um controlador de domínio no mesmo site ou qualquer controlador de domínio no domínio).
O controlador de domínio do Domínio E autentica o usuário e envia a resposta de autenticação.
Para concluir o processo de autenticação, a resposta viaja de volta ao longo da mesma cadeia para o servidor web no Domínio B.
Dependendo da topologia do site, os seguintes servidores são os possíveis pontos de estrangulamento:
| Segmento de canal horário | Servidores de envio e recebimento em um site | Servidores de envio e recebimento em sites diferentes |
|---|---|---|
| 1 | Servidor Web Controladores de domínio B no site |
Servidor Web Todos os controladores de domínio do Domínio B |
| 2 | Controladores de domínio do domínio A no site | Todos os controladores de domínio do Domínio A |
| 3 | Controladores de domínio D no site | Todos os controladores de domínio do Domínio D |
| 4 | Controladores de domínio E dentro do site | Todos os controladores de domínio do Domínio E |
Exemplo 3: topologia de floresta interna/externa
Considere a topologia a seguir.
O Domínio A e o Domínio D têm uma relação de confiança externa. O servidor Web no Domínio A atende usuários do Domínio D e usa autenticação NTLM.
Observação
Esse é o mesmo método que se aplica a relações de confiança de atalho.
Sempre que um usuário acessa um recurso do servidor Web, uma solicitação de autenticação segue estas etapas:
O servidor Web recebe a solicitação de autenticação e a envia para um controlador de domínio "próximo" (um controlador de domínio no mesmo site lógico no domínio do servidor Web). Se não houver um controlador de domínio no mesmo site, o servidor Web reenviará a solicitação para qualquer controlador de domínio no Domínio A.
O controlador de domínio do Domínio A determina que o usuário não pertence ao Domínio A. Ele encaminha a solicitação de autenticação através da relação de confiança externa para o Domínio D (um controlador de domínio no mesmo site ou qualquer controlador de domínio no domínio).
O controlador de domínio do Domínio D autentica o usuário e envia a resposta de autenticação.
Para concluir o processo de autenticação, a resposta viaja de volta ao longo da mesma cadeia para o servidor Web no Domínio A.
Dependendo da topologia do site, os servidores a seguir são os possíveis pontos de estrangulamento.
| Segmento de canal horário | Servidores de envio e recebimento em um site | Servidores de envio e recebimento em sites diferentes |
|---|---|---|
| 1 | Servidor Web Controladores de domínio do domínio A no site |
Servidor Web Todos os controladores de domínio do Domínio A |
| 2 | Controladores de domínio E dentro do site | Todos os controladores de domínio do Domínio E |
Referência rápida: Possíveis pontos de estrangulamento em diferentes cenários
Esta tabela aborda possíveis pontos de estrangulamento em um escopo mais generalizado como diretrizes de pesquisa. Ao revisar a tabela, lembre-se de que, nas configurações de front-end/back-end, os servidores de aplicativos front-end e back-end são pontos de estrangulamento potenciais. Da mesma forma, você precisa coletar dados sobre todos os membros de grupos de servidores com balanceamento de carga.
Cenários de floresta única
| Exemplos de cenários de gargalo | Possíveis pontos de estrangulamento (onde coletar dados) |
|---|---|
| Servidor de aplicativos enviando credenciais para usuários no mesmo domínio Detalhes do cenário:
|
|
| Servidor de aplicativos enviando credenciais para usuários em um domínio diretamente confiável diferente (confiança externa intransitiva OU confiança transitiva com raiz da floresta)* Detalhes do cenário:
|
|
| Servidor de aplicativos enviando credenciais para usuários em um domínio filho diferente (dentro da mesma floresta) Detalhes do cenário:
|
|
* Este é o cenário descrito no Exemplo 2: topologia simples de duas florestas.
Cenários de várias florestas
| Exemplos de cenários de gargalo | Possíveis pontos de estrangulamento (onde coletar dados) |
|---|---|
| Servidor de aplicativos no domínio filho enviando credenciais para usuários na raiz da floresta em uma floresta diferente (em uma relação de confiança de floresta) Detalhes do cenário:
|
|
| Servidor de aplicativos no domínio filho enviando credenciais para usuários no domínio filho de uma floresta diferente (em uma relação de confiança de floresta)* Detalhes do cenário:
|
|
| Um cenário um pouco mais complexo... Uma configuração de servidor de aplicativos front-end/back-end (como o Microsoft Exchange) em um domínio filho que envia credenciais para usuários no domínio filho de uma floresta diferente (em uma relação de confiança de floresta) Detalhes do cenário:
|
|
Investigação preliminar: existe um problema de MCA?
Depois de identificar os possíveis pontos de estrangulamento em sua infraestrutura, você pode começar a coletar e analisar dados. A primeira prioridade é identificar se realmente existe um problema de MCA. Mais tarde, você restringe exatamente qual servidor (ou servidores) tem um problema.
Importante
Para coletar dados, habilite o log do Netlogon para todos os pontos de estrangulamento identificados na seção anterior. Se você tiver muitos pontos de estrangulamento em potencial, revise esta seção e a próxima seção, Restrinja seu escopo e identifique tendências.
Para identificar um problema de MCA, você precisa coletar dados de desempenho enquanto os servidores estão sob uma carga pesada. Uma carga pesada ocorre quando os servidores veem a maioria das solicitações do cliente. Por exemplo, em um cenário de servidor de email, o melhor momento para coletar os dados de desempenho é quando os usuários chegam ao trabalho e verificam suas mensagens de email. Portanto, você deve garantir que todos os servidores em um determinado cenário tenham seus dados de desempenho revisados enquanto estão ocupados atendendo cargas pesadas.
Verificação rápida: contadores de desempenho e logs de eventos
Os contadores de desempenho e os logs de eventos do Netlogon fornecem uma visão rápida da existência de um problema. Você também pode identificar se o problema está no servidor que forneceu os dados ou em outro servidor que está no mesmo site ou domínio.
Para ajudar a interpretar os valores do contador, verifique se o servidor que forneceu os dados já tem um valor não padrão MaxConcurrentApi . Para fazer isso, siga estas etapas:
Selecione Iniciar, digite regedit e selecione Editor do Registro nos resultados da pesquisa.
Vá para a seguinte subchave do Registro:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\MaxConcurrentApiSe a
MaxConcurrentApichave não existir, você pode presumir com segurança que o computador usa o valor padrão paraMaxConcurrentApi. Os valores padrão são os seguintes:- Controladores de domínio e servidores membros (Windows Server 2012 e versões posteriores): 10
- Computadores clientes e estações de trabalho (Windows 8 e versões posteriores): 1
Observação
Os computadores cliente e as estações de trabalho raramente usam um valor maior que 1.
A tabela a seguir lista eventos e valores de contador que você pode ver juntos em um único computador e o significado de cada combinação.
| Eventos | Valores do contador | O que significa |
|---|---|---|
| N/D | Semaphore Holders é igual à configuração MCA atualmente configurada no servidor local. | O servidor local (ou outro servidor no mesmo nível da cadeia de autenticação) pode ter um problema de MCA. |
| 5816 5817 |
Tempos limite de semáforo tem um valor diferente de zero | Os tempos limite de autenticação estão ocorrendo. O servidor local pode ter um problema de MCA. |
| 5818 5819 |
Garçons de semáforo tem um valor diferente de zero que continua por qualquer período de tempo –e– Semaphore Holders tem um valor menor que a configuração de MCA no servidor local |
Um problema de MCA pode existir em um servidor diferente na cadeia de autenticação. |
Verificação rápida: arquivos de log do Netlogon
Para usar os arquivos de log do Netlogon para identificar um problema de MCA, pesquise nos arquivos por Can't allocate client API slot. Você pode fazer isso usando um editor de texto, como o Bloco de Notas, um script ou comandos de linha de comando. Use uma pesquisa que não diferencia maiúsculas de minúsculas. Se essa string aparecer no arquivo de log, você tem um problema de MCA.
Por exemplo, se você armazenou netlogon.log e netlogon.bak na pasta c:\temp , poderá abrir uma janela do Prompt de Comando e executar os seguintes comandos:
Find /I "Can't allocate client API slot" c:\temp\netlogon.log > c:\temp\MCA-detect-sample.txt
Find /I "Can't allocate client API slot" c:\temp\netlogon.bak >> c:\temp\MCA-detect-sample.txt
Se os arquivos de log contiverem a cadeia de caracteres, o arquivo de resultados, MCA-detect-sample.txt, conterá texto semelhante ao seguinte trecho:
---------- C:\temp\NETLOGON.LOG
[3]12/25 07:12:02 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.
[5]12/25 07:12:02 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.
[7]12/25 07:12:02 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.
[10]12/25 07:12:02 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.
[12]12/25 07:12:02 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.
[17]12/25 07:12:02 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.
[19]12/25 07:12:02 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.
Observação
Neste trecho, <Domínio> representa o domínio que respondeu à solicitação de autenticação.
Se você não encontrar nenhuma correspondência em um servidor específico, pesquise os arquivos por 0xC000005E. Esse código de erro indica que uma solicitação de autenticação atingiu o tempo limite. Também pode indicar que um dos outros computadores que manipularam a solicitação de autenticação tem um erro de MCA. Use essas informações para determinar quais computadores examinar em seguida. Se você estiver lidando com um grande número de servidores, consulte a próxima seção para obter ajuda para restringir o escopo de sua análise.
Restrinja seu escopo e identifique tendências
Esta seção fornece dicas para ajudá-lo a lidar com muitos pontos de estrangulamento em potencial.
Para usar MaxConcurrentApi de forma eficaz, você precisa identificar servidores específicos para mitigar. A longo prazo, você precisa entender por que esses servidores específicos estavam sobrecarregados. Usando essas informações, você pode melhorar sua topologia para que ela não precise mais de MaxConcurrentApi ajustes (descritos na Parte 3 desta série).
Observação
Você pode usar aplicativos como o Bloco de Notas ou o Microsoft Excel para classificar e pesquisar arquivos de log.
Procure tendências como as seguintes:
Os logs de netlogon incluem mensagens de conexão que você pode usar para identificar quais controladores de domínio estão envolvidos em um caminho de autenticação. Essas entradas de log são semelhantes ao seguinte trecho:
12/25 01:39:03 [PERF] NlSetServerClientSession: Not changing connection (000000000A10FA48): "\\DC01.CONTOSO.LOCAL"Ao identificar a quais controladores de domínio um servidor tenta se conectar, verifique se a solicitação realmente chegou a um deles.
Por exemplo, suponha que você encontre
Can't allocate client API sloterros nos logs do servidor de aplicativos. Esses erros indicam que o próprio servidor de aplicativos tem um problema de MCA. Verifique novamente todos os controladores de domínio que o servidor de aplicativos tentou contatar. Se o servidor de aplicativos for a raiz do problema, é provável que os controladores de domínio nunca tenham recebido a solicitação.Use os carimbos de data/hora nos logs do Netlogon e nos rastreamentos de rede (e potencialmente contadores de desempenho) para comparar a velocidade de cada "salto" no caminho de autenticação.
Por exemplo, considere uma solicitação de autenticação que precisa viajar entre dois domínios filho em uma única floresta. O tempo necessário para passar a solicitação do domínio filho solicitante para o domínio raiz é significativamente menor do que o tempo necessário para passar do domínio raiz para o domínio filho de destino. Nesse caso, algo pode estar atrasando a solicitação no controlador de domínio raiz ou no controlador de domínio de destino (filho).
Verifique quais usuários são afetados e quando são afetados. Todos os usuários afetados são do mesmo domínio ou floresta? O problema afeta apenas usuários específicos ou todos os usuários? A hora do dia faz diferença? Você pode usar entradas de log do Netlogon que se assemelham aos seguintes trechos para rastrear solicitações de usuários específicos:
[8]12/25 07:12:02 [LOGON] SamLogon: Network logon of CONTOSO\User1 from WIN7CLIENT1 Returns 0xC000005E[3905][29654]12/25 07:16:03 [LOGON] SamLogon: Network logon of CONTOSO\User1 from WIN7CLIENT1 Returns 0xC000005E
Exemplo: usar o Monitor de desempenho para pesquisar um problema de MCA
Como um exemplo do mundo real, considere um arquivo BLG (dados do Monitor de Desempenho) de um servidor de aplicativos que executa o IIS e o FTP e também fornece funcionalidade de servidor de arquivos e impressão. O arquivo de dados é iniciado algumas horas após o aparecimento do problema. Para este exemplo, suponha que o servidor que produziu esses dados seja o único que está no ambiente com suspeita de ter um problema de MCA.
A exibição a seguir no Performance Manager mostra um segmento de 110 segundos dos dados.
As solicitações de autenticação estão expirando?
Primeiro, use os dados do contador Tempos Limite de Semáforo para calcular o número de tempos limite de semáforo que ocorrem durante esse intervalo. Esse contador é cumulativo. Portanto, o valor no início da duração é o mínimo e o valor no final da duração é o máximo. Subtrair o número mínimo de tempos limite do número máximo de tempos limite produz um valor de 2.253 tempos limite durante esse intervalo. O valor esperado para esse contador é zero. Claramente, existe um problema de MCA aqui.
Qual é o volume de solicitações atrasadas?
Observe os dados do contador de garçons de semáforo durante o mesmo intervalo. Esse contador rastreia as solicitações que estão aguardando, mas ainda não atingiram o tempo limite. Essas informações podem indicar a magnitude do problema.
Nesse caso, existem até 2.157 "garçons" durante esse intervalo.
Conclusão
Nosso servidor de exemplo tem um problema significativo de tempo limite de autenticação. Continuaremos este exemplo na parte 2 desta série para mostrar como calcular um MaxConcurrentApi valor para este servidor.