IIS é executado fora do itens de trabalho e faz com que as falhas RPC ao conectar-se a um caminho UNC remoto

Em uma Web farm ambiente, onde um ou mais Web IIS servidores estiverem usando um Windows NT ou Windows 2000 arquivo servidor remoto para armazenar o conteúdo para o site da Web (por exemplo, o diretório base ou os diretórios virtuais para o site da Web são mapeados para um caminho UNC), servidores Web do IIS podem ficar sem contextos de trabalho disponível no nível do redirecionador. Quando isso acontece, os seguintes sintomas podem ocorrer nos servidores Web do IIS:

• IIS parece parar de responder. Se você examinar um despejo de processo do Inetinfo.exe, você verá que um grande número de threads de trabalho está aguardando para recuperar o conteúdo do compartilhamento de arquivo remoto. Em um log de desempenho do sistema, o IIS aparece amplamente ocioso durante esse tempo, como a maioria dos threads em um estado de espera, aguardando para acessar o servidor remoto.
• Na área de trabalho local de um dos servidores Web do IIS, se você tentar utilizar o redirecionador de cliente para acessar o compartilhamento de arquivo remoto através de ambiente de rede ou Meus locais de rede ou através do Windows Explorer, ele parece parar de responder indefinidamente. Se um caminho UNC é mapeado para uma letra de unidade local no Windows Explorer e Windows Explorer é aberto, ele parece parar de responder bem. Isso pode dar a aparência que todo o sistema operacional parou de responder, quando na verdade não tem.
• As seguintes mensagens de erro podem ocorrer quando o número máximo de contextos de trabalho está esgotado em um servidor específico:
  
  
  RPC 1792 - A chamada de procedimento remoto falhou e não foi executada.
  Netlogon 5719 - não é possível localizar o controlador de domínio.
  Essas mensagens de erro podem ocorrer quando você tenta estabelecer conexões RPC adicionais para um servidor quando o número máximo de contextos de trabalho é alcançado.
• Foi atingido o limite de comandos BIOS da rede.
• A seguinte mensagem ID evento é registrada:

O servidor está executando fora do trabalho contextos para um determinado cliente. No Windows 2000, há um limite superior embutida de 125 contextos de trabalho para todos os tipos de clientes (Windows NT, Windows 95 e Windows 98).

importante Esta seção, método ou tarefa contém etapas que informam sobre como modificar o registro. No entanto, sérios problemas poderão ocorrer se você modificar o registro incorretamente. Por isso, certifique-se que você execute essas etapas cuidadosamente. Para proteção adicional, fazer backup do registro antes de modificá-lo. Em seguida, você pode restaurar o registro se ocorrer um problema. Para obter mais informações sobre como fazer backup e restaurar o registro, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:

1. Se você estiver executando o Windows 2000, instale o hotfix pós-SP1 descrito no seguinte artigo da Base de dados de Conhecimento da Microsoft para os servidores IIS e o servidor de arquivos:
   271148  (http://support.microsoft.com/kb/271148/ ) Limites MaxMpxCt e MaxCmds no Windows 2000
2. Aumente os valores de MaxCmds nos servidores IIS e MaxMpxCT no servidor de arquivos usando os scripts de registro a seguir:
   
   
   • Salve o seguinte script de registro como Client.reg e execute-o em servidores IIS:
     Windows Registry Editor versão 5.00
     
     [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters] "MaxCmds" = dword:00000800
   • Salve o script de registro a seguir como Server.reg e execute-o no servidor de arquivos:
     Windows Registry Editor versão 5.00
     
     [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters]
     "MaxMpxCT" = dword:00000800
     "MaxWorkItems" = dword:00002000
   Por padrão, esses scripts especifique um MaxCmds e MaxMpxCT de 2.048, que deve ser suficiente para a maioria das situações. MaxWorkItems foi especificado em 4 x MaxMpxCt ou 8.192. Para obter mais informações sobre essas configurações, consulte a seção "Mais informações" deste artigo.
3. Reinicie todos os servidores IIS e o servidor de arquivos para que essas alterações tenham efeito.

Observação Quando você aumenta a esses valores na plataforma x 86, memória de pool não paginável adicionais é consumida no servidor de arquivo e os clientes do IIS. Memória de pool não-paginável tem um limite superior de 256 megabytes (MB). Muitos clientes que têm muitas conexões podem consumir toda a memória não-paginável no servidor de arquivos. Use o Monitor de desempenho para observar esse contador e para certificar-se de que ele não está se aproximando do limite. Na plataforma x 64, memória de pool não-paginável tem um limite superior de 128 gigabytes (GB). Portanto, você pode aumentar esses valores para o valor máximo. Para obter mais informações sobre as diferenças entre a memória de pool não paginado na plataforma x 86 e na plataforma x 64, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:

A Microsoft confirmou que este é um problema nos produtos da Microsoft listados na seção "Aplica-se a".

Depois de aplicar o hotfix descrito no Q271148, o limite superior para MaxMpxCt (a configuração de servidor) muda de 125 para 65.535 e no cliente, o limite superior para MaxCmds (o cliente configuração) altera de 255 a 65.535.

Além disso, o número máximo de sessões simultâneas do SMB que pode ser aberto entre o cliente e o servidor é a inferior das MaxCmds e MaxMpxCT . No entanto, se o cliente está se conectando for um cliente Windows 95 ou Windows 98, em seguida, o valor efetivo de MaxMpxCt para que o cliente é limitado a 125.

Esses limites tornam-se importante quando você usar o IIS em um cenário de Web farm onde o conteúdo para sites da Web está armazenado em um compartilhamento UNC remoto, porque o IIS usa ReadDirectoryChangesW API para receber notificações de alteração de arquivo. Isso é feito para que se alterar arquivos, IIS possa un-cache os arquivos antigos e, em seguida, nova leitura os novos arquivos do disco ou compartilhamento. Quando você usa um caminho UNC como diretório base, uma conexão SMB persistente permanece aberta entre o servidor IIS e o servidor de arquivos, que consome um contexto de trabalho. Se a estrutura de diretórios é grande o suficiente, é possível executar fora de contextos de trabalho e encontrar os sintomas listados anteriormente.

Um computador que está executando o IIS pode ter vários diretórios virtuais ou sites da Web apontando para compartilhamentos no Windows NT Server outro computador. O Monitor de Directory ASP usa ReadDirectoryChangesW API para monitorar para que quaisquer alterações nesses diretórios em outro servidor. Cada pendentes ReadDirectoryChangesW requer um contexto de trabalho no servidor e somente um número limitado de contextos de trabalho está disponível.

O número de contextos de trabalho é passado do servidor para o cliente quando o nível SMB será negociado. O redirecionador do cliente mantém uma contagem do número de contextos de trabalho que está usando no servidor interna. O número de contextos de trabalho padrão é 50.

O número de contextos de trabalho é limitado a manter o processo servidor consuma toda a memória não-paginável. Isso pode ser elevado, mas, em seguida, há um limite para quantos contextos de trabalho pode consumir um cliente específico.

Esse problema não está limitado ao IIS. Windows NT Explorer usa o mesmo mecanismo para monitorar as alterações de diretório.

Observação Esse problema não ocorre em computadores que estejam executando uma versão x 64 do Windows Server 2003.Para obter mais informações sobre as configurações MaxWorkItems e MaxMpxCT, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft: