Você abre o Gerenciador de Tarefas do Windows 11, entra em Desempenho → Memória e encontra uma informação que muita gente simplesmente ignora:
Confirmado: 18,4/31,7 GB
Em outro computador pode aparecer:
Confirmado: 7,2/23,8 GB
ou:
Confirmado: 28,9/31,7 GB
O que significam esses dois números?
O primeiro representa a quantidade de memória que o Windows assumiu o compromisso de fornecer naquele momento? O segundo é a quantidade de RAM instalada? É o tamanho do arquivo de paginação? É RAM mais SSD? É memória virtual?
A resposta exige entender um dos conceitos mais importantes — e frequentemente mal interpretados — do gerenciamento de memória do Windows:
Commit.
Quando entendemos Commit, vários comportamentos aparentemente estranhos começam a fazer sentido.
Por exemplo:
- Windows informa pouca memória mesmo sem RAM física chegar exatamente a 100%;
- aumentar ou remover o
pagefile.sysaltera o limite de memória disponível para determinadas alocações; - um programa pode reservar grandes quantidades de memória sem manter tudo residente na RAM naquele instante;
- o Gerenciador de Tarefas apresenta “Confirmado” com dois números;
- Working Set não é a mesma coisa que Commit;
- memória virtual não significa simplesmente “arquivo de paginação”;
- ter muita RAM não torna automaticamente o pagefile inútil;
- um vazamento de memória pode fazer o Commit crescer continuamente;
- fechar um programa pode provocar uma queda muito maior no Commit do que parecia sugerir a coluna Memória.
Este artigo vai explicar tudo isso começando pelo conceito fundamental.
O que significa Commit no Windows?
Em português, podemos encontrar traduções como memória confirmada ou memória comprometida.
O conceito é mais importante que a tradução.
Quando determinada memória privada precisa ter backing garantido, o Windows precisa ser capaz de sustentá-la por meio dos recursos disponíveis para esse tipo de compromisso.
De maneira simplificada, podemos pensar:
aplicativo solicita memória privada comprometida
↓
Windows assume um compromisso
↓
essa memória precisa ter backing possível
↓
RAM e/ou pagefile participam do limite
Isso é Commit.
Commit não é simplesmente RAM utilizada
Esse é o primeiro ponto fundamental.
Imagine que o Gerenciador de Tarefas mostre:
RAM física em uso: 12 GB
e:
Confirmado: 18/32 GB
Não existe contradição.
Os números medem coisas diferentes.
Working Set também não é Commit
Outro erro muito comum consiste em olhar a coluna Memória de um programa e acreditar que aquele número representa toda a memória comprometida por ele.
Não necessariamente.
Precisamos separar conceitos.
O que é Working Set?
De maneira simplificada, o Working Set representa páginas de memória de um processo que estão atualmente residentes na memória física.
Ou seja, estão efetivamente presentes na RAM naquele momento.
Podemos representar:
Processo
↓
Working Set
↓
páginas atualmente residentes na RAM
E o Commit?
Commit responde a outra questão:
quanto de memória comprometida precisa ser suportado pelo sistema?
Portanto:
Working Set ≠ Commit
Exemplo simplificado
Imagine um aplicativo que possui:
Commit: 6 GB
mas:
Working Set: 2,5 GB
Isso não significa que o Windows perdeu 3,5 GB.
Significa que estamos comparando duas métricas diferentes.
Por que isso acontece?
Nem todas as páginas comprometidas precisam estar fisicamente residentes na RAM simultaneamente.
Algumas podem não estar residentes naquele instante.
Outras situações do gerenciamento de memória também precisam ser consideradas.
O Windows move, reutiliza e gerencia páginas conforme a demanda.
Então Commit fica no SSD?
Também não devemos simplificar dessa maneira.
É incorreto dizer:
“Commit é memória que está no pagefile.”
Commit é um compromisso de backing, não a localização física atual de cada página.
Uma página comprometida pode estar:
- residente na RAM;
- respaldada de maneira apropriada pelo sistema;
- em diferentes estados ao longo de sua vida.
Pagefile e Commit estão relacionados, mas não são sinônimos
O arquivo:
pagefile.sys
participa do gerenciamento de memória virtual do Windows.
Ele também é importante para determinar o Commit Limit.
Mas:
Commit ≠ pagefile
e:
memória virtual ≠ pagefile
Essas distinções são fundamentais.
O que é Commit Charge?
O termo Commit Charge descreve a quantidade total de memória comprometida atualmente pelo sistema.
No Gerenciador de Tarefas moderno, isso aparece de forma mais amigável na informação:
Confirmado
Por exemplo:
18,4/31,7 GB
De maneira conceitual:
18,4 GB = Commit atual
31,7 GB = Commit Limit
O que é Commit Limit?
Commit Limit é o limite aproximado até o qual o sistema consegue sustentar memória comprometida.
De forma simplificada, ele depende principalmente de:
RAM física + pagefile(s)
com ajustes e reservas internas do sistema.
Por isso, não devemos esperar que uma soma manual produza sempre exatamente o mesmo número exibido pelo Windows.
Exemplo didático
Computador:
RAM = 16 GB
Pagefile:
16 GB
Podemos imaginar um Commit Limit na região de:
RAM + pagefile
mas o número efetivamente apresentado pelo Windows pode diferir por causa das estruturas e reservas internas.
A ideia é entender a relação, não usar essa soma como fórmula contábil exata.
Agora podemos interpretar “Confirmado 18/32 GB”
Quando aparece:
18/32 GB
podemos interpretar aproximadamente:
o sistema possui cerca de 18 GB de Commit Charge contra um Commit Limit próximo de 32 GB.
Isso não significa:
18 GB estão no pagefile
nem:
18 GB estão na RAM.
Essa diferença muda completamente o diagnóstico
Imagine:
RAM instalada: 16 GB
RAM em uso: 11 GB
Confirmado: 30/31 GB
O usuário olha apenas a RAM:
“Ainda existem alguns gigabytes, então não pode estar faltando memória.”
Mas o Commit está perigosamente próximo do limite.
O sistema pode ficar sem Commit antes da RAM física chegar exatamente a 100%
Sim.
Esse é um dos motivos pelos quais mensagens de memória insuficiente podem confundir.
O problema pode estar relacionado à incapacidade de assumir novos compromissos de memória, e não simplesmente ao gráfico da RAM física encostar em 100%.
Exemplo
Imagine:
RAM instalada: 16 GB
RAM em uso: 12,5 GB
Commit: 30,8/31,2 GB
Um aplicativo solicita:
+1 GB de memória comprometida
O sistema pode não ter Commit disponível suficiente para satisfazer aquela solicitação.
“Mas ainda havia RAM disponível!”
Esse raciocínio mistura:
memória física
com:
Commit Limit.
São recursos relacionados, mas não idênticos.
É aqui que muitos erros de “memória insuficiente” começam a fazer sentido
O usuário pensa:
memória insuficiente = RAM 100%
Mas um diagnóstico mais correto pergunta:
- quanto existe de RAM física?
- quanto está em uso?
- quanto está disponível?
- qual é o Commit Charge?
- qual é o Commit Limit?
- existe pagefile?
- qual o tamanho dele?
- algum processo está aumentando o Commit continuamente?
O que acontece quando o Commit se aproxima do limite?
O Windows passa a ter cada vez menos capacidade para aceitar novas alocações que exigem Commit.
Aplicativos podem começar a apresentar:
- falha ao alocar memória;
- mensagens de memória insuficiente;
- encerramento inesperado;
- erros;
- instabilidade.
Isso significa que o Windows sempre trava ao atingir exatamente 100%?
Não devemos esperar um comportamento único.
Diferentes programas lidam de formas diferentes com falhas de alocação.
Um aplicativo pode:
- mostrar erro;
- encerrar uma operação;
- fechar;
- travar;
- lidar corretamente com a falha.
O que significa “Out of Memory”?
Out of Memory não deve ser traduzido mentalmente apenas como:
“acabou a RAM física.”
Dependendo do contexto, pode significar que determinada solicitação de memória não pôde ser atendida.
Commit é uma das primeiras métricas que merecem análise.
O pagefile aumenta o Commit Limit?
Em termos gerais, sim.
Um pagefile fornece backing adicional e, consequentemente, permite ao Windows sustentar um Commit Limit maior.
Essa é uma das razões pelas quais a frase:
“Tenho 32 GB de RAM, então posso desativar o pagefile”
é simplista demais.
Mais RAM não torna o pagefile conceitualmente inútil
Um computador com muita RAM pode raramente precisar paginar grandes quantidades de memória por pressão física.
Mas isso não significa que o pagefile não tenha outras implicações para o gerenciamento de memória e o Commit Limit.
Exemplo: computador com 32 GB e pagefile
Imagine:
RAM: 32 GB
pagefile: gerenciado pelo sistema
Commit Limit: significativamente acima dos 32 GB
Agora desativamos o pagefile.
Depois do reinício, o Commit Limit tende a ficar muito mais próximo do que a RAM física pode sustentar, descontadas as necessidades internas.
O computador ficou mais rápido?
Não podemos concluir isso.
O que fizemos foi reduzir a margem disponível para Commit.
E se o computador nunca passa de 10 GB?
Talvez o usuário nunca perceba diferença em sua carga normal.
Mas isso não transforma a desativação do pagefile em uma otimização universal.
E em uma carga pesada?
Imagine:
- máquina virtual;
- navegador com muitas abas;
- edição;
- renderização;
- compilação;
- jogo;
- aplicativo profissional.
O Commit pode crescer muito além do que o usuário esperava apenas olhando o consumo físico instantâneo.
O pagefile não deve ser tratado como “RAM lenta”
Essa frase aparece bastante:
“Quando a RAM acaba, o Windows usa o SSD como RAM.”
Ela ajuda em uma explicação muito básica, mas fica imprecisa quando queremos compreender o gerenciamento real de memória.
Paginação é mais complexa
O Windows trabalha com:
- páginas;
- working sets;
- listas de páginas;
- memória compartilhada;
- arquivos mapeados;
- memória comprometida;
- backing;
- pagefile;
- cache;
- prioridades.
Reduzir tudo a:
RAM cheia → usa SSD
esconde conceitos importantes.
Commit também não significa “memória reservada fisicamente”
Um processo pode comprometer uma quantidade de memória sem exigir que toda ela esteja residente na RAM ao mesmo tempo.
Isso explica parte da diferença entre:
Commit Size
e:
Working Set.
Como visualizar o Commit de um processo?
Abra:
Gerenciador de Tarefas
e vá para:
Detalhes
Clique com o botão direito nos títulos das colunas e escolha a opção para selecionar colunas.
Dependendo da tradução e versão do Windows, procure uma coluna relacionada ao:
Tamanho da confirmação / Commit size
Ela oferece outra perspectiva sobre o consumo de memória dos processos.
Compare Memória e Commit Size
Imagine:
programa.exe
Working Set aproximado: 1,8 GB
Commit Size: 7,5 GB
Isso é uma informação extremamente interessante.
Qual dos dois está certo?
Os dois.
Eles estão medindo coisas diferentes.
Um programa pode ter Commit enorme e Working Set pequeno
Sim.
Isso pode acontecer dependendo da forma como o aplicativo aloca e utiliza memória.
E o contrário?
Também precisamos considerar memória compartilhada e outros tipos de páginas, portanto comparar números isolados sem compreender sua composição pode gerar interpretações erradas.
Private Bytes entra nessa história
Ferramentas avançadas também podem mostrar métricas como:
Private Bytes.
Esse conceito se aproxima da quantidade de memória privada comprometida pelo processo, embora diferentes ferramentas e contadores devam ser interpretados conforme suas definições específicas.
Process Explorer ajuda bastante
O Process Explorer, da Microsoft Sysinternals, oferece informações mais detalhadas sobre processos e memória do que a visualização básica do Gerenciador de Tarefas.
Podemos comparar:
- Working Set;
- Private Bytes;
- Commit;
- memória virtual;
- outras métricas.
Não escolha o culpado apenas pelo Working Set
Imagine:
Processo A
Working Set: 4 GB
Commit: 4,5 GB
Processo B
Working Set: 1 GB
Commit: 15 GB
Se o problema é Commit Limit, o Processo B pode ser muito mais interessante para a investigação.
Isso explica por que ordenar somente por “Memória” pode esconder a causa
A coluna padrão foi criada para fornecer uma visão prática, não para substituir análise de gerenciamento de memória.
Vazamento de Commit
Assim como outras formas de consumo de recursos, um processo pode apresentar crescimento progressivo de memória comprometida.
Exemplo:
09:00 → Commit 800 MB
11:00 → 2,5 GB
13:00 → 6 GB
15:00 → 12 GB
17:00 → 20 GB
Se o padrão continua e a memória não é liberada adequadamente, temos uma possível situação de vazamento que merece investigação.
Isso é diferente do post anterior sobre Nonpaged Pool
No artigo anterior, analisamos principalmente:
Paged Pool
e:
Nonpaged Pool
com atenção especial a vazamentos de drivers e Pool Tags.
Agora estamos olhando outra dimensão:
Commit do sistema e dos processos.
Os dois problemas podem produzir “RAM alta”?
Sim.
Mas o caminho de diagnóstico não é o mesmo.
Cenário A — Nonpaged Pool
RAM alta
processos não explicam
Nonpaged Pool cresce
Nesse caso, PoolMon e Pool Tags ganham importância.
Cenário B — Commit
Commit 30/31 GB
processo apresenta Commit Size crescente
Nesse cenário, precisamos investigar a alocação daquele processo e por que o Commit está se aproximando do limite.
Cenário C — muita RAM usada, mas Commit confortável
Também pode acontecer.
Exemplo:
RAM em uso: 28/32 GB
Commit: 18/50 GB
A memória física está bastante utilizada, mas o sistema ainda possui grande margem de Commit.
Isso exige outro tipo de interpretação.
Portanto, RAM e Commit respondem perguntas diferentes
Podemos resumir:
RAM física
Quanto da memória física está sendo utilizada agora?
Working Set
Quanto da memória de determinado processo está residente na RAM?
Commit
Quanto de memória comprometida precisa ser suportado pelo sistema?
Commit Limit
Até onde o sistema pode sustentar esse compromisso antes de novas alocações começarem a falhar?
Pagefile
Um dos recursos que participa do backing e amplia a capacidade de Commit do sistema.
Essa separação é a base de todo o restante do artigo
Quando o usuário diz:
“Tenho 32 GB de RAM e o Windows falou que estava sem memória”
não devemos responder imediatamente:
“Então existe defeito na RAM.”
Nem:
“Aumente o pagefile.”
Nem:
“Desative o pagefile.”
Primeiro precisamos olhar:
RAM
Commit atual
Commit Limit
pagefile
processos
Working Set
Commit Size
e o comportamento desses números ao longo do tempo.
O diagnóstico começa com uma fotografia, mas termina com uma linha do tempo
Uma captura mostrando:
Confirmado: 28/32 GB
é útil.
Mas muito melhor seria descobrir:
08:00 → 8 GB
10:00 → 11 GB
12:00 → 16 GB
14:00 → 22 GB
16:00 → 28 GB
Agora sabemos que alguma coisa está crescendo.
A próxima pergunta passa a ser:
quem está fazendo o Commit aumentar?
Como interpretar “Confirmado X/Y GB”, Commit Limit, Working Set e pagefile.sys
Agora que entendemos a ideia fundamental de Commit, podemos analisar uma das informações mais importantes do Gerenciador de Tarefas:
Confirmado: X/Y GB
Essa pequena linha pode revelar situações que não ficam evidentes quando observamos somente o percentual de utilização da RAM.
Vamos usar um exemplo:
Confirmado: 18,2/31,8 GB
Temos dois valores.
De maneira simplificada:
18,2 GB = Commit Charge atual
31,8 GB = Commit Limit
O primeiro mostra quanto de Commit está sendo utilizado naquele momento.
O segundo representa o limite atual disponível para esse tipo de compromisso de memória.
Por que o Windows mostra dois números?
Porque saber apenas quanto já foi comprometido não basta.
Precisamos conhecer também o limite.
Compare:
Computador A
Confirmado: 18/64 GB
Computador B
Confirmado: 18/20 GB
Os dois possuem aproximadamente 18 GB comprometidos.
Mas a situação é completamente diferente.
Computador A
Ainda existe grande margem:
64 - 18 = 46 GB
de diferença matemática entre os valores mostrados.
Isso não significa que 46 GB de RAM estejam livres.
Significa que o Commit atual está distante do Commit Limit.
Computador B
Temos:
20 - 18 = 2 GB
A margem está muito menor.
Novas alocações que exigem Commit podem começar a enfrentar problemas se o consumo continuar crescendo.
Portanto, o segundo número muda completamente a interpretação
Nunca analise:
Confirmado: 18 GB
sem saber:
18 de quanto?
Onde encontrar “Confirmado” no Windows 11?
Abra:
Ctrl + Shift + Esc
Entre em:
Desempenho → Memória
Procure:
Confirmado
Você verá algo semelhante a:
8,4/23,7 GB
ou:
27,1/47,6 GB
Os valores dependem da configuração do computador e do estado atual do sistema.
Por que o segundo número não é igual à RAM instalada?
Essa dúvida aparece frequentemente.
Imagine:
RAM instalada: 16 GB
mas:
Confirmado: 7,8/25,3 GB
Por que o limite é maior que 16 GB?
Porque o Commit Limit não corresponde simplesmente à quantidade de RAM física.
O pagefile também participa desse limite.
Um exemplo didático
Considere:
RAM física = 16 GB
e um pagefile configurado pelo sistema.
O Windows pode apresentar:
Commit Limit > 16 GB
porque existe backing adicional fornecido pelo arquivo de paginação.
Então a fórmula é RAM + pagefile?
Como aproximação conceitual, podemos pensar dessa forma:
Commit Limit ≈ RAM + pagefile - ajustes/reservas
Mas não utilize essa expressão como uma fórmula exata.
O Windows possui estruturas, reservas e detalhes internos que fazem com que o número real não precise coincidir exatamente com uma soma feita manualmente.
O importante é entender a relação
Se você aumenta a capacidade disponível de pagefile, o Commit Limit pode aumentar.
Se remove o pagefile, o Commit Limit diminui significativamente.
Vamos demonstrar conceitualmente
Computador:
RAM = 16 GB
Situação A — pagefile ativo
Commit Limit ≈ 30 GB
Situação B — sem pagefile
Commit Limit ≈ próximo da capacidade física disponível para Commit
Os números acima são apenas exemplos didáticos.
O comportamento real depende da máquina.
Agora imagine um aplicativo profissional
O sistema está em:
Commit = 13 GB
O aplicativo precisa de mais:
8 GB
Na situação A, pode existir margem suficiente.
Na situação B, a solicitação pode encontrar um limite muito menor.
Isso explica por que desativar pagefile pode criar erros que antes não existiam
O usuário pensa:
“Tenho RAM suficiente.”
Mas alterou outra coisa:
reduziu o Commit Limit.
O pagefile não serve apenas para quando a RAM chega a 100%
Esse é um dos maiores mitos sobre memória no Windows.
A explicação popular costuma ser:
Quando acaba a RAM, o Windows começa a usar o pagefile.
Isso é simplificado demais.
O sistema pode gerenciar páginas e pagefile muito antes de uma situação visual de “RAM 100%”.
O Windows tenta utilizar a RAM de maneira eficiente
RAM física é muito mais rápida que armazenamento.
O sistema mantém páginas importantes residentes quando possível.
Mas também precisa equilibrar:
- working sets;
- cache;
- páginas modificadas;
- páginas compartilhadas;
- memória comprometida;
- pressão de memória.
Pagefile não é uma segunda RAM
Não devemos imaginar:
16 GB RAM + 16 GB pagefile = 32 GB de RAM
Isso seria errado.
O SSD não passa a ter latência e largura de banda de DRAM.
Então por que somamos conceitualmente no Commit Limit?
Porque estamos discutindo capacidade de backing para memória comprometida, não desempenho equivalente à RAM.
São conceitos diferentes.
Commit Limit não mede velocidade
Ele mede capacidade.
Essa frase ajuda bastante:
RAM determina residência física; Commit Limit determina quanto compromisso de memória o sistema consegue sustentar.
Ainda é uma simplificação, mas é muito melhor que chamar pagefile de “RAM extra”.
Agora precisamos falar de Working Set com mais profundidade
Quando um processo executa, nem todas as páginas relacionadas a ele precisam estar residentes fisicamente ao mesmo tempo.
O conjunto atualmente residente recebe o nome de:
Working Set.
Exemplo
Um aplicativo pode apresentar:
Commit Size: 10 GB
e:
Working Set: 3 GB
Isso não significa que existe erro.
Por que a diferença pode ser tão grande?
Porque Commit e Working Set medem aspectos diferentes.
O Commit representa memória privada comprometida que precisa de backing.
O Working Set representa páginas atualmente residentes na RAM.
Imagine uma biblioteca
Podemos criar uma analogia.
Commit
O sistema garante que existem lugares suficientes para armazenar determinado conjunto de livros.
Working Set
Representa os livros que estão atualmente sobre sua mesa.
Você pode ter direito a armazenar 100 livros sem manter todos os 100 sobre a mesa ao mesmo tempo.
A analogia não descreve todos os detalhes do Windows, mas ajuda a separar os conceitos.
Um processo pode ter Working Set reduzido sem liberar Commit
Esse ponto é importantíssimo.
O Windows pode reduzir o Working Set de um processo.
Isso não significa necessariamente que o processo liberou a memória comprometida.
Portanto, “o processo caiu de 5 GB para 1 GB” não significa automaticamente que liberou 4 GB de Commit
Talvez parte das páginas simplesmente tenha deixado de permanecer residente.
É por isso que precisamos olhar mais de uma métrica
Para diagnóstico avançado:
- Working Set;
- Private Working Set;
- Private Bytes;
- Commit Size;
podem fornecer perspectivas diferentes.
O que é Private Working Set?
É a parte do Working Set associada a páginas privadas daquele processo.
Isso ajuda a diferenciar memória privada de páginas compartilhadas.
E o que é memória compartilhada?
Algumas páginas podem estar presentes nos working sets de mais de um processo.
Por exemplo, código e componentes compartilhados podem participar desse cenário.
Por isso somar Working Sets pode contar memória compartilhada mais de uma vez
Esse é outro motivo pelo qual somar números de processos e comparar diretamente com RAM física pode produzir resultados estranhos.
O que é Private Bytes?
Private Bytes é uma métrica importante para investigar quanto de memória privada comprometida está associado a um processo.
Em ferramentas de diagnóstico, ela costuma ser extremamente útil para encontrar crescimento de Commit associado a aplicações.
Private Bytes e Working Set podem divergir bastante
Exemplo:
Private Bytes: 12 GB
Working Set: 2,8 GB
Se o Commit global está próximo do limite, esse processo merece atenção mesmo que a coluna de memória padrão não pareça assustadora.
Process Explorer
O Process Explorer, da Microsoft Sysinternals, permite enxergar essas métricas com mais detalhes.
Ele é especialmente útil quando o Gerenciador de Tarefas não fornece toda a granularidade necessária.
O que procurar?
Em uma investigação de Commit, podemos observar principalmente:
- Private Bytes;
- Working Set;
- Private Working Set;
- evolução ao longo do tempo.
Não olhe apenas o maior número
Queremos encontrar:
crescimento.
Exemplo de leak
08:00
Private Bytes: 500 MB
10:00
1,7 GB
12:00
4,5 GB
14:00
9,2 GB
16:00
17 GB
Isso é muito mais interessante que encontrar um programa estável em 5 GB.
Um programa grande pode ser normal
Editor de vídeo:
Private Bytes: 8 GB
estável durante horas.
Talvez seja completamente esperado para aquela carga.
Um programa pequeno que cresce sem parar pode ser o verdadeiro problema
300 MB
↓
900 MB
↓
2 GB
↓
6 GB
↓
14 GB
O padrão temporal muda o diagnóstico.
O Gerenciador de Tarefas também pode mostrar Commit Size
Abra:
Gerenciador de Tarefas → Detalhes
Clique com o botão direito no cabeçalho das colunas.
Selecione:
Selecionar colunas
Procure uma coluna relacionada a:
Tamanho da confirmação / Commit size
A nomenclatura pode variar conforme idioma e versão do Windows.
Ordene por Commit Size
Isso pode revelar processos que não pareciam grandes quando observados apenas pela coluna padrão de memória.
Exemplo
| Processo | Memória visível | Commit Size |
|---|---|---|
| app1.exe | 2,4 GB | 3 GB |
| app2.exe | 1,1 GB | 12 GB |
| app3.exe | 800 MB | 1 GB |
Se o Commit global está quase no limite, app2.exe merece atenção.
Mas o Commit global não é simplesmente a soma dessa coluna
Não transforme essa tabela em outra soma manual simplificada.
O gerenciamento de memória do sistema envolve mais componentes.
Use a coluna para identificar processos relevantes, não para reconstruir internamente todos os cálculos do Windows.
Performance Monitor: acompanhando Commit ao longo do tempo
Para problemas que demoram horas ou dias, o Performance Monitor é extremamente útil.
Execute:
perfmon
O Windows possui contadores que permitem acompanhar memória e processos ao longo do tempo.
Um contador muito importante
Entre os contadores relacionados a memória, podemos trabalhar com métricas como:
Committed Bytes
e:
Commit Limit
Isso permite visualizar o crescimento do Commit do sistema.
Também podemos acompanhar processos
Contadores relacionados a processos ajudam a observar métricas como:
Private Bytes
por processo.
Por que isso é melhor que ficar olhando a tela?
Porque podemos registrar comportamento durante várias horas.
Exemplo
Você suspeita que um serviço apresenta leak depois de aproximadamente 12 horas.
Não faz sentido ficar olhando o Gerenciador de Tarefas o dia inteiro.
Crie um conjunto de coleta apropriado e acompanhe o comportamento.
Gráfico esperado de um leak
Algo semelhante a:
500 MB
700 MB
1,1 GB
2 GB
4 GB
8 GB
15 GB
sem retorno significativo.
Um padrão serrilhado pode ser normal
Imagine:
2 GB → 4 GB → 2,5 GB → 5 GB → 3 GB
Isso pode indicar alocações e liberações normais de acordo com a carga.
Não basta ver picos.
Vazamento costuma apresentar tendência
A palavra importante é:
tendência.
Commit pode cair quando fecho um aplicativo?
Sim.
Se o processo termina, suas alocações privadas são liberadas e o Commit correspondente pode diminuir.
Isso é um teste útil
Imagine:
Commit global: 29/32 GB
Você encerra corretamente um aplicativo suspeito.
Depois:
Commit global: 12/32 GB
Isso é uma pista extremamente importante.
Agora abra novamente
Se:
12 GB
↓
18 GB
↓
23 GB
↓
29 GB
com o mesmo aplicativo, temos um padrão reproduzível.
Não finalize o processo sem salvar documentos
Para diagnóstico, prefira fechar o aplicativo corretamente.
Evite perda de dados.
E se fechar o programa não reduzir o Commit?
Talvez:
- outro processo relacionado continue ativo;
- serviço continue rodando;
- driver esteja envolvido;
- a causa esteja em outro componente.
É aqui que o artigo anterior complementa este
Se os processos não explicam e:
Nonpaged Pool cresce
volte para o diagnóstico de kernel e drivers.
Commit alto não significa necessariamente leak
Outro ponto essencial.
Imagine uma máquina com várias VMs.
Commit = 45 GB
Talvez isso seja esperado.
Se:
Commit Limit = 80 GB
e a carga realmente exige aquela memória, não existe necessariamente problema.
O contexto decide
Pergunte:
essa quantidade é esperada para a carga?
Exemplo com 8 GB de RAM
Computadores com 8 GB possuem margem física pequena para cargas modernas.
Imagine:
RAM: 8 GB
Commit: 10/15 GB
Isso pode funcionar, mas já existe dependência maior do gerenciamento de memória e do pagefile conforme a carga.
Exemplo com 16 GB
RAM: 16 GB
Commit: 14/28 GB
Existe margem razoável de Commit.
Mas isso não nos diz sozinho se o desempenho está bom.
Exemplo com 32 GB
RAM: 32 GB
Commit: 28/45 GB
Pode ser perfeitamente normal em uma estação de trabalho pesada.
Exemplo com 64 GB
RAM: 64 GB
Commit: 70/90 GB
Observe algo interessante:
o Commit pode ser maior que a RAM física instalada.
Isso não é erro.
Commit maior que RAM não significa que tudo acima de 64 GB está necessariamente escrito no pagefile naquele instante
Novamente:
Commit não é localização.
Essa distinção precisa ficar clara.
E o tamanho atual do pagefile?
O Windows pode trabalhar com pagefile gerenciado pelo sistema.
Dependendo da configuração e da pressão de Commit, seu tamanho pode ser ajustado dentro das condições permitidas.
Onde configurar o pagefile?
No Windows 11, as opções tradicionais ficam nas configurações avançadas de desempenho e memória virtual.
Um caminho possível passa por:
Propriedades do Sistema → Avançado → Desempenho → Configurações → Avançado → Memória virtual
A interface pode variar entre versões do Windows 11.
“Gerenciar automaticamente” costuma ser a melhor escolha?
Para a maioria dos usuários, deixar o Windows gerenciar o arquivo de paginação é uma escolha sensata.
Configurações manuais fazem mais sentido quando existe uma necessidade específica e o administrador entende suas implicações.
O mito do pagefile com tamanho fixo
Durante muitos anos circularam fórmulas como:
pagefile = 1,5 × RAM
ou:
pagefile = 2 × RAM
Essas regras não devem ser tratadas como universais para computadores modernos.
Uma máquina com 8 GB e outra com 128 GB têm cargas completamente diferentes
Não faz sentido aplicar a mesma multiplicação sem considerar:
- workload;
- dumps;
- Commit;
- armazenamento;
- políticas;
- aplicações.
O pagefile também pode ser importante para crash dumps
Além do Commit, determinadas configurações de despejo de memória após falhas do sistema possuem requisitos relacionados à paginação.
Isso é outro motivo para não desativar pagefile de forma automática.
“Meu SSD vai gastar por causa do pagefile”
SSDs possuem vida útil finita de gravação, mas desativar paginação apenas por medo genérico de desgaste não é uma recomendação universal.
O impacto real depende da carga e do dispositivo.
Se o Windows pagina excessivamente, precisamos descobrir por quê
Talvez o computador realmente tenha pouca RAM para a carga.
Talvez exista leak.
Talvez existam aplicações demais.
A resposta não deve ser simplesmente:
“desative o pagefile para impedir paginação.”
Isso pode piorar o problema
Sem pagefile, você reduz o Commit Limit e pode fazer alocações falharem mais cedo.
Pagefile não corrige falta física de RAM
O contrário também precisa ficar claro.
Se um computador com 8 GB precisa manter 20 GB de working sets ativos, aumentar pagefile não transforma o SSD em 12 GB de DRAM adicional.
O desempenho pode continuar ruim devido à pressão de memória.
Capacidade e desempenho são perguntas diferentes
Commit Limit
Pergunta:
o sistema consegue sustentar a alocação?
RAM física
Pergunta:
quantas páginas podem permanecer residentes rapidamente?
Essa diferença explica muita coisa.
Um computador pode ter Commit disponível e ainda estar lento por falta de RAM
Sim.
Exemplo:
Commit: 15/40 GB
mas:
RAM física: 8 GB
Uma carga pesada pode gerar grande pressão sobre a memória física.
O Commit Limit está confortável, mas o desempenho pode sofrer.
E o contrário também
O computador pode ter RAM física aparentemente disponível, mas Commit quase esgotado.
Exemplo:
RAM utilizada: 12/16 GB
Commit: 30,5/31 GB
Agora o risco está no limite de Commit.
É por isso que olhar apenas “85% de RAM” é insuficiente
O diagnóstico precisa combinar métricas.
Tabela de interpretação rápida
| RAM física | Commit | Possível interpretação |
|---|---|---|
| baixa utilização | baixo | situação leve |
| alta utilização | Commit confortável | pressão física possível |
| moderada utilização | Commit quase no limite | risco de falha de alocação |
| alta utilização | Commit quase no limite | pressão severa |
| processos pequenos + Nonpaged alto | investigar drivers/kernel | |
| processo com Private Bytes crescendo | investigar leak do processo |
Primeira metodologia VMIA para Commit
Quando aparecer erro de memória insuficiente:
1. Abra o Gerenciador de Tarefas
Vá para:
Desempenho → Memória
2. Registre
RAM em uso
RAM disponível
Confirmado X/Y
Paged Pool
Nonpaged Pool
3. Vá para Detalhes
Adicione a coluna relacionada a:
Commit Size
4. Ordene os processos
Procure valores elevados e crescimento.
5. Compare ao longo do tempo
Não confie apenas em uma captura.
6. Use Process Explorer
Observe principalmente:
Private Bytes
e:
Working Set
7. Para problemas longos, use Performance Monitor
Registre:
Committed Bytes
Commit Limit
e métricas do processo suspeito.
8. Verifique o pagefile
Descubra se:
- está ativo;
- está gerenciado pelo sistema;
- foi desativado manualmente;
- possui alguma limitação incomum.
9. Não altere antes de medir
Primeiro registre o comportamento atual.
10. Depois faça teste A/B
Altere uma variável por vez.
Por que o Windows pode ficar sem memória mesmo com RAM disponível?
Chegamos a uma das partes mais importantes deste artigo.
O usuário abre o Gerenciador de Tarefas e encontra algo parecido com:
RAM instalada: 32 GB
RAM em uso: 24 GB
Disponível: 8 GB
À primeira vista, parece impossível receber um erro relacionado à falta de memória.
Afinal:
ainda existem aproximadamente 8 GB disponíveis.
Mas então observamos:
Confirmado: 47,5/48,0 GB
Agora o diagnóstico muda completamente.
O sistema está muito próximo do Commit Limit.
A quantidade de RAM física disponível e a quantidade restante de Commit não são a mesma coisa.
Memória física disponível não garante Commit disponível
Essa frase resume boa parte do problema.
Podemos ter:
RAM disponível > 0
ao mesmo tempo em que:
Commit disponível ≈ 0
Essas métricas representam recursos diferentes.
Exemplo simplificado
Imagine:
Commit Charge: 47 GB
Commit Limit: 48 GB
Restam aproximadamente:
1 GB
de margem de Commit.
Agora um aplicativo solicita mais:
2 GB
de memória que exige Commit.
O Windows não possui margem suficiente para assumir aquele compromisso.
A alocação pode falhar.
“Mas havia 8 GB de RAM!”
Isso não muda o fato de que o sistema estava próximo do limite de Commit.
Esse é justamente o erro de interpretação que queremos evitar.
O que significa “memória virtual”?
Existe outra confusão importante.
Muitos usuários aprendem:
memória virtual = pagefile.sys
Essa definição é incompleta.
Cada processo trabalha com um espaço de endereçamento virtual
Um processo não trabalha simplesmente dizendo:
“grave meus dados no pente de RAM localizado naquele endereço físico.”
O Windows fornece a cada processo um espaço de endereçamento virtual.
O Memory Manager e o hardware participam do mapeamento entre endereços virtuais e páginas físicas.
Portanto, endereço virtual não é endereço físico
Conceitualmente:
processo
↓
endereço virtual
↓
mapeamento
↓
página física / backing apropriado
Essa abstração é fundamental para sistemas operacionais modernos.
Dois processos podem utilizar o mesmo endereço virtual
Isso não significa que estejam necessariamente acessando a mesma posição física da RAM.
Cada processo possui seu próprio contexto de endereçamento.
Isso aumenta isolamento e flexibilidade
O sistema consegue controlar:
- permissões;
- compartilhamento;
- proteção;
- mapeamento;
- residência física;
- paginação.
Então onde entra o pagefile?
O pagefile.sys é um dos mecanismos que fornecem backing para determinadas páginas comprometidas e participa do gerenciamento de memória.
Ele não é o próprio conceito de memória virtual.
Memória virtual existe mesmo sem pagefile
Sim.
Desabilitar pagefile.sys não faz o Windows deixar de utilizar endereçamento virtual.
Essa é uma distinção fundamental.
64 bits mudaram bastante o espaço de endereçamento
Processos de 64 bits podem trabalhar com espaços virtuais muito maiores do que os antigos limites típicos de processos de 32 bits.
Mas espaço de endereçamento virtual grande não significa RAM física infinita.
Espaço de endereço também não é Commit
Outra distinção.
Um processo pode possuir regiões de endereço virtual reservadas sem que toda aquela região tenha Commit correspondente.
Reserve versus Commit
A API de memória virtual do Windows permite conceitos como:
Reserve
e:
Commit.
Eles não significam a mesma coisa.
O que significa reservar uma região?
De maneira simplificada, reservar significa separar uma faixa do espaço de endereçamento virtual para uso futuro.
Podemos pensar:
Reserve
↓
esta faixa de endereços virtuais fica separada
Mas isso não significa necessariamente que todo aquele espaço já recebeu backing comprometido.
E Commit?
Quando páginas dentro daquela região são committed, o sistema assume o compromisso necessário para suportá-las.
Exemplo conceitual
Um aplicativo reserva:
100 GB de espaço de endereço virtual
mas inicialmente compromete:
2 GB
Isso não significa que ele acabou de consumir 100 GB de RAM ou 100 GB de Commit.
Essa diferença é extremamente importante
Se você olhar apenas o tamanho do espaço virtual reservado, pode acreditar que o aplicativo está usando uma quantidade absurda de memória.
Mas:
Virtual Address Space
Reserve
Commit
Working Set
são conceitos diferentes.
Podemos montar uma hierarquia didática
Imagine:
Espaço de endereço virtual
Dentro dele:
regiões reservadas
Dentro de determinadas regiões:
páginas committed
E parte dessas páginas pode estar:
residente no Working Set
Essa representação não descreve todos os detalhes internos, mas ajuda bastante.
Reserve não consome Commit da mesma maneira que Commit
Essa é a razão pela qual um aplicativo pode reservar um espaço enorme sem imediatamente aproximar o sistema do Commit Limit.
Mas quando ele começa a fazer Commit?
A situação muda.
Se o aplicativo compromete progressivamente:
2 GB
5 GB
10 GB
20 GB
40 GB
o Commit Charge do sistema pode crescer junto.
Agora podemos entender melhor um memory leak
Imagine um programa que continuamente solicita memória comprometida e não a libera adequadamente.
O comportamento pode ser:
08:00
Private Bytes: 800 MB
10:00
2,5 GB
12:00
7 GB
14:00
15 GB
16:00
28 GB
Ao mesmo tempo:
Commit Charge
também sobe.
A RAM física não precisa crescer exatamente na mesma proporção
Esse detalhe explica muitos casos.
O Working Set pode permanecer relativamente menor enquanto o Commit aumenta.
Por isso o usuário procura o culpado e não encontra
Ele ordena:
Gerenciador de Tarefas → Processos → Memória
e vê:
programa.exe → 3 GB
Mas em outra métrica o processo pode possuir quantidade muito maior de memória privada comprometida.
Adicione Commit Size
Na guia:
Detalhes
adicione a coluna correspondente ao tamanho de Commit.
Agora talvez apareça:
programa.exe
Commit Size: 19 GB
A investigação muda.
Process Explorer aprofunda ainda mais
Observe:
Private Bytes
e:
Working Set
Se:
Private Bytes cresce continuamente
mas:
Working Set oscila
podemos estar diante de um processo aumentando suas alocações privadas comprometidas sem manter tudo residente ao mesmo tempo.
Private Bytes é excelente para detectar leaks de processos
Não é a única métrica, mas costuma ser extremamente útil.
Exemplo de comportamento normal
Editor:
2 GB → 6 GB → 3 GB → 7 GB → 4 GB
A memória aumenta durante operações pesadas e depois parte é liberada.
Exemplo suspeito
2 GB → 4 GB → 7 GB → 11 GB → 18 GB → 27 GB
sem redução significativa, mesmo depois de concluir as tarefas.
Isso merece investigação.
Fechar o programa é um teste
Antes:
Commit global: 43/48 GB
Fecha corretamente o aplicativo.
Depois:
Commit global: 17/48 GB
Temos uma pista muito forte.
Abra novamente e reproduza
Se o Commit cresce novamente com a mesma atividade, a evidência melhora.
Navegadores podem usar muito Commit?
Podem utilizar quantidades significativas dependendo de:
- número de abas;
- processos;
- extensões;
- conteúdo;
- aplicações web.
Mas “Chrome usa muita RAM” não é diagnóstico suficiente.
Navegadores modernos usam arquitetura multiprocesso
Você pode encontrar vários processos relacionados ao mesmo navegador.
Por isso, analisar apenas um processo pode não representar todo o conjunto.
Extensões também podem participar
Se o crescimento aparece apenas com determinada extensão, faça teste controlado.
Mas não chame consumo alto de leak automaticamente
Se abrir 100 abas aumenta a memória, isso pode ser esperado.
Leak significa comportamento de retenção inadequada, não simplesmente uso alto.
Jogos podem elevar Commit
Jogos modernos podem utilizar grandes quantidades de:
- RAM;
- memória virtual;
- recursos da GPU;
- caches.
Além disso, launchers, overlays e ferramentas auxiliares também participam da carga.
“Out of Memory” em jogo nem sempre significa pouca RAM
Investigue:
- Commit;
- pagefile;
- memória do processo;
- VRAM;
- limite interno do aplicativo;
- mods;
- bugs;
- configurações.
VRAM e Commit são a mesma coisa?
Não.
Memória da GPU é outro recurso.
Um jogo pode apresentar erro de memória por VRAM?
Pode.
Por isso, a mensagem exibida precisa ser interpretada no contexto.
Máquinas virtuais são um excelente exemplo
Hypervisors podem criar cargas muito grandes de memória.
Imagine:
Host: 32 GB RAM
VM 1:
8 GB
VM 2:
8 GB
VM 3:
12 GB
Além disso, o host precisa de memória para o Windows e outros programas.
O Commit pode subir significativamente.
“Tenho 32 GB, então posso entregar 32 GB às VMs?”
Essa abordagem ignora o próprio host.
É preciso planejar margem.
Edição de vídeo também
Aplicativos de edição podem usar grandes quantidades de memória para:
- projetos;
- cache;
- efeitos;
- frames;
- plugins.
Um Commit elevado pode ser legítimo.
Renderização 3D
A mesma lógica.
Carga alta não é leak por definição.
Compilação e desenvolvimento
Ambientes de desenvolvimento podem executar:
- IDE;
- navegador;
- containers;
- máquinas virtuais;
- compiladores;
- bancos de dados locais.
A soma da carga pode elevar bastante o Commit.
Servidores e bancos de dados
Alguns softwares são projetados para utilizar agressivamente recursos disponíveis.
Por isso, olhar um número grande sem conhecer a carga pode levar a conclusões erradas.
O que realmente importa?
Pergunte:
o consumo é esperado, limitado e estável?
ou:
cresce indefinidamente sem liberação adequada?
Commit alto pode ser normal
Exemplo:
Commit: 50/90 GB
em uma estação com carga pesada.
Talvez seja perfeitamente saudável.
Commit perto do limite merece atenção
Exemplo:
Commit: 88/90 GB
Agora existe pouca margem.
Mesmo que a carga seja legítima, o sistema pode estar perto de falhar em novas solicitações.
Quanto de margem devo deixar?
Não existe uma porcentagem universal.
A carga pode mudar rapidamente.
O importante é compreender o pico real do workload e dimensionar recursos adequadamente.
O Windows pode aumentar o pagefile automaticamente?
Quando o pagefile é gerenciado pelo sistema, o Windows possui maior flexibilidade para ajustar seu tamanho conforme as condições e políticas aplicáveis.
Mas isso depende de fatores como espaço em disco e configuração.
Não dependa de crescimento instantâneo para salvar qualquer situação
Se uma aplicação dispara uma enorme demanda rapidamente, o sistema ainda pode enfrentar pressão e falhas.
Pouco espaço no SSD pode virar problema
Se o pagefile precisa de flexibilidade para crescer, mas a unidade do sistema está praticamente cheia, essa capacidade pode ficar limitada.
Exemplo
SSD:
500 GB
Livre:
1,2 GB
Pagefile gerenciado pelo sistema.
Commit crescendo rapidamente.
Esse ambiente merece atenção.
Não conclua que “SSD cheio causa falta de RAM”
Novamente, precisamos usar linguagem correta.
Pouco espaço pode limitar a capacidade de crescimento do pagefile e, consequentemente, afetar a margem de Commit em determinadas configurações.
O que acontece se definirmos pagefile muito pequeno?
Você pode reduzir artificialmente o Commit Limit.
Exemplo
Computador:
32 GB RAM
O usuário configura:
pagefile máximo: 1 GB
Agora uma carga que antes tinha grande margem de Commit pode chegar ao limite mais cedo.
Por que alguém faz isso?
Normalmente por dicas antigas de “otimização”.
Outra dica antiga: pagefile fixo evita fragmentação
Esse tipo de recomendação vem de contextos históricos diferentes e não deve ser aplicado automaticamente a Windows 11 e SSDs modernos.
“Desative o pagefile para o Windows usar toda a RAM”
Também é uma recomendação problemática.
O Windows já tenta utilizar a RAM de forma eficiente.
Remover pagefile não obriga magicamente o sistema a ficar mais rápido.
O que você realmente faz?
Entre outras consequências, reduz a margem de Commit.
E pode afetar dumps
Dependendo da configuração, também pode interferir na capacidade de produzir determinados tipos de crash dump.
Pagefile em SSD é ruim?
Não como regra geral.
SSDs são o armazenamento padrão em computadores modernos, e o Windows foi projetado considerando esse tipo de ambiente.
O pagefile deve ficar no SSD mais rápido?
Para usuários comuns, normalmente é melhor deixar o Windows gerenciar a configuração apropriada em vez de aplicar receitas universais.
Ambientes especializados podem ter políticas diferentes.
Posso ter mais de um pagefile?
O Windows oferece suporte a configurações com arquivos de paginação em volumes apropriados.
Mas isso não significa que todo usuário precise criar vários.
Pagefile gerenciado pelo sistema continua sendo a recomendação mais simples
Especialmente quando não existe uma necessidade técnica documentada para configuração manual.
Como verificar a configuração?
Abra:
Propriedades do Sistema
Depois:
Avançado → Desempenho → Configurações → Avançado → Memória virtual
Verifique se:
Gerenciar automaticamente o tamanho do arquivo de paginação para todas as unidades
está habilitado.
Não altere durante o diagnóstico inicial
Primeiro registre:
- configuração atual;
- Commit Limit;
- Commit Charge;
- espaço livre;
- comportamento do processo.
Só depois faça mudanças.
Performance Monitor: agora fica ainda mais importante
Execute:
perfmon
Para analisar Commit global, contadores úteis incluem métricas relacionadas a:
Memory\Committed Bytes
Memory\Commit Limit
e percentual de bytes comprometidos em uso, quando disponível na versão/configuração.
Para processos
Observe contadores relacionados a:
Process\Private Bytes
e:
Process\Working Set
O gráfico pode revelar o culpado
Imagine:
Committed Bytes
cresce continuamente.
Process A Private Bytes
estável.
Process B Private Bytes
cresce exatamente no mesmo ritmo.
Agora temos uma correlação excelente.
Exemplo
| Hora | Commit global | Processo B Private Bytes |
|---|---|---|
| 08:00 | 8 GB | 500 MB |
| 10:00 | 11 GB | 3,4 GB |
| 12:00 | 16 GB | 8,2 GB |
| 14:00 | 23 GB | 15,1 GB |
| 16:00 | 31 GB | 23,0 GB |
Isso é muito mais convincente que:
“Acho que o programa está usando muita memória.”
E se Committed Bytes cresce, mas nenhum processo acompanha?
Agora precisamos ampliar a análise.
Considere:
- kernel;
- pools;
- drivers;
- serviços;
- outros tipos de alocação.
É aí que o artigo anterior sobre Paged Pool e Nonpaged Pool volta a ser relevante.
Diagnóstico de memória é uma árvore
Podemos pensar:
Commit crescendo
↓
processo acompanha?
Sim
investigue o processo.
Não
investigue sistema/kernel/drivers e outras categorias.
Outra possibilidade: vários processos pequenos
Talvez não exista um único culpado.
Exemplo:
20 processos aumentam 500 MB cada.
Total:
10 GB
Nenhum parece gigantesco individualmente.
Portanto, contexto continua importante
Não procure obrigatoriamente “um processo monstro”.
O sistema pode avisar antes do limite absoluto?
Aplicativos e componentes podem reagir à pressão de memória de formas diferentes.
Não espere necessariamente que tudo funcione perfeitamente até:
99,999%
e falhe exatamente em:
100%.
Aplicações podem possuir seus próprios limites
Um programa pode falhar antes do Commit Limit global por:
- limite interno;
- fragmentação do espaço virtual;
- arquitetura 32 bits;
- política;
- bug.
Processos de 32 bits merecem atenção especial
Mesmo em Windows 64 bits, um aplicativo de 32 bits possui limitações próprias de espaço de endereçamento virtual.
Isso significa que aumentar RAM sempre resolve um aplicativo 32 bits?
Não.
Se o problema está no limite de espaço de endereçamento daquele processo, instalar mais RAM física não remove automaticamente esse limite.
Então existem vários tipos de “falta de memória”
Exatamente.
Podemos ter:
- pressão de RAM física;
- Commit Limit;
- limite de espaço virtual do processo;
- VRAM;
- limites internos do software;
- recursos do kernel;
- vazamentos.
A mensagem “memória insuficiente” sozinha não identifica qual deles ocorreu
Precisamos medir.
Cenário 1 — RAM física pressionada
RAM: 31/32 GB
Commit: 35/80 GB
Pode existir pressão física forte, mas ainda grande margem de Commit.
Cenário 2 — Commit esgotando
RAM: 24/32 GB
Commit: 79/80 GB
O problema principal está muito mais próximo do limite de Commit.
Cenário 3 — Nonpaged Pool crescendo
RAM: 30/32 GB
Nonpaged Pool: 15 GB
Agora investigue drivers/kernel.
Cenário 4 — processo 32 bits
RAM e Commit globais podem ter margem, mas o processo pode atingir sua própria limitação de endereço.
Cenário 5 — VRAM
O sistema possui RAM e Commit suficientes, mas a aplicação está limitada por memória gráfica.
Não trate todos esses cenários com “compre mais RAM”
Essa é uma das principais conclusões técnicas.
O Gerenciador de Tarefas oferece pistas, não uma resposta completa
Use-o para começar.
Depois avance conforme a evidência.
Procedimento VMIA para “Out of Memory”
1. Registre o erro exato
Não traduza mentalmente.
2. Abra Desempenho → Memória
Anote:
RAM em uso
Disponível
Confirmado X/Y
Paged Pool
Nonpaged Pool
3. Verifique Commit Size dos processos
Procure crescimento.
4. Use Process Explorer
Compare:
Private Bytes
Working Set
5. Use Performance Monitor se o problema demorar
Registre comportamento.
6. Confira pagefile
Veja se foi:
- desativado;
- limitado;
- gerenciado pelo sistema.
7. Verifique espaço livre
Principalmente se o pagefile precisa crescer.
8. Descubra se o aplicativo é 32 ou 64 bits
Isso pode mudar completamente a investigação.
9. Verifique pools
Se processos não explicarem o consumo.
10. Reproduza
Tente descobrir qual atividade faz o Commit crescer.
Não mude cinco coisas ao mesmo tempo
Se você:
- aumenta pagefile;
- instala RAM;
- atualiza driver;
- atualiza Windows;
- remove antivírus;
e o problema desaparece, não sabe o que corrigiu.
Mude uma variável por vez
Esse princípio vale para quase todo diagnóstico técnico.
Diagnóstico completo de Commit, pagefile, memória virtual e erros de “memória insuficiente”
Depois de entender Commit, Commit Charge, Commit Limit, Working Set, Private Bytes e pagefile.sys, fica muito mais fácil interpretar problemas de memória no Windows 11.
A principal lição deste artigo é:
memória insuficiente não significa obrigatoriamente RAM física em 100%.
O Windows trabalha com diferentes limites e diferentes tipos de memória.
Por isso, antes de trocar RAM, alterar pagefile ou culpar um aplicativo, precisamos descobrir qual recurso está realmente próximo do limite.
Resumo das principais métricas
| Métrica | O que representa |
|---|---|
| RAM física | Memória DRAM instalada no computador |
| RAM em uso | Parte da memória física atualmente utilizada |
| Disponível | Memória que pode ser disponibilizada para novas demandas |
| Working Set | Páginas de um processo atualmente residentes na RAM |
| Private Working Set | Parte privada do Working Set de um processo |
| Private Bytes | Memória privada comprometida por um processo |
| Commit | Memória comprometida que precisa de backing garantido |
| Commit Charge | Total de Commit atual do sistema |
| Commit Limit | Limite aproximado de Commit disponível |
| pagefile.sys | Arquivo de paginação que participa do backing e do Commit Limit |
| Memória virtual | Sistema de endereçamento virtual usado pelos processos; não é sinônimo de pagefile |
O que significa “Confirmado 22/47 GB”?
Podemos interpretar:
22 GB
como o Commit atual aproximado.
E:
47 GB
como o Commit Limit atual.
Portanto:
22/47 GB
não significa:
22 GB dentro do pagefile.
Também não significa:
22 GB fisicamente dentro da RAM.
E se aparecer 46/47 GB?
Agora existe pouca margem de Commit.
Isso merece atenção.
Se novos programas ou componentes solicitarem memória comprometida, alocações podem começar a falhar.
O primeiro diagnóstico deve ser simples
Quando o computador apresentar erro de memória, abra:
Gerenciador de Tarefas → Desempenho → Memória
Anote:
- memória em uso;
- disponível;
- Confirmado;
- Paged Pool;
- Nonpaged Pool.
Depois veja:
Detalhes
e habilite a coluna relacionada ao:
Commit Size / Tamanho da confirmação.
Cenário 1 — RAM alta e Commit alto
Exemplo:
RAM: 30/32 GB
Commit: 47/48 GB
Temos forte pressão dos dois lados.
Agora precisamos descobrir:
quem está consumindo essa memória?
Cenário 2 — RAM alta, Commit ainda confortável
Exemplo:
RAM: 30/32 GB
Commit: 28/64 GB
Aqui pode existir forte pressão de memória física, mas o sistema ainda possui bastante margem de Commit.
O problema de desempenho pode estar relacionado à quantidade de páginas que precisam permanecer ativas na RAM.
Cenário 3 — RAM não está cheia, mas Commit está quase no limite
Exemplo:
RAM: 22/32 GB
Commit: 47,5/48 GB
Esse é um dos cenários que mais confundem usuários.
Ainda existe RAM física disponível, mas quase não existe margem de Commit.
Cenário 4 — RAM alta e Nonpaged Pool enorme
Exemplo:
RAM: 30/32 GB
Commit: 35/64 GB
Nonpaged Pool: 12 GB
Nesse caso, o artigo anterior sobre Paged Pool e Nonpaged Pool se torna mais importante.
Precisamos investigar drivers e Pool Tags.
Cenário 5 — um processo apresenta Private Bytes crescendo continuamente
Exemplo:
programa.exe
08:00
Private Bytes: 700 MB
10:00
3 GB
12:00
8 GB
14:00
17 GB
16:00
29 GB
Ao mesmo tempo, o Commit do sistema cresce de maneira semelhante.
Esse processo se torna um forte candidato a vazamento.
Cenário 6 — vários processos contribuem
Nem sempre existe um único programa gigantesco.
Imagine:
20 processos aumentam:
500 MB
cada.
Isso representa aproximadamente:
10 GB
de crescimento acumulado.
Cenário 7 — programa 32 bits
O sistema possui:
64 GB de RAM
e Commit confortável.
Mesmo assim, um aplicativo de 32 bits pode encontrar limitações próprias relacionadas ao espaço de endereçamento.
Nesse caso, instalar mais RAM pode não corrigir o problema específico do processo.
Cenário 8 — jogo acusa “Out of Memory”
Não conclua imediatamente que faltou RAM.
Verifique:
- RAM;
- Commit;
- VRAM;
- arquitetura do aplicativo;
- mods;
- bugs;
- pagefile;
- limite interno do jogo.
Cenário 9 — máquina virtual
Máquinas virtuais podem elevar rapidamente o compromisso de memória.
Exemplo:
Host com:
32 GB
VM1:
10 GB
VM2:
10 GB
VM3:
8 GB
Ainda existe o próprio Windows host e seus aplicativos.
O planejamento precisa considerar a carga completa.
Cenário 10 — pagefile foi desativado
Imagine:
32 GB RAM
Antes:
Commit Limit: 50 GB
Depois de desativar pagefile:
Commit Limit significativamente menor
Uma carga que antes funcionava pode chegar ao limite de Commit mais rapidamente.
Isso prova por que pagefile não é simplesmente “RAM lenta”
Se fosse apenas uma extensão usada quando a RAM acabasse, desativá-lo não afetaria o Commit Limit antes da RAM chegar a 100%.
Mas afeta.
Então devo deixar o pagefile ativado?
Para a maioria dos usuários, sim.
Em computadores comuns com Windows 11, deixar o sistema gerenciar automaticamente o pagefile costuma ser a escolha mais segura e simples.
“Tenho 64 GB de RAM. Posso desligar o pagefile?”
Ter muita RAM reduz a probabilidade de determinadas cargas precisarem de paginação intensa.
Mas isso não elimina o papel do pagefile no Commit Limit e em determinados mecanismos de dump.
Portanto, não existe uma regra universal dizendo:
RAM alta = desative pagefile
Existe algum ganho garantido ao desativar?
Não.
E você pode reduzir a margem de Commit.
“Mas o SSD é lento comparado à RAM”
Correto.
Porém essa constatação não significa que remover o pagefile torne todo o sistema mais rápido.
RAM e SSD possuem funções diferentes
O Windows prefere manter páginas úteis na RAM quando possível.
O pagefile participa do gerenciamento e backing de memória, mas isso não transforma o SSD em DRAM.
Outro mito: pagefile desgasta muito o SSD
SSDs possuem limite de gravação, mas o impacto real depende da carga.
Desativar paginação indiscriminadamente apenas por medo de desgaste não é uma recomendação técnica universal.
Outro mito: pagefile precisa ter 1,5 vez a RAM
Essa regra antiga aparece em muitos sites.
Não existe razão para tratá-la como fórmula universal para Windows 11.
Outro mito: pagefile fixo sempre é melhor
Também não.
O tamanho apropriado depende de:
- quantidade de RAM;
- workload;
- pico de Commit;
- crash dumps;
- espaço em disco;
- políticas administrativas.
Outro mito: pagefile sempre precisa ficar enorme
Também não.
O tamanho deve acompanhar as necessidades reais do sistema.
O modo “Gerenciado pelo sistema” resolve tudo?
Não necessariamente.
Um memory leak ainda é um leak.
Se um processo continua crescendo:
10 GB
20 GB
40 GB
80 GB
um pagefile maior pode apenas retardar o momento em que o limite será atingido.
Mais pagefile não corrige memory leak
Essa frase merece destaque.
Aumentar Commit Limit não corrige a causa do consumo crescente.
Assim como adicionar RAM
Mais RAM pode permitir que o problema demore mais para se tornar crítico.
Mas o vazamento continua.
Como diferenciar capacidade insuficiente de leak?
Observe o padrão.
Carga legítima
Commit sobe
durante tarefa pesada.
Depois:
Commit cai
quando a carga termina.
Possível leak
Commit sobe
continua subindo
e não retorna de forma compatível com a carga concluída.
Exemplo de edição de vídeo
Abre projeto:
Commit: 12 GB
Começa renderização:
24 GB
Finaliza:
15 GB
Pode ser perfeitamente normal.
Compare com vazamento
Abre programa:
12 GB
Depois de uma hora:
20 GB
Depois:
30 GB
Finaliza todas as tarefas:
31 GB
Continua aberto:
38 GB
Agora existe um padrão muito mais suspeito.
O tempo é uma das melhores ferramentas de diagnóstico
Por isso, registre:
hora
Commit
Private Bytes
Working Set
atividade
Monte uma tabela
| Horário | Commit global | Private Bytes | Atividade |
|---|---|---|---|
| 08:00 | 8 GB | 600 MB | programa aberto |
| 10:00 | 12 GB | 4 GB | uso normal |
| 12:00 | 18 GB | 10 GB | uso normal |
| 14:00 | 26 GB | 18 GB | uso normal |
| 16:00 | 35 GB | 27 GB | programa parado |
Essa tabela pode revelar um vazamento que uma captura isolada não mostraria.
Performance Monitor é excelente para isso
Execute:
perfmon
Monitore contadores relacionados a:
Memory\Committed Bytes
Memory\Commit Limit
e:
Process\Private Bytes
O que procurar no gráfico?
Uma linha continuamente crescente.
Principalmente se o processo suspeito e o Commit global crescem juntos.
Process Explorer também ajuda
O Process Explorer permite acompanhar:
- Private Bytes;
- Working Set;
- processos filhos;
- serviços;
- detalhes adicionais.
E se o processo fecha, mas o Commit continua alto?
Verifique se:
- existem processos filhos;
- serviços permanecem;
- outro componente mantém a alocação;
- driver está envolvido.
Um software pode instalar serviço separado
Por exemplo:
aplicativo.exe
fecha.
Mas:
servico.exe
continua rodando.
Se o serviço possui o consumo, fechar somente a janela não resolve.
Programas modernos usam vários processos
Isso vale para:
- navegadores;
- launchers;
- suítes profissionais;
- aplicativos Electron;
- ferramentas de comunicação.
Por isso, observe o conjunto.
O que fazer quando Commit está perto do limite?
Primeiro identifique a causa.
Depois, conforme o caso:
- feche corretamente aplicações que não são necessárias;
- corrija software com leak;
- atualize aplicativo;
- atualize driver;
- restaure pagefile adequado;
- aumente RAM se a carga realmente exige mais memória física;
- ajuste workload.
Não comece aumentando o pagefile sem entender o motivo
Se o pagefile foi limitado manualmente, restaurar gerenciamento automático pode fazer sentido.
Mas se existe um aplicativo vazando 40 GB, o ajuste não resolve a origem.
Não desative o pagefile durante investigação
Isso altera o Commit Limit e muda o comportamento que você está tentando analisar.
Primeiro registre a configuração
Anote:
- pagefile ativo ou não;
- automático ou manual;
- tamanho atual;
- espaço livre no SSD;
- Commit Limit.
Pouco espaço em disco merece atenção
Se o pagefile está gerenciado pelo sistema e o disco possui pouquíssimo espaço livre, a capacidade de ajuste pode ficar limitada.
Mas não misture espaço em disco com RAM
São recursos diferentes.
O elo entre eles neste contexto é o pagefile.
Por que o Windows pode manter pagefile mesmo com muita RAM?
Porque pagefile participa do desenho global de gerenciamento de memória.
O sistema não espera necessariamente a RAM ficar absolutamente cheia para considerar paginação.
Páginas pouco utilizadas podem sair da RAM
Isso abre espaço para páginas mais úteis e cache.
Isso é ruim?
Não automaticamente.
Um pouco de paginação não significa problema.
Quando pagefile começa a afetar desempenho?
Quando a carga exige constantemente trazer e remover páginas devido à pressão de memória física, o armazenamento pode virar um gargalo.
Esse comportamento é diferente de simplesmente ter pagefile ativo.
“Pagefile Usage” e Commit também não são exatamente iguais
Outro cuidado importante.
O Commit representa o compromisso global.
Não devemos tratar todo Commit como conteúdo efetivamente escrito no pagefile naquele instante.
O que acontece quando uma página comprometida ainda não foi tocada?
Detalhes de alocação podem variar conforme a API e o comportamento do aplicativo.
Por isso, analisar apenas números de reserva/endereço não é suficiente.
Reserve continua sendo diferente de Commit
Um programa pode reservar uma região virtual enorme.
Por exemplo:
200 GB
Isso não significa:
200 GB de RAM utilizados
nem:
200 GB de Commit imediatamente consumidos.
Esse conceito explica muitos números “absurdos”
Ferramentas avançadas podem mostrar espaços virtuais enormes para processos.
Isso não significa consumo físico equivalente.
Endereço virtual, Commit e RAM precisam ser separados
Essa talvez seja a principal lição técnica deste artigo.
Fluxo final de diagnóstico VMIA
Quando surgir:
“Memória insuficiente”
siga esta ordem.
1. Leia a mensagem exata
Descubra qual aplicativo apresentou o erro.
2. Verifique RAM física
Abra:
Gerenciador de Tarefas → Desempenho → Memória
3. Verifique “Confirmado X/Y”
Descubra o Commit atual e o limite.
4. Verifique Paged e Nonpaged Pool
Isso ajuda a descobrir se kernel/drivers participam.
5. Abra Detalhes
Habilite Commit Size.
6. Procure processos com Commit alto
Compare também crescimento.
7. Use Process Explorer
Observe Private Bytes e Working Set.
8. Use Performance Monitor
Para problemas que demoram horas ou dias.
9. Verifique pagefile
Veja se foi desativado ou limitado.
10. Verifique espaço livre
Principalmente com pagefile automático.
11. Descubra se o processo é 32 ou 64 bits
Limitações podem ser diferentes.
12. Compare antes e depois de fechar o aplicativo
Observe se o Commit cai.
13. Reproduza
Abra novamente e execute a mesma atividade.
14. Mude uma variável por vez
Atualização, configuração, driver ou versão.
15. Documente
Registre valores e horários.
O que NÃO fazer primeiro
Evite começar por:
- formatar o Windows;
- comprar RAM;
- desativar pagefile;
- definir pagefile gigantesco;
- usar limpadores de RAM;
- instalar otimizadores;
- finalizar processos desconhecidos;
- apagar
pagefile.sysmanualmente; - alterar Registro aleatoriamente.
Posso apagar pagefile.sys?
Não apague manualmente o arquivo.
Se for necessário alterar a configuração, utilize as opções de memória virtual do Windows.
O pagefile.sys fica oculto?
Sim, é um arquivo protegido do sistema.
Ele pode ocupar vários gigabytes?
Sim.
O tamanho depende da configuração e das necessidades do sistema.
É normal mudar de tamanho?
Quando gerenciado pelo sistema, o tamanho pode ser ajustado conforme as condições aplicáveis.
Preciso mover o pagefile para outro SSD?
Na maioria dos computadores comuns, não há necessidade de alterar a configuração padrão sem um objetivo específico.
Dois SSDs melhoram o Commit?
Não confunda capacidade de Commit com desempenho.
Configurações com múltiplos pagefiles podem existir, mas não representam automaticamente um ganho perceptível para todo usuário.
Pagefile em HDD funciona?
Funciona, mas HDD possui latência muito maior que SSD.
Em situações com paginação intensa, o impacto de desempenho pode ser significativo.
SSD NVMe resolve pouca RAM?
Não.
Mesmo um NVMe rápido continua muito mais lento que DRAM para acesso à memória.
Então quando instalar mais RAM realmente ajuda?
Quando a carga normal precisa manter mais dados ativos do que a RAM física consegue sustentar confortavelmente.
Exemplo
Máquina com:
8 GB
utiliza constantemente:
- navegador pesado;
- Teams;
- Photoshop;
- máquinas virtuais.
O sistema pode apresentar intensa pressão de memória.
Aumentar para 16 GB ou 32 GB pode melhorar bastante a experiência.
Mas se existe leak?
Primeiro corrija o leak.
Um computador com 128 GB pode ficar sem Commit?
Pode, dependendo da configuração de pagefile e da carga.
Muita RAM não torna o Commit infinito.
E um computador com 8 GB pode ter Commit maior que 8 GB?
Sim, com pagefile adequado.
FAQ — Commit, RAM, memória virtual e pagefile no Windows 11
1. O que é Commit no Windows?
É o compromisso do sistema de fornecer backing para determinada memória comprometida.
2. Commit é RAM?
Não.
3. Commit é pagefile?
Não.
4. O que é Commit Charge?
É a quantidade total de Commit atualmente em uso.
5. O que é Commit Limit?
É o limite até o qual o sistema consegue sustentar memória comprometida.
6. O que significa Confirmado 10/30 GB?
Aproximadamente 10 GB de Commit atual contra um limite de 30 GB.
7. Os 10 GB estão todos no pagefile?
Não.
8. Commit pode ser maior que a RAM?
Sim.
9. Isso é erro?
Não.
10. Working Set é Commit?
Não.
11. O que é Working Set?
É o conjunto de páginas de um processo atualmente residente na RAM.
12. O que é Private Bytes?
É uma métrica relacionada à memória privada comprometida por um processo.
13. Private Bytes ajuda a encontrar memory leak?
Sim, principalmente quando cresce continuamente.
14. O que é Commit Size?
É uma métrica relacionada à memória comprometida associada ao processo.
15. Onde vejo Commit Size?
Na guia Detalhes do Gerenciador de Tarefas, adicionando a coluna correspondente.
16. O que é memória virtual?
É o sistema de endereçamento virtual utilizado pelos processos.
17. Memória virtual é pagefile?
Não.
18. Windows usa memória virtual sem pagefile?
Sim.
19. O que é Reserve?
É a reserva de uma faixa no espaço de endereçamento virtual.
20. Reserve usa toda aquela RAM?
Não.
21. Reserve usa todo aquele Commit?
Não necessariamente.
22. O que é Commit em uma região reservada?
É quando páginas daquela região passam a exigir compromisso de backing.
23. Por que recebi erro de memória com RAM disponível?
Uma possibilidade é Commit próximo do limite.
24. Isso sempre significa Commit?
Não. Existem outras causas.
25. Um aplicativo 32 bits pode ficar sem memória mesmo com 64 GB de RAM?
Sim, devido às limitações do processo e seu espaço de endereçamento.
26. Desativar pagefile aumenta desempenho?
Não existe ganho universal garantido.
27. Desativar pagefile reduz Commit Limit?
Sim, de maneira relevante.
28. Tenho 32 GB. Preciso de pagefile?
Para a maioria dos usuários, é recomendável manter o Windows gerenciando o pagefile.
29. E com 64 GB?
A mesma lógica geral continua válida.
30. E com 128 GB?
Ter muita RAM não torna o pagefile conceitualmente inútil.
31. Pagefile estraga SSD?
Não deve ser analisado por esse simplismo.
32. O SSD possui desgaste?
Sim, mas é necessário considerar carga e endurance reais.
33. Aumentar pagefile resolve memory leak?
Não.
34. Adicionar RAM resolve memory leak?
Não corrige a causa.
35. Pode adiar o problema?
Sim.
36. Pagefile é RAM lenta?
Essa é uma simplificação inadequada para uma explicação técnica.
37. Pagefile pode ser maior que a RAM?
Pode.
38. Deve ser 1,5 vez a RAM?
Não existe essa regra universal.
39. Devo usar tamanho fixo?
Não existe necessidade universal.
40. Gerenciado pelo sistema é adequado?
Para a maioria dos usuários, sim.
41. Pouco espaço no SSD pode afetar pagefile?
Pode limitar sua capacidade de crescimento em algumas configurações.
42. RAM física cheia significa Commit cheio?
Não.
43. Commit cheio significa RAM física cheia?
Também não.
44. O Process Explorer ajuda?
Sim.
45. O Performance Monitor ajuda?
Muito, especialmente em leaks lentos.
46. Qual contador acompanhar?
Committed Bytes e Commit Limit são métricas importantes do sistema.
47. Para processos?
Private Bytes é muito útil.
48. O que significa Commit crescendo sem parar?
Pode indicar carga crescente ou vazamento; o contexto precisa ser analisado.
49. Se fechar o programa e Commit cair muito, ele era o culpado?
É uma forte pista, mas vale reproduzir o teste.
50. Qual é a principal regra deste artigo?
Não confunda RAM física, Working Set, Commit e pagefile.
Conclusão
O gerenciamento de memória do Windows 11 é muito mais sofisticado do que a ideia de:
“quando a RAM acaba, o Windows usa o SSD.”
Um processo trabalha com espaço de endereçamento virtual. Dentro desse espaço podem existir regiões reservadas e páginas comprometidas. Parte dessas páginas permanece residente na RAM através do Working Set, enquanto o Windows administra backing, paginação, cache e outros mecanismos.
O indicador:
Confirmado X/Y
é uma das melhores formas de observar a relação entre o Commit atual e o Commit Limit.
Quando o primeiro número começa a se aproximar do segundo, novas alocações podem falhar mesmo que o gráfico de RAM física ainda não mostre exatamente 100%.
Por isso, diante de um erro de memória insuficiente, não analise apenas:
“quanto de RAM ainda sobrou?”
Analise também:
- Commit Charge;
- Commit Limit;
- Private Bytes;
- Commit Size;
- Working Set;
- pagefile;
- Paged Pool;
- Nonpaged Pool;
- comportamento ao longo do tempo.
Isso permite separar:
falta real de RAM física
de:
Commit esgotando
de:
memory leak
de:
problema de driver
de:
limitação de processo
de:
VRAM ou limite interno do aplicativo.
O diagnóstico correto não tenta simplesmente “liberar memória”.
Ele identifica qual recurso está chegando ao limite e por quê.
Precisa diagnosticar erros de memória no Windows 11?
A VMIA – Manutenção e Configuração realiza diagnóstico de computadores e notebooks Windows, incluindo problemas de memória RAM, pagefile, desempenho, processos, drivers, travamentos, lentidão e erros de aplicativos.
O atendimento pode ser realizado por acesso remoto ou visita técnica agendada, conforme o problema.
Site: https://vmia.site
Blog: https://vmia.com.br
WhatsApp: https://whats.vmia.com.br
Telefone/WhatsApp: (11) 99779-7772
E-mail: suporte@vmia.com.br
Uma análise correta pode evitar troca desnecessária de memória RAM, formatação do Windows ou alterações perigosas no arquivo de paginação.
Faça um comentário