Intermitentemente, as solicitações do IIS7 ficam presas no WindowsAuthenticationModule

1



Estamos executando um servidor IIS7 que hospeda várias dezenas de sites. Vários desses sites fazem parte do mesmo aplicativo legado que desenvolvemos. Todos esses sites executam o mesmo código e são executados no mesmo pool de aplicativos.

Aproximadamente uma vez por mês nos últimos meses, constatamos que todas as solicitações desse pool de aplicativos começam a ser suspensas indefinidamente. Quando isso acontece, recebemos um alerta e reciclaremos o pool de aplicativos. Depois disso, os sites começam a funcionar novamente.

Isso afeta apenas esse pool de aplicativos - nunca outros no mesmo servidor. Algumas vezes, antes de reciclar o pool, observei as solicitações atualmente em execução no processo de trabalho. Todos eles aparecem como executando dentro do WindowsAuthenticationModule. O que é estranho, porque a grande maioria do aplicativo não requer autenticação. Há uma pequena seção de administração que usa a autenticação do Windows ... mas todas as outras solicitações devem ser anônimas.


Alguém tem alguma idéia do que pode estar causando isso?

Existem várias coisas incomuns sobre a maneira como esses sites são configurados. Como mencionei, todos eles executam o mesmo código - vários sites apontam para o mesmo diretório físico. A única diferença é as ligações de cabeçalho do host. Não sei por que não há apenas um site com todos os cabeçalhos de host, mas é assim que funciona.

Em vários desses sites, o mesmo diretório físico é mapeado em dois níveis - como a raiz do site e novamente como um aplicativo dentro do site. Portanto, se um usuário acessa o link , ele mapeia para c: \ files \ oursite \ index.aspx. Se um usuário acessar o link , ele também será mapeado para c: \ files \ oursite \ index.aspx. Acho que existe um código que analisa o URL do pedido e lida com os dois pedidos de forma diferente.

Isso é estranho porque o mesmo web.config acaba sendo interpretado como um arquivo de configuração do site, e também como um arquivo de configuração do aplicativo dentro do site. Não sei se isso pode estar relacionado ao problema de autenticação.


Se não conseguirmos encontrar a causa, estamos pensando em algumas soluções alternativas que poderíamos tentar:

  • Mova a seção de administração para um site separado e forneça ao cliente um novo URL de administrador. Execute esse site separado em seu próprio pool de aplicativos. Em seguida, no web.config compartilhado por todos os outros sites, remova o WindowsAuthenticationModule. Dessa forma, não deve haver possibilidade de interrupção no WindowsAuthenticationModule.

  •   
  • Tente executar todos esses sites no pipeline clássico em vez do pipeline integrado. Eles estavam funcionando bem no nosso antigo servidor IIS6 ...

  •   
  • (se ficarmos desesperados) Configure um script de monitoramento que monitora os sites e recicla automaticamente o pool de aplicativos quando detecta que as solicitações estão ficando presas.


O que você acha?

Obrigado pela sua ajuda,
Richard

    
por Richard Beier 13.08.2009 / 20:47

1 resposta

1

Eu tentaria clicar com o botão direito do mouse no processo w3wp.exe executando sob o pool de aplicativos suspenso. Clique com o botão direito do mouse e selecione, criar arquivo de despejo.

Ou:

  1. Abra o arquivo de despejo no Visual Studio 2010
  2. Em opções > depuração (ou similar), você pode selecionar para adicionar servidores de símbolos. Adicionar link
  3. Clique duas vezes no local do travamento e no clique com o botão direito do mouse e selecione o código / símbolos.
  4. Leia o código e veja por que ele foi suspenso

OR:

  1. Siga este artigo para instalar o WinDbg
  2. Faça o que ela faz e veja se consegue encontrar o problema
  3. Ative o log com o netsh para ver os pedidos do token do kerberos assim que eles acontecem (eu não tentei este IRL):

    PS C:\> netsh trace show providers | select-string kerberos   PS C:\> netsh trace show providers | select-string auth

    ... e depois algo como:

    netsh trace start provider={5BBB6C18-AA45-49B1-A15F-085F7ED0AA90}

OR:

  1. Contrate um consultor. :)
por 24.05.2010 / 23:45