Quanta memória está disponível quando você recebe esse erro? Se você saturou toda a memória, novas sessões falharão.
Começamos a ver instâncias no nosso servidor de intranet onde, para qualquer página, o servidor responde apenas com a página de erro 'HTTP / 1.1 New Session Failed'. Parece que podemos consertá-lo executando o IISRESET, mas parece que estamos apenas tratando o sintoma.
O servidor é um servidor virtualizado que executa o IIS6 no Windows Server 2003 com 0,5 GB de RAM. Nossa intranet é escrita em ASP, mas também temos aplicativos ASP.NET 2.0 em execução no site. O site está configurado para Autenticação Anônima e Integrada.
O que faz com que o IIS entre nesse estado de erro? O servidor pode estar saturado de solicitações, por exemplo, precisamos expandir e mover alguns aplicativos para outro servidor?
Eu vi KB210842 , mas não tenho certeza de que se aplica, pois isso é aplicável ao IIS 4
Seus logs de eventos provavelmente têm mais informações. Verifique os logs do aplicativo e os logs do sistema em busca de erros.
512 MB de RAM não são suficientes para o Windows 2003 + IIS 6 com qualquer carga respeitável - especialmente com o ASP .NET 2.0. Atualizar para 1 GB fará uma grande diferença.
Eu quero adicionar algumas informações aqui. O problema tem apenas uma causa direta - não há memória suficiente para alocação de nova sessão. A verdadeira questão é o que consome a memória e, obviamente, a resposta é diferente em cada situação diferente. Deixe-me dizer algumas palavras sobre minha configuração primeiro:
Estou hospedando em VPS-es baseados no Virtuozzo e lá você pode ver o problema com mais clareza. Qual é a diferença - no VMWare você tem algo parecido com uma máquina real - com arquivo de swap e ram, eles podem não corresponder exatamente ao real, mas efetivamente um VMWare (e qualquer solução baseada em virtualização de hardware) pode ser tratado como uma máquina real . Com Virtuozzo você obtém apenas RAM - parte dela estaria no arquivo de paginação, mas de dentro do VPS você não pode realmente ver a diferença. Então, eu estou usando VPS-es com tão pouca memória quanto 286MB e essa é toda a memória que eu posso usar, quando você usa VMWare com memória definida para 286 você também pode ter algum espaço adicional de swap, assim sua RAM utilizável seria mais depende muito do tamanho do arquivo de paginação, é claro).
Na máquina de 286 MB, posso hospedar cerca de 15 a 20 aplicativos com boa quantidade de visitantes. Eu estou usando meu próprio framework e componentes - incluindo o próprio mecanismo de banco de dados. Tenho certeza que não há vazamentos de memória (depois de anos e anos de testes), mas 286MB de memória no total é gelo muito fino. Você obteria a "nova sessão falhou" de vez em quando - a questão é como evitar ficar preso a ela até a reinicialização (do IIS ou da máquina). A resposta é ajustar os limites de memória do aplicativo COM + e pode haver algumas outras opções de reciclagem. Você deve certificar-se de que os limites sejam tais que o processo de trabalho será reciclado quando as coisas ficarem feias e você deve manter em sua mente a quantidade total de memória usada por todos os aplicativos COM + que estiver usando, porque a quantidade total de limites de memória é maior que a memória utilizável que você pode obter em uma situação em que nenhum dos processos de trabalho está acima do limite, mas todos juntos estão ocupando toda a memória disponível e nenhum reciclará para liberar alguns megabytes preciosos.
Outra coisa a verificar é as opções de armazenamento em cache do ASP - quantos arquivos são armazenados em cache na memória, quantos mecanismos de script são armazenados em cache (isso também acontece na memória). Os padrões são bem grandes e o efeito se parece com vazamentos de memória - especialmente se você tiver muitos arquivos ASP e muitos sites (o cache é configurado em um nível global, mas é feito nos processos de trabalho).
Assim, ajustando os aplicativos COM + e as opções de cache, você pode fazer com que o servidor funcione, se não de forma absolutamente tranquila; pelo menos, certifique-se de recuperar automaticamente com possíveis solicitações por dia no máximo (de, digamos, cem mil ) retornando Nova sessão falhou. Se você mantiver o número de aplicativos COM + baixo (de no máximo 2-3), poderá manter a faixa e escolher os limites de memória apropriados, talvez configurando a reciclagem do intervalo de tempo para os aplicativos que não são sensíveis a perdas de sessão, etc.
Há outra coisa a considerar aplicativos .NET no mesmo servidor. Sem atenção, eles podem matar todo o resto e pegar todos os recursos do servidor. O problema é a coleta de lixo - os aplicativos ASP.NET (e qualquer .NET) não liberarão sua memória porque algum aplicativo ASP ou clássico do PHP precisa disso e manterá a memória ocupada mesmo se não a estiver usando - eventualmente eles liberarão isso, mas eles podem mantê-lo por horas - apenas assim. As soluções são - evite misturar aplicativos .NET e não-.NET no mesmo servidor, se você não puder evitar, coloque os aplicativos .NET em pools COM + separados e defina limites rígidos de memória e faça-os o mais baixo possível.
Bem, espero que isso seja útil. Tenho muita experiência em gerenciar servidores com pouca memória disponível - não é muito difícil, mas é preciso prestar atenção e não esperar que o problema desapareça com um patch ou outra solução mágica.
Você está executando o estado de sessão no IIS ou no provedor fora do proc. Mover o estado da sessão para o provedor permitirá que você use a memória do serviço de estado da sessão em vez do processo do IIS. Além disso, o estado da sessão sobreviverá ao IIS e reinicia o domínio do aplicativo. Eu também notaria que 512Meg está no lado pequeno.
Parece que o IIS6 não tem memória suficiente para alocar a sessão. Se isso estiver acontecendo com muita frequência, talvez seja necessário definir um limite de reciclagem de memória no pool de aplicativos. Dessa forma, não "comerá" todos os recursos disponíveis. Tenha em mente que a reciclagem da memória causará a perda da sessão.