# VmmemWSL com memória alta: encontre o trabalho antes de recuperar a RAM

`VmmemWSL` no Gerenciador de Tarefas representa os recursos usados pelo ambiente de máquina virtual do WSL. Sua memória pode incluir cargas de trabalho Linux ativas e cache. Se o Docker, um servidor de modelo de IA ou ferramentas de desenvolvimento rodam ali, encerrar um editor do Windows não necessariamente interrompe esse trabalho.

Primeiro, determine se a memória pertence a uma tarefa em execução ou permanece em cache após o término da tarefa. Excluir um disco virtual do WSL não é uma correção de memória e pode destruir o ambiente Linux e seus dados.

## Encontre o trabalho dentro do WSL

No PowerShell, inspecione o ambiente instalado:

```
wsl --version
wsl --list --verbose
wsl --list --running
```

Dentro da distribuição Linux relevante, use estas visualizações somente leitura:

```
free -h
ps -eo pid,comm,rss --sort=-rss
```

As leituras do Linux não têm exatamente o mesmo escopo que o total da VM no Gerenciador de Tarefas. Use-as para localizar processos e distinguir memória disponível de cache de arquivos, não para forçar todos os números a coincidir. Para o trabalho de propriedade do Docker, inspecione os contêineres em execução do Docker Desktop e pare a tarefa pretendida por meio de seu controle normal.

Um servidor de IA pode manter um modelo carregado após responder. Pare essa carga de trabalho deliberadamente se ela não for mais necessária. Não encerre um processo arbitrário simplesmente porque seu nome não é familiar.

## Leia uma amostra de memória do Linux sem chamar todo cache de vazamento

Na saída do `free -h`, preste atenção em `available`, bem como em `used` e `buff/cache`. O Linux usa memória que estaria ociosa para dados de arquivos, e parte dessa memória pode ser recuperada quando os aplicativos precisam dela. Portanto, um valor pequeno de `free` sozinho não basta para estabelecer que o Linux está sem memória.

A listagem de processos informa o RSS em KiB, enquanto `free -h` usa unidades legíveis por humanos. Páginas compartilhadas e a sobrecarga da VM também fazem com que a soma das linhas de processo não seja necessariamente igual ao número VmmemWSL do Gerenciador de Tarefas. Use as maiores linhas para identificar o responsável e depois inspecione a carga de trabalho nomeada, em vez de forçar os totais a coincidir.

Se o Docker estiver envolvido, estes comandos somente leitura identificam os contêineres em execução e coletam uma amostra de recursos, seguindo a [referência de estatísticas do Docker](https://docs.docker.com/reference/cli/docker/container/stats/):

```powershell
docker ps
docker stats --no-stream
```

Execute-os no ambiente conectado ao backend do Docker que está sendo investigado. Um contexto do Docker diferente pode descrever uma máquina remota, então confirme o alvo antes de agir. O número de memória exibido para um contêiner e o total da VM WSL inteira têm escopos diferentes.

Compare três estados: antes de o trabalho de IA começar, enquanto ele está em execução e depois que o aplicativo descarregou normalmente seu modelo ou encerrou o trabalho. Se o processo grande permanecer ativo, a recuperação de cache não substitui a decisão sobre se esse processo deve continuar em execução. Se o processo diminuir, mas o cache permanecer, o comportamento de recuperação se torna uma questão mais relevante.

## Verifique a configuração atual de recuperação

A [referência de configuração do WSL](https://learn.microsoft.com/en-us/windows/wsl/wsl-config) da Microsoft coloca as configurações globais do WSL 2 em `%USERPROFILE%\.wslconfig`. É diferente de `/etc/wsl.conf` dentro de uma distribuição.

A referência atual lista `autoMemoryReclaim` em `[experimental]`, com `dropCache` como padrão e `gradual` como outro modo suportado. O conselho antigo de ativar um padrão universalmente desativado pode, portanto, estar desatualizado. Verifique a versão instalada do WSL e sua configuração existente antes de adicionar qualquer coisa.

Se você quiser deliberadamente a recuperação gradual de cache em uma versão que suporte a configuração, mescle esta entrada no arquivo existente:

```
[experimental]
autoMemoryReclaim=gradual
```

Não sobrescreva configurações não relacionadas nem crie seções duplicadas. Isso altera como a memória em cache é recuperada; não faz com que um modelo ou banco de dados ativo exija menos memória. Compare a mesma carga de trabalho antes de decidir se mantém a alteração.

## Edite a configuração existente e mantenha uma forma de voltar

Abra `%USERPROFILE%` no Explorador de Arquivos e ative as extensões de nome de arquivo antes de criar ou editar `.wslconfig`. Um arquivo salvo acidentalmente como `.wslconfig.txt` não é a configuração pretendida. Copie uma configuração existente para um backup primeiro e preserve as seções não relacionadas à memória.

Em uma seção `[experimental]` existente, altere apenas a entrada de recuperação que está sendo testada. Um novo arquivo só é necessário se não existir nenhuma configuração e se uma mudança intencional de configuração for justificada. Não adicione linhas `dropCache` e `gradual` ao mesmo tempo nem duplique a seção depois de copiar exemplos de artigos diferentes.

O padrão documentado pela Microsoft já recupera o cache. Alterá-lo para `gradual` é um experimento de política, não uma atualização que sempre economiza mais memória. Isso pode manter o cache residente por mais tempo do que a recuperação imediata. Se não houver um problema demonstrado com o comportamento atual, mantenha o padrão e investigue a carga de trabalho ativa.

Depois de aplicar uma mudança por meio de uma reinicialização segura do WSL, repita o mesmo trabalho e observe a capacidade de resposta do Windows, a memória disponível no Linux e se o trabalho é concluído. Se a mudança não for útil, restaure a entrada anterior a partir do backup e aplique essa restauração com as mesmas precauções de salvar e reiniciar. Não apague a configuração inteira para remover uma linha experimental.

## Reinicie o WSL somente após salvar seu trabalho

As alterações de configuração são aplicadas quando o ambiente do WSL reinicia. Os [comandos básicos](https://learn.microsoft.com/en-us/windows/wsl/basic-commands) da Microsoft documentam o comando de desligamento global:

```
wsl --shutdown
```

Antes de usá-lo, salve arquivos, pare tarefas de treinamento ou inferência e desligue normalmente os contêineres ou bancos de dados afetados. O comando interrompe todas as distribuições em execução e a VM do WSL 2, incluindo o trabalho por trás do Docker Desktop. Não é um botão seletivo de redução de memória.

Se a memória do VmmemWSL desaparecer após o desligamento, isso confirma que o ambiente interrompido era o proprietário dela. Isso não distingue um vazamento de uma tarefa ativa ou de cache útil. Reinicie os serviços necessários e compare após a conclusão do mesmo trabalho.

## Use um limite de memória como orçamento, não como reparo

A configuração `.wslconfig` `memory` limita a memória disponível do WSL 2. Um limite muito baixo pode fazer aplicações Linux falharem ou usarem swap intensamente. Ele não remove a exigência de um programa. Escolha-o somente após medir a carga de trabalho e a RAM que o Windows também precisa, depois verifique se a aplicação é concluída com sucesso.

A [orientação do Docker Desktop para WSL](https://docs.docker.com/desktop/features/wsl/) discute a recuperação de memória para seu backend WSL. Mantenha a configuração nesse backend em vez de aplicar instruções não relacionadas do Hyper-V.

## Confirme que um limite de memória realmente entrou em vigor

Se um limite for necessário, coloque `memory` em `[wsl2]` na configuração existente. Por exemplo, `memory=8GB` significa um limite de 8 GB, não 8 GB reservados para cada distribuição. Esse é um exemplo de sintaxe, não um orçamento recomendado para todo PC. Várias distribuições do WSL 2 compartilham o orçamento global da VM, então inclua o trabalho simultâneo delas ao escolhê-lo.

Depois de salvar o trabalho e reiniciar o WSL, inspecione o total informado por `free -h` dentro de uma distribuição e compare-o com o limite pretendido, considerando a sobrecarga do sistema. Em seguida, execute o modelo ou a compilação real. Um número menor no Gerenciador de Tarefas não é sucesso se o trabalho no Linux agora é encerrado ou passa o tempo trocando páginas.

Se o limite parecer ignorado, verifique a conta do Windows proprietária do arquivo, sua extensão, se a distribuição de destino é WSL 2 e se a VM antiga parou completamente. Essas verificações são mais informativas do que baixar o número repetidamente. Não desative a swap como um segundo experimento simultâneo, já que isso muda como a carga de trabalho se comporta ao atingir seu orçamento.

Para cargas de trabalho do Docker, mantenha intacto o comportamento normal de desligamento e persistência de dados do Docker. Fechar um terminal não necessariamente interrompe seu contêiner, enquanto um desligamento global do WSL pode interromper vários serviços não relacionados. Salve o trabalho de banco de dados e de treinamento pelos próprios controles do aplicativo antes de aplicar uma mudança em toda a VM.

## Mantenha RAM e espaço em disco virtual separados

| Problema | Investigação relevante |
| --- | --- |
| A memória aumenta enquanto uma tarefa de IA é executada | Modelo, contexto e trabalho Linux concorrente |
| O cache permanece após o término do trabalho | Comportamento de recuperação e versão do WSL |
| O PC inteiro está sob pressão | Memória e comprometimento do Windows |
| O arquivo de disco do WSL permanece grande | Armazenamento de arquivos e disco virtual, não RAM |

O [guia de memória do Windows](/pt-br/windows/blog/windows-high-memory-usage) cobre as leituras do lado do host. Para capacidade de disco, use o [guia separado de armazenamento do Docker e WSL](/pt-br/windows/blog/docker-wsl-disk-space-windows). Nunca use `wsl --unregister` como atalho de limpeza: ele remove uma distribuição e seus dados em vez de resolver uma leitura de memória alta.


Canonical: https://mole.fit/pt-br/windows/blog/vmmemwsl-high-memory