# VmmemWSL con mucha memoria: localiza el trabajo antes de recuperar RAM

`VmmemWSL` en el Administrador de tareas representa los recursos que usa el entorno de máquina virtual de WSL. Su memoria puede incluir cargas de trabajo activas de Linux y caché. Si Docker, un servidor de modelos de IA o herramientas de desarrollo se ejecutan ahí, cerrar un editor de Windows no necesariamente detiene ese trabajo.

Primero determina si la memoria pertenece a una tarea en ejecución o si permanece en caché después de que la tarea termina. Borrar un disco virtual de WSL no es una solución para la memoria y puede destruir el entorno Linux y sus datos.

## Localiza el trabajo dentro de WSL

Desde PowerShell, inspecciona el entorno instalado:

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

Dentro de la distribución de Linux correspondiente, usa estas vistas de solo lectura:

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

Las lecturas de Linux no tienen exactamente el mismo alcance que el total de la VM del Administrador de tareas. Úsalas para localizar procesos y distinguir la memoria disponible de la caché de archivos, no para forzar a que todos los números cuadren. Para el trabajo que pertenece a Docker, inspecciona los contenedores en ejecución de Docker Desktop y detén la tarea prevista mediante su control habitual.

Un servidor de IA puede mantener un modelo cargado después de responder. Detén esa carga de trabajo de forma deliberada si ya no la necesitas. No mates un proceso arbitrario solo porque su nombre no te resulte familiar.

## Lee una muestra de memoria de Linux sin llamar fuga a cada caché

En la salida de `free -h`, presta atención a `available`, así como a `used` y `buff/cache`. Linux usa la memoria que de otro modo estaría inactiva para datos de archivos, y parte de esa memoria se puede reclamar cuando las aplicaciones la necesitan. Por lo tanto, un valor pequeño de `free` por sí solo no basta para establecer que Linux se ha quedado sin memoria.

El listado de procesos informa el RSS en KiB, mientras que `free -h` usa unidades legibles para humanos. Las páginas compartidas y la sobrecarga de la VM también hacen que sumar las filas de procesos no necesariamente coincida con el número VmmemWSL del Administrador de tareas. Usa las filas más grandes para identificar al propietario y luego inspecciona la carga de trabajo con nombre, en lugar de forzar a que los totales coincidan.

Si Docker está implicado, estos comandos de solo lectura identifican los contenedores en ejecución y toman una muestra de recursos, siguiendo la [referencia de Docker stats](https://docs.docker.com/reference/cli/docker/container/stats/):

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

Ejecútalos en el entorno conectado al backend de Docker que se está investigando. Un contexto de Docker distinto puede describir una máquina remota, así que confirma el destino antes de actuar. La cifra de memoria que muestra un contenedor y el total de toda la VM de WSL tienen alcances diferentes.

Compara tres estados: antes de que empiece el trabajo de IA, mientras se ejecuta y después de que la aplicación haya descargado normalmente su modelo o detenido el trabajo. Si el proceso grande sigue vivo, la reclamación de caché no sustituye a decidir si ese proceso debería seguir ejecutándose. Si el proceso se reduce pero la caché permanece, el comportamiento de reclamación pasa a ser una cuestión más relevante.

## Revisa la configuración actual de recuperación

La [referencia de configuración de WSL](https://learn.microsoft.com/en-us/windows/wsl/wsl-config) de Microsoft coloca los ajustes globales de WSL 2 en `%USERPROFILE%\.wslconfig`. Es distinto de `/etc/wsl.conf` dentro de una distribución.

La referencia actual incluye `autoMemoryReclaim` en `[experimental]`, con `dropCache` como valor predeterminado y `gradual` como otro modo admitido. Por lo tanto, el consejo antiguo de habilitar un valor predeterminado deshabilitado de forma universal puede estar desactualizado. Revisa la versión de WSL instalada y tu configuración existente antes de añadir nada.

Si quieres deliberadamente una recuperación gradual de la caché en una versión que admita el ajuste, combina esta entrada en el archivo existente:

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

No sobrescribas ajustes no relacionados ni crees secciones duplicadas. Esto cambia cómo se recupera la memoria en caché; no hace que un modelo o una base de datos activos necesiten menos memoria. Compara la misma carga de trabajo antes de decidir si mantienes el cambio.

## Edita la configuración existente y conserva una forma de volver atrás

Abre `%USERPROFILE%` en el Explorador de archivos y activa las extensiones de nombre de archivo antes de crear o editar `.wslconfig`. Un archivo guardado accidentalmente como `.wslconfig.txt` no es la configuración deseada. Primero copia una configuración existente a una copia de seguridad y conserva las secciones que no estén relacionadas con la memoria.

Dentro de una sección `[experimental]` existente, cambia solo la entrada de reclamación que se está probando. Solo se necesita un archivo nuevo si no existe ninguna configuración y si está justificado un cambio intencional de ajuste. No añadas a la vez líneas `dropCache` y `gradual` ni dupliques la sección después de copiar ejemplos de artículos distintos.

El valor predeterminado documentado por Microsoft ya reclama la caché. Cambiarlo a `gradual` es un experimento de política, no una mejora que siempre ahorre más memoria. Puede dejar la caché residente durante más tiempo que la reclamación inmediata. Si no hay un problema demostrado con el comportamiento actual, deja el valor predeterminado y investiga la carga de trabajo activa en su lugar.

Después de aplicar un cambio mediante un reinicio seguro de WSL, repite el mismo trabajo y observa la capacidad de respuesta de Windows, la memoria disponible en Linux y si el trabajo finaliza. Si el cambio no resulta útil, restaura la entrada anterior desde la copia de seguridad y luego aplica esa restauración con las mismas precauciones de guardar y reiniciar. No borres toda la configuración para eliminar una sola línea experimental.

## Reinicia WSL solo después de guardar su trabajo

Los cambios de configuración se aplican cuando se reinicia el entorno de WSL. Los [comandos básicos](https://learn.microsoft.com/en-us/windows/wsl/basic-commands) de Microsoft documentan el comando de apagado global:

```
wsl --shutdown
```

Antes de usarlo, guarda los archivos, detén los trabajos de entrenamiento o inferencia y apaga los contenedores o bases de datos afectados de forma normal. El comando detiene todas las distribuciones en ejecución y la VM de WSL 2, incluido el trabajo detrás de Docker Desktop. No es un botón selectivo para recortar memoria.

Si la memoria de VmmemWSL desaparece tras el apagado, eso confirma que el entorno detenido era el propietario. No distingue una fuga de una tarea activa ni de una caché útil. Reinicia los servicios necesarios y compara después de que el mismo trabajo termine.

## Usa un límite de memoria como presupuesto, no como reparación

El ajuste `.wslconfig` `memory` limita la memoria disponible de WSL 2. Un límite demasiado bajo puede hacer que las aplicaciones de Linux fallen o recurran en exceso al swap. No elimina el requisito de un programa. Elígelo solo después de medir la carga de trabajo y la RAM que Windows también necesita, y luego comprueba que la aplicación termina correctamente.

La [guía de WSL](https://docs.docker.com/desktop/features/wsl/) de Docker Desktop trata la recuperación de memoria para su backend de WSL. Mantén la configuración en ese backend en lugar de aplicar instrucciones no relacionadas de Hyper-V.

## Confirma que un límite de memoria realmente ha surtido efecto

Si se necesita un límite, coloca `memory` bajo `[wsl2]` en la configuración existente. Por ejemplo, `memory=8GB` significa un límite de 8 GB, no 8 GB reservados para cada distribución. Eso es un ejemplo de sintaxis, no un presupuesto recomendado para todos los equipos. Varias distribuciones de WSL 2 comparten el presupuesto global de la VM, así que incluye su trabajo simultáneo al elegirlo.

Después de guardar el trabajo y reiniciar WSL, inspecciona el total que informa `free -h` dentro de una distribución y compáralo con el límite previsto, teniendo en cuenta la sobrecarga del sistema. Luego ejecuta el modelo o la compilación reales. Una cifra más pequeña en el Administrador de tareas no es un éxito si ahora se mata el trabajo de Linux o si pasa el tiempo haciendo swapping.

Si parece que se ignora el límite, comprueba la cuenta de Windows propietaria del archivo, su extensión, si la distribución de destino es WSL 2 y si la VM anterior se detuvo por completo. Estas comprobaciones son más informativas que bajar el número repetidamente. No desactives el swap como un segundo experimento simultáneo, ya que eso cambia cómo se comporta la carga de trabajo cuando alcanza su presupuesto.

Para las cargas de trabajo de Docker, mantén intacto el comportamiento normal de apagado y persistencia de datos de Docker. Cerrar una terminal no necesariamente detiene su contenedor, mientras que un apagado global de WSL puede interrumpir varios servicios no relacionados. Guarda el trabajo de bases de datos y de entrenamiento mediante sus propios controles de aplicación antes de aplicar un cambio que afecte a toda la VM.

## Mantén separados el espacio de RAM y el del disco virtual

| Problema | Investigación relevante |
| --- | --- |
| La memoria sube mientras se ejecuta una tarea de IA | Modelo, contexto y trabajo concurrente en Linux |
| La caché permanece después de que termina el trabajo | Comportamiento de recuperación y versión de WSL |
| Todo el equipo está bajo presión | Memoria y confirmación de Windows |
| El archivo de disco de WSL sigue siendo grande | Archivos y almacenamiento del disco virtual, no la RAM |

La [guía de memoria de Windows](/es/windows/blog/windows-high-memory-usage) cubre las lecturas del lado del host. Para la capacidad del disco, usa la [guía de almacenamiento de Docker y WSL](/es/windows/blog/docker-wsl-disk-space-windows) por separado. Nunca uses `wsl --unregister` como atajo de limpieza: elimina una distribución y sus datos en lugar de resolver una lectura de memoria alta.


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