Otimizando o tamanho do arquivo de paginação: gostaria de esclarecer sobre o Peak Commit e minha RAM física?

Otimizando o tamanho do arquivo de paginação: gostaria de esclarecer sobre o Peak Commit e minha RAM física?

Quero otimizar o tamanho do arquivo de paginação para atender às minhas necessidades reais. E quero seguir a fórmula sugerida por Mark Russinovich:O mínimo deve ser Peak Commit menos RAM física e o máximo deve ser o dobro disso.

Para ter certeza de que estou fazendo tudo certo, gostaria de esclarecer o seguinte:

1) Este número em vermelho é aquele Peak Commit mencionado pelo Sr. Russinovich?

Na tela está a janela Informações do sistema doExplorador de processos

insira a descrição da imagem aqui

2)No Painel de Controle > Sistema diz que meuRAM instalada é de 4 GB e apenas 2,45 GB podem ser usados. E obviamente, no Gerenciador de Tarefas minha memória física total também é de 2.509 MB. Isso ocorre porque meu sistema operacional é de 32 bits. Então,entendi corretamente que este 2509 (não aqueles 4 GB) é o número que devo usar para o cálculo do tamanho do arquivo de paginação?

Sei que pode ser uma pergunta boba, mas como já disse, quero ter certeza de que estou fazendo tudo certo.

Muito obrigado.

Responder1

Você sem dúvida está se referindo a"Expandindo os Limites do Windows: Memória Virtual"por Mark Russinovich.

  1. Sim, esse é o número.
  2. Sim, você só tem 2,5 GB de RAM utilizáveis ​​(aproximadamente - não há necessidade de excesso de precisão aqui).

No entanto .. você escreve sobre "fazer certo". Devo salientar que o artigo de Mark é sobre "ultrapassar os limites", e essa fórmula dá-lhe uma ideiamínimo absolutopara tamanho do arquivo de paginação. Se você deseja que seu sistema funcione bem, você não quer "ultrapassar os limites".

Não há nenhuma recomendação nesse artigo que diga que vocêdevefaça as configurações tão pequenas. Só que você pode se safar se realmente quiser. (Supondo que você nunca precise de mais memória comprometida.)

(E você pode precisar de mais. Lembre-se de que esse "pico" que você viu aqui é apenas o pico durante a execução do Process Explorer. Ele só será significativo se você executar a carga de trabalho máxima do aplicativo durante esse período. Isso não significa apenas iniciar todos os aplicativos que você acha que estará em execução ao mesmo tempo. Você também precisa fazer com que cada aplicativo use o máximo de memória privada (memória comprometida) que você solicitará. algo difícil de configurar e testar. E quem pode garantir que você nunca precisará de mais nenhum aplicativo?

Observe que se você realmente atingir esse pico novamente e tiver o arquivo de paginação definido para o mínimo calculado dessa forma, não haverá espaço na RAM para RAM usada por arquivos mapeados - como arquivos de código, como exe e dll . (Isso ocorre porque a contagem de memória virtual "confirmada" não inclui páginas de código ou outras páginas suportadas por arquivos mapeados.) Como o código precisa estar na RAM para ser executado, isso é um problema.

Ok, como você está habilitando a expansão do arquivo de paginação, não é um problema "embaraçoso". Mas certamente será um sucesso de desempenho.

Portanto, a menos que você esteja tentando, por algum motivo acadêmico, demonstrar o tamanho mínimo absoluto do arquivo de paginação que não resultará em falhas no aplicativo, independentemente dos problemas de desempenho, eu não faria dessa maneira. (Não consigo pensar em uma razão prática para fazer isso.)

Se você realmente deseja reduzir as coisas a umpráticomínimo, ou seja, sem restringir a RAM disponível para o código, simplesmente defina o tamanho mínimo do arquivo de paginação para a cobrança máxima de commit observada. Isso significa que ainda haverá RAM disponível para código, mesmo que os aplicativos e o sistema operacional tenham criado tanta memória comprometida (e referenciado tudo).

Nem há razão para limitar o tamanho máximo a apenas 2x o mínimo, a menos que você esteja muito preocupado com o uso do disco.

Veja, não há nenhum dano (além do uso de espaço em disco) ter um arquivo de paginação maior do que o sistema precisará. Em particular, um arquivo de paginação maior que o necessário não "atrairá" mais paginação para ele. E não há nenhuma vantagem em torná-lo grande o suficiente (novamente, além do uso de espaço em disco). Então, por que se preocupar? ou seja, você não está "otimizando" nada, exceto o espaço em disco ocupado por este exercício.

Dado que esgotar o limite de commit pode causar travamentos do aplicativo (e, portanto, perda de dados) e, em casos raros, até mesmo travamentos do sistema, eu não estaria tão interessado em tornar meu arquivo de paginação o menor possível.

Por outro lado, se o sistema tiver que gravar muito no arquivo de paginação - e em um sistema Windows 7 com apenas 2,5 GB de RAM utilizável, imagino que será - ter um arquivo de paginação consideravelmente maior do que o sistema jamais usará será acelerar as coisas. Por que? Porque o algoritmo de alocação de espaço usado para o arquivo de paginação pode ser muito mais rápido se houver muito espaço livre.

Por causa disso, gosto de ver o contador PerfMon para% de uso do arquivo de paginação ficar abaixo de 25%.

informação relacionada