Pressão de memória com 5 GB usada como caches?

Question

Eu gerencio uma estação de trabalho bastante poderosa, mas por alguma razão a caixa é muito lenta. Olhando para o gerenciador de tarefas, vejo que quase nenhuma memória é livre e muito é usado como caches (o que o IMO deve ser muito semelhante a ser livre) - no entanto, a máquina está trocando muito. Há um bom número de processos grandes abertos (Lotus Notes, Word, duas cópias do Visual Studio), mas IMO isso não deve derrubar uma máquina como esta ao ponto de ficar inutilizável (a tarefa de comutação leva vários minutos, digitando no A janela ativa faz com que o SO perceba que o aplicativo não está respondendo, etc.).

O SO é o Win7 de 64 bits, tenho um disco rígido normal e um SSD de 32 GB para o ReadyBoost instalado. Existe alguma configuração obscura que eu possa distorcer para permitir que o sistema use mais memória para mapeamentos privados em vez de caches de disco, ou estou interpretando mal os números? Há alguma outra coisa que eu possa tentar melhorar o desempenho do sistema?

    

Answer 1

Ughh. O Gerenciador de Tarefas é uma ferramenta bastante ruim para medir o desempenho.

Por exemplo, quando eu avalio o desempenho de uma equipe esportiva, vejo as estatísticas de um jogo ou de muitos jogos?

Além disso, o cérebro humano coloca mais ênfase e, portanto, peso em pontos de dados recentes, em comparação com pontos de dados talvez mais significativos, porém distantes.

O mito da memória livre

From my understanding, the system should always keep a few "free" (i.e. zeroed) pages so it can >map those quickly when a process requests it (so pages can be cleared from another CPU while the >requesting process can proceed).

Zerar as páginas de memória é um processo bastante trivial na máquina de hoje. O acesso ao disco, mesmo com SSDs de primeira linha, domina a lista de fatores de desempenho lentos. Há uma razão pela qual a memória livre e o acesso ao disco são correlacionados no desempenho, pois para um aplicativo, eles são uma e a mesma coisa: armazenamento secundário. Embora a pouca memória possa fazer com que um SO vá para o disco, a partir de minhas observações de gráficos de desempenho, acesso a disco e latência de rede (Ughh, odeio nosso ISP) dominam as preocupações de desempenho de hoje.

Também é impossível ler o impacto de ter memória livre (páginas zeradas) na sua máquina. Nós não temos idéia sobre o pico de commits, pico # de falhas de página, # de páginas, etc. Eu aconselharia não tirar conclusões precipitadas sobre o que é literalmente um instantâneo .

Minhas sugestões

Aceite muitos pontos de dados.

Se você tiver acesso de administrador local à sua máquina, acesse perfmon e use o Coletor de conjunto de dados padrão Desempenho do sistema . Colete os pontos de dados a cada 10 a 15 segundos e execute-os por vários dias.

Veja também em que local do seu fluxo de trabalho uma máquina mais rápida ajudaria. É possível que uma máquina mais rápida faça muito pouco. Por exemplo, o VS2010 pode ser um hog de memória durante as compilações, pois ele precisa carregar todas as dependências do seu projeto. Eu conheço alguns lugares onde eles pegam vários Pentium 4s antigos e "terceirizam" compilações para eles.

A "lentidão" também pode ser atribuída à própria aplicação. Nem todos os programas são projetados para tirar proveito de muita memória livre. Alguns aplicativos são bastante agressivos em manter um perfil com pouca memória, mas manter os dados no disco, já que o espaço em disco é de pouca preocupação.