Uso de memória do Windows 2012 Core Extreme no serviço SVCHOST / Workstation

Question

Temos aproximadamente 200 servidores, Hyper V, Cluster de arquivos e IIS, todos com o mesmo problema. Ocorre um evento no servidor por meio do uso normal que maximiza ou quase maximiza a RAM no servidor. Quando isso acontece, o serviço SVCHOST / Workstation, especificamente (eliminado ao isolar o serviço Estação de Trabalho para seu próprio SVCHOST) pára de liberar alças / 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 estão usando até 40GB de memória RAM em um servidor de 255GB. Também encontra mais de 40 milhões de alças em alguns casos.

Na reinicialização, o problema desaparece e não aparece novamente até que toda a memória tenha sido usada, digamos, pelo processo W3 ou pelas VMs do HyperV. Depois disso, o serviço Estação de Trabalho começa a capturar toda a RAM. O processo é muito lento e pode levar semanas / meses dependendo da quantidade de RAM em um servidor.

Os nossos servidores Hyper V e servidores IIS acessam compartilhamentos para arquivos de trabalho, esses compartilhamentos estão em armazenamento SSD, então eles têm bastante desempenho. Nós instalamos todos os patches atuais, mas não mudamos para o R2, já que temos muitas ferramentas implementadas, o que fará com que seja um passo significativo e não encontremos nenhuma indicação clara de que isso seria corrigido no R2.

Nós executamos o ProcMon e outras ferramentas, mas nos servidores mais problemáticos, essas ferramentas não serão executadas. Nos outros, os resultados que eles fornecem apenas mostram que parece haver um vazamento de memória nesse processo.

Existe uma maneira de liberar a memória desse processo ou evitar o bug? Não queremos ter que reinicializar e não podemos reiniciar o processo quando estiver em um estado de erro. O processo fica congelado.

Estamos tentando evitar a reinicialização regular para "corrigir" esse problema, portanto, qualquer resposta seria apreciada.

    

Answer 1

Eu tive um problema assustadoramente semelhante, no qual o svchost estava destruindo o desempenho do servidor.

A solução: Acontece que eu tinha um registro 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
- Iniciar o Visualizador de Eventos.
- Na árvore de 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 correção muito fácil. Uma reinicialização resolveria temporariamente o problema, mas, assim que qualquer coisa tentasse gravar no log, tudo ficaria fora de controle e continuaria consumindo recursos.

Espero que isso ajude!

    

Answer 2

>Is there a way we can free up the memory from this process ?

Não há como liberar (apropriadamente) externamente a memória alocada ou manipular recursos sem eliminar o aplicativo ofensivo.

>or avoid the bug all together? 

Você está tendo 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 o problema realmente está.

Você pode tentar encontrar o culpado identificando o vazamento de memória / recurso usando, por exemplo, MS Application Verifier

    

Answer 3

Criar RAM é fácil, mas não tem solução.

Eu 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 metafile.

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 a partir do compartilhamento.

Nossa solução alternativa é hospedar esses aplicativos em um Terminal Server separado e limpar com freqüência o consumo de memória.

Fazemos isso com um aplicativo de linha de comando autodescrito c ++ usando o
SetProcessWorkingSetSize () com SeDebugPrivilege em todos os processos

É altamente recomendável não fazer algo assim;)