O que está usando toda a minha memória?

4

SOLUTION: There's a lot of stuff to read in this thread, so i'll just summarize here to help.

The problem is the VMWare ESX balloon driver which "inflates" the amount of memory "in use" that the OS sees in order to force the OS to dump caches and reduce working set size. This creates a large amount of "in use" physical ram that you can't account for by looking at the processes. You can look at the VMWare console performance graph for the VM's and see the balloon driver in use.

The solution to the performance was to raise the amount of reserved memory for the server, which limits the amount of memory the balloon driver can steal from you.

Eu tenho um Windows 2003 Terminal Server de 32 bits que está executando uma cópia local do SQL Server (versão completa, não expressa) e hospeda um ambiente de desenvolvimento do Visual Studio 2008 para vários desenvolvedores. As máquinas são uma máquina virtual executada no vSphere 4, com 4 GB de memória alocada para ela.

Quando tenho 2 ou 3 usuários conectados, estou usando mais de 4 GB de memória confirmada, mas não consigo encontrar onde a maior parte dessa memória está sendo usada. Quando eu adiciono toda a memória no Gerenciador de Tarefas para todos os usuários, ela é responsável por apenas 2 GB no máximo. O que está usando o resto?

Eu tentei dar um ciclo no servidor SQL, que leva apenas a memória que vejo alocada para o SQL servr. O mesmo acontece com o visual studio, se eu desligá-lo, leva apenas a quantia que vejo alocada no Gerenciador de Tarefas do conjunto de memórias confirmadas. Eu também configurei as opções de memória para o SQL Server para usar apenas 512 MB no máximo.

Não acredito que seja um problema de sistema ou cache de arquivos, já que o Windows não inclui essa memória nas estatísticas confirmadas AFAIK.

Isso está me deixando louca. Deve haver memória mais que suficiente para todas essas coisas, com base nos valores que elas parecem estar usando. Como faço para localizar onde esta memória extra está sendo usada?

Atualizar

Em relação a quais estatísticas de memória eu estou olhando, nenhuma delas se soma.

Por exemplo, agora com 1 usuário logado e executando apenas o Visual Studio e o servidor WebDev, e SQL Server e IIS em segundo plano. Eu adiciono bytes particulares e recebo cerca de 1049740K de memória, mas o gerenciador de tarefas diz carga de compromisso é de 1146M, deixando cerca de 150Mb não contabilizados.

Quando três usuários estão logados, são apenas cerca de 2 GB de bytes privados (muita memória é compartilhada porque os usuários estão apenas executando o Visual Studio).

O tamanho da VM também não aumenta, já que normalmente não é muito diferente dos bytes particulares. Embora, curiosamente, o número seja muito diferente no Process Explorer para memória virtual do que no Gerenciador de Tarefas. O PE mostra a memória virtual do SQL Server em 1.791.444K para o SQL Server e 1.251.432K para o Visual Studio, mas a taxa de confirmação é de apenas 1146M total para a máquina.

Não há coluna para o Tamanho do WS no Gerenciador de Tarefas, mas no PE ele lista o WS como Privado e Compartilhável, e esses números são significativamente menores do que a carga de Confirmação, mesmo que seja somada.

ATUALIZAÇÃO:

Eu sei que essa pergunta tem muitos detalhes, então talvez a pergunta não esteja clara.

Como descubro quais processos estão usando toda a memória comprometida em meu sistema? A memória fornecida pelo TaskManager e pelo Process Explorer não se soma adequadamente, e mostra apenas 2GB de memória confirmada, embora 4GB está comprometido.

    
por Erik Funkenbusch 26.08.2010 / 20:46

3 respostas

1

ferramentas sql server e vmware disputam espaço de memória em uma vm. Isso provavelmente é composto pela execução de serviços de terminal e vs.

Se você ainda não o fez, entre nas configurações do vm e crie uma reserva completa de memória de 4 Gb na guia Recursos. Isso impedirá que o driver baloon tente recuperar a memória dentro da vm.

Você também pode querer configurar as opções dentro do sql server para garantir que ele apenas aloque parte da memória RAM do sistema. Talvez 2gb max.

    
por 27.08.2010 / 00:15
0

Provavelmente é um servidor SQL. Por padrão (se não me engano), o SQL Server alocará o máximo de memória possível, a menos que seja especificamente configurado para consumir uma quantidade específica de memória (acessada nas propriedades do servidor SQL). Esta memória alocada não aparece no Gerenciador de Tarefas. O que você precisa fazer é iniciar o perfmon e adicionar os contadores "SQL Server: Gerenciador de memória: Target Server Memory" e "SQL Server: Gerenciador de memória: Total Server Memory" e ver quanta memória o servidor SQL está disposto a consumir e como muita memória que realmente está consumindo.

    
por 27.08.2010 / 01:20
-2

Você está falando sério?

I have a 32-bit Windows 2003 Terminal Server that is running a local copy of SQL Server (full version, not express) and hosts a Visual Studio 2008 development environment for several developer

Assim como as informações:

MY wvirtual work environment é um sistema Windows 7 com memória 4g com Visual Studio e SQL Server. 64 bits. Eu uso em torno de 3,5 gb do que REGULARMENTE. Minha instância do Visual Studio sozinha é geralmente em torno de 500mb, além de depuração leva um monte de coisas, embora possivelmente não por muito tempo. Adicione a isso os culpados usuais (sistema de ajuda, navegadores) ....

... você é criminosamente baixo para começar. A máquina que você nota é boa para talvez um desenvolvedor em uso ativo. Dois, se não muito, é usado.

What's using the rest?

O sistema usa muito. Não se esqueça, todas as telas devem ser renderizadas, e a placa gráfica não tem uso aqui - então uma cópia de todo o buffer de memória tem que entrar (o que pode ser muito) - quais resoluções, quantas telas nós falamos aqui? ?, dado 2003 eu assumo um por desenvolvedor)

Dica:

Atualize para:

  • 2008 R2. MUCh better RDP, incluindo SETUP MULTI MONITOR. Eu trabalho com 2 telas remotamente no momento, o 2008 R2 copia a configuração do meu monitor do meu cliente Windows 7. MUITO legal para trabalhar. Essa atualização para mim realmente tornou o trabalho remoto ALGUMA VEZ utilizável - estou acostumado a trabalhar com 2+ telas há anos, o Remote sempre foi paifull.
  • SO de 64 bits. 32 bits só não é isso. Mesmo com todo o software sendo de 32 bits (VIsual Studio etc.) o hsot de 64 bits pode ter muito mais memória e de fato distribuir 3GB para cada processo iniciado. E há alguns problemas.

E você precisará de muito mais RAM. Eu diria que 2gb PER DEVELOPER é um bom lineup (dado 2+ desenvolvedores). Você pode fugir com menos, mas não é muito provável. Depende do que eles realmente fazem - mas aplicativos grandes no Visual Studio têm muita memória. Especiariamente durante as compilações,

    
por 26.08.2010 / 21:43