Temos aproximadamente 200 servidores, Hyper V, File Cluster e IIS, que estão enfrentando o mesmo problema, ocorre um evento no servidor durante o uso normal que atinge o máximo ou quase o limite da RAM no servidor. Quando isso acontece, o serviço SVCHOST/Estação de Trabalho, especificamente (eliminado pelo isolamento do serviço Estação de Trabalho em seu próprio SVCHOST) para de liberar identificadores/threads e a memória usada por esse serviço nunca é liberada. Temos, em alguns casos extremos, serviços de estação de trabalho que usam até 40 GB de RAM em um servidor de 255 GB. Também encontrando mais de 40 milhões de identificadores em alguns casos.
Na reinicialização, o problema, claro, desaparece e não aparece novamente até que toda a memória tenha sido usada, digamos, pelo processo W3 ou pelas VMs HyperV, depois disso, o serviço Workstation começa a capturar toda a RAM. O processo é muito lento e pode levar semanas/meses dependendo da quantidade de RAM do servidor.
Tanto nossos servidores Hyper V quanto os servidores IIS acessam compartilhamentos para arquivos de trabalho. Esses compartilhamentos estão em armazenamento SSD, portanto, têm bastante desempenho. Instalamos todos os patches atuais, mas não mudamos para o R2, pois temos muitas ferramentas instaladas que tornarão isso um passo significativo e não conseguimos encontrar nenhuma indicação clara de que isso seria corrigido no R2.
Executamos o ProcMon e outras ferramentas, mas nos servidores mais problemáticos essas ferramentas nem funcionam. Nos outros, os resultados fornecidos apenas mostram que parece haver realmente um vazamento de memória nesse processo.
Existe uma maneira de liberar memória desse processo ou evitar o bug de uma vez? Não queremos reiniciar e não podemos reiniciar o processo quando ele estiver em estado de erro. O processo fica congelado.
Estamos tentando evitar reinicializações regulares para 'corrigir' esse problema, portanto, qualquer resposta será apreciada.
Responder1
Tive um problema estranhamente semelhante em que o svchost estava destruindo o desempenho do servidor.
A solução:Acontece que eu tinha um log de eventos completo. Limpei tudo e tudo voltou a funcionar como se nada tivesse acontecido.
(Eu também recomendo alterar o tamanho do log de eventos do padrão, veja abaixo)
Para definir o tamanho máximo do log usando a interface do Windows
- Inicie o Visualizador de Eventos.
- Na árvore do console, navegue e selecione o log de eventos que deseja gerenciar.
- No menu Ação, clique em Propriedades.
- Em Tamanho máximo do log (KB), use o controle giratório para definir o valor desejado e clique em OK.
Parece exatamente o que está acontecendo aqui, mas acabou sendo uma solução muito fácil. Uma reinicialização resolveria temporariamente o problema, mas assim que alguma coisa tentasse gravar no log, tudo sairia do controle e continuaria consumindo recursos.
Espero que isto ajude!
Responder2
>Is there a way we can free up the memory from this process ?
Não há como liberar externamente (corretamente) a memória alocada ou manipular recursos sem eliminar o aplicativo agressor.
>or avoid the bug all together?
Você está enfrentando um vazamento de memória e recursos. A única maneira de resolver o problema é encontrar o vazamento e evitar seu gatilho (se possível) ou consertar o vazamento no nível do código-fonte; No último caso, você precisa da ajuda da Microsoft para produzir o patch, mas parece que eles esperam que você diga "exatamente" onde realmente está o problema.
Você pode tentar encontrar o culpado identificando o vazamento de memória/recurso usando, por exemplo, MSVerificador de aplicativos
Responder3
Criar RAM é fácil, mas não é solução.
Sugiro Sysinternals RAMMAP ou VMMAP para uma investigação mais profunda. Com essas ferramentas você pode ver melhor o que acontece. muitas vezes é um problema de metarquivo.
Desde o Server 2008, temos esse problema com todos os servidores de terminal ficando sem memória com um consumo de memória inacreditável ao longo do tempo ao iniciar aplicativos do compartilhamento.
Nossa solução alternativa é hospedar esses aplicativos em um Terminal Server separado e limpar frequentemente o consumo de memória.
Fazemos isso com um aplicativo de linha de comando c++ autoprojetado usando
SetProcessWorkingSetSize() com SeDebugPrivilege em todos os processos
É altamente recomendável não fazer algo assim;)