Límites de memoria y CPU de WSL2: evita que consuma tu RAM

Cómo WSL2 usa realmente memoria y CPU

WSL2 no es “Linux ejecutándose en una capa de compatibilidad”. Eso era más como WSL1. WSL2 ejecuta un kernel Linux real dentro de una máquina virtual ligera gestionada por Hyper-V. Por eso WSL2 tiene mejor compatibilidad de syscalls y también por eso puede comerse tu sistema en forma de presión de RAM.

El modelo mental que no te fallará

• Windows es el propietario del hardware. WSL2 es una VM invitada. El invitado puede solicitar memoria y CPU; el host las programa y las provee.
• La memoria de WSL2 es “elástica” hasta que deja de serlo. La VM puede crecer a medida que Linux cachea datos de archivos, asigna memoria para compilaciones o ejecuta contenedores.
• Linux utilizará la RAM “libre” para caché. Esto es normal. El modo de fallo ocurre cuando esa caché no se devuelve a Windows con suficiente rapidez, o cuando la VM alcanza un límite y comienza a hacer swap.
• vmmem es la factura. El Administrador de tareas no muestra “memoria de WSL2” de la forma que deseas; muestra el proceso contenedor de la VM. Eso incluye el kernel de Linux, la page cache y todo lo que iniciaste dentro de WSL2.

La CPU es más simple: sin límites, WSL2 puede usar tantos núcleos como Windows le permita. Si alguna vez has visto una compilación de Rust o un make -j paralelo arrasar con la interactividad, has presenciado la política por defecto: “Enhorabuena, compraste núcleos; los usaremos todos.”

Una cita para mantenerte honesto, idea parafraseada de Gene Kim (autor sobre confiabilidad/ops): idea parafraseada: el flujo rápido y sistemas estables vienen de reducir el trabajo en progreso y limitar el radio de explosión. Los límites de recursos son literalmente control del radio de explosión.

Broma corta #1: WSL2 no “gotea memoria”. Simplemente la adopta permanentemente y la llama como tu directorio de build.

Hechos interesantes y contexto histórico (las partes que no escuchas en el standup)

1. WSL1 vs WSL2 fue un giro filosófico. WSL1 traducía syscalls de Linux a Windows. WSL2 trae un kernel Linux real, lo que solucionó compatibilidad pero reintrodujo comportamiento de VM respecto a recursos.
2. El proceso vmmem es un contenedor de Hyper-V. Es la representación en el host de la VM WSL2. Por eso parece “misterioso” en el Administrador de tareas y por qué matar procesos Linux al azar no lo reducirá necesariamente rápido.
3. La page cache de Linux no es “RAM desperdiciada”. Es rendimiento. Cuando se convierte en un problema, el problema es la reclamación a través del límite de la VM, no que Linux sea “codicioso”.
4. El ballooning de memoria es una técnica conocida en VMs. Los hipervisores pueden reclamar memoria del invitado con drivers balloon. El comportamiento de WSL2 ha mejorado con el tiempo, pero no es mágico ni instantáneo.
5. WSL2 tuvo historia de “memoria que no vuelve”. Las builds tempranas eran conocidas por eso. Las versiones más nuevas de Windows 11 + actualizaciones de WSL mejoraron la reclamación, especialmente con características como el page reporting.
6. El backend de Docker para WSL2 cambió la ecuación. En lugar de un pesado LinuxKit VM, Docker Desktop puede ejecutarse dentro de WSL2, lo que convierte la política de recursos de WSL2 en problema de todos, no solo de “devs Linux”.
7. El swap dentro de WSL2 no es el pagefile de Windows. WSL2 puede tener su propio archivo de swap. Puedes ajustarlo, y deberías, porque “swap por sorpresa” es cómo los portátiles empiezan a sonar como si procesaran grava.
8. El soporte de systemd en WSL2 fue un gran cambio. Pueden ejecutarse más servicios en segundo plano, lo cual es genial para realismo y también genial para consumir silenciosamente RAM y CPU si tratas WSL como una shell desechable.
9. Los límites de CPU son toscos pero efectivos. La VM no es un sandbox de cgroups por defecto. Si quieres que “las cargas de desarrollo no roben la interactividad de Windows”, los límites de CPU a nivel de VM son un martillo sorprendentemente limpio.

Guion rápido de diagnóstico

Cuando la máquina se siente lenta, no empieces editando archivos de configuración. Primero averigua qué tipo de lentitud es. Hay tres cuellos de botella comunes: presión de memoria en el host, presión de memoria en el invitado y contención de CPU. El disco es el cuarto, más sigiloso.

Primero: ¿Windows se ahoga por RAM o CPU?

• Revisa el Administrador de tareas: gráfico de memoria, gráfico de CPU y qué procesos son los principales ofensores (vmmem vs el resto).
• Decisión: Si Windows está intercambiando mucho o la memoria está >90% usada, trátalo como una emergencia de memoria en el host. Si la CPU está al 100%, trátalo como un problema de planificación/contención.

Segundo: ¿es WSL2 el culpable o solo está cerca?

• Revisa las distribuciones WSL: identifica qué está en ejecución y si hay una pila de contenedores involucrada (Docker Desktop, Kubernetes, trabajos de compilación).
• Decisión: Si vmmem es enorme y crece, confirma qué dentro de Linux está usando memoria (RSS) vs caché. Si la CPU está alta, confirma si es compilación, contenedores o servicios en segundo plano.

Tercero: ¿la memoria está “atascada” o se usa legítimamente?

• Dentro de WSL: mira free -h, ps y /proc/meminfo para separar memoria anónima (apps) de page cache.
• Decisión: Si es mayormente caché y Windows sufre, necesitas límites o una estrategia de reclamación/apagado forzado. Si es memoria real de procesos, arregla la carga (o acéptala y ponle un tope).

Cuarto: comprobación de thrash en disco (porque swap y I/O mienten)

• Dentro de WSL: si el swap está activo y la espera de I/O es alta, tu “problema de memoria” ahora es un problema de disco.
• Decisión: Reduce el uso de memoria, aumenta la asignación de RAM (contradictorio pero a veces correcto) o ajusta el swap para evitar thrash catastrófico.

Establecer límites estrictos con .wslconfig (y qué hace realmente cada control)

Si ejecutas WSL2 como un servicio de producción—y deberías, porque se comporta como tal—entonces estableces presupuestos. Los presupuestos protegen al host. También te obligan a notar cuando las cargas crecen más allá de lo que tu portátil debería soportar.

Dónde vive la configuración y cómo se aplica

.wslconfig lo lee WSL en el lado de Windows. Vive en tu directorio de perfil de usuario de Windows (típicamente C:\Users\<you>\.wslconfig). Se aplica globalmente a las VMs WSL2, no por distro.

Después de editarlo, normalmente necesitas apagar WSL para que se reinicie con la nueva configuración. “Reiniciar la terminal” no es un reinicio. WSL es más listo que eso.

Configuración base con opinión

En un portátil de desarrollo típico con 16 GB, me gusta darle a WSL2 suficiente margen para ser rápido sin permitir que se convierta en el sistema operativo. Un punto de partida razonable:

cr0x@server:~$ cat /mnt/c/Users/$USER/.wslconfig
[wsl2]
memory=8GB
processors=4
swap=4GB
swapFile=C:\\Users\\%USERNAME%\\AppData\\Local\\Temp\\wsl-swap.vhdx
localhostForwarding=true

Qué significa cada línea en la práctica:

• memory=8GB: tope estricto en la memoria de la VM. Si el invitado quiere más, reclamará caché, luego hará swap y luego sufrirá. Esto protege a Windows.
• processors=4: número máximo de vCPU. No “fija” CPUs; limita el paralelismo. Protege la capacidad de respuesta durante compilaciones y tormentas de contenedores.
• swap=4GB: tamaño del swap de WSL2. No es una característica de rendimiento; es un colchón ante fallos. Demasiado pequeño provoca OOM. Demasiado grande puede causar thrash silencioso.
• swapFile=...: dónde vive el swap. Ponlo en almacenamiento rápido. No lo pongas en perfiles en red, carpetas encriptadas con políticas raras ni en sitios que activen DLP corporativo.
• localhostForwarding=true: mantiene la red en orden. No es un control de recursos, pero la gente lo rompe y luego diagnostica mal una “lentitud” que en realidad es DNS o reenvío de puertos.

Elegir límites que no te saboteen

No hay un número “mejor” universal. Sin embargo, existe un modo de fallo universal: fijar límites tan bajos que el invitado haga swap constantemente y luego culpar a WSL2 por ser lento. Es como poner un limitador a un coche a 20 km/h y quejarse de que la autopista es estresante.

Usa estas reglas prácticas:

• Memoria: Si el host tiene 16 GB, configura WSL2 entre 6–10 GB según cuánto uses en Windows. Si ejecutas IDEs pesados en Windows, ve más bajo.
• CPU: Capa a la mitad de tus núcleos para máquinas de desarrollador. Si tienes 12–16 núcleos, da 6–8. Si tienes 4 núcleos, da 2 y acepta la realidad.
• Swap: 2–8 GB es común. Si compilas proyectos enormes o ejecutas Kubernetes, ve más alto. Si te interesa la latencia interactiva, ve más bajo y corrige el uso de memoria.

Broma corta #2: El swap es como la cafeína: un poco te mantiene vivo, demasiado te pone nervioso e insoportable.

Recuperar memoria: por qué “debería liberar RAM” no es un plan

La queja más común es: “Cerré todo en Linux, pero Windows sigue mostrando vmmem usando 10 GB.” A veces eso es un bug. A menudo es solo física: el invitado usó memoria para caché y el host no la recupera inmediatamente.

Qué suele estar pasando

• Linux cacheó datos de archivos. Compilaciones, instalaciones de paquetes y descargas de imágenes de contenedores llenan la page cache.
• El invitado está inactivo pero aún retiene páginas. Esas páginas son “reclamables” dentro de Linux, pero el host no fuerza la reclamación hasta que exista presión.
• Windows ve la asignación de la VM, no que Linux esté “libre”. Así que ves un número grande y asumes que es uso activo.

Qué puedes hacer al respecto

Hay tres capas de respuesta, de menos a más disruptivas:

1. No hagas nada hasta que el host lo necesite. Si Windows tiene memoria libre y no estás haciendo paging, no optimices por instinto.
2. Aplica límites sensatos. Esta es la solución a largo plazo: WSL2 no podrá inflarse más allá del presupuesto.
3. Reinicia WSL cuando termines trabajo pesado. Es el botón práctico de “liberar todo ahora”. No es elegante. Es efectivo.

Además: si constantemente alcanzas el tope, eso no es un mal comportamiento de WSL2. Es tu carga de trabajo diciéndote que necesita más RAM de la que tu máquina puede proporcionar cómodamente. O ajustas límites hacia arriba, reduces paralelismo o dejas de fingir que un portátil es una granja de builds.

Swap, almacenamiento y la lenta muerte de tu SSD

El swap no es gratis. Es dolor diferido. En máquinas de desarrollador, el swap aparece durante el “caos pico”: compilaciones paralelas, unas cuantas réplicas de contenedores, pestañas del navegador multiplicándose en segundo plano y alguien abriendo Teams.

Por qué el swap es especialmente sigiloso en WSL2

• Puedes tener swap dentro del invitado (archivo de swap de WSL2) mientras Windows tiene su propio pagefile. Bajo presión, puedes acabar paginando dos veces: Windows paginando la VM mientras Linux hace swap dentro. Es tan divertido como suena.
• La espera de I/O se convierte en tu cuello de botella real. Los gráficos de CPU quizá parezcan “bien”, pero todo se detiene porque esperas al disco.
• El tamaño del swap interactúa con los límites. Un tope de memoria ajustado más un swap grande puede mantener una carga cojeando en lugar de fallar rápido. Eso es “productivo” o “sufrimiento extendido”, dependiendo de tus plazos.

La ubicación del almacenamiento importa

WSL2 usa un disco virtual (VHDX) por cada distro. Ese disco normalmente está bajo tu perfil de Windows. Si tienes un disco del sistema lento, todo en WSL2 hereda ese dolor—especialmente capas de contenedores, caches de paquetes y artefactos de build.

Si quieres rendimiento en WSL2, mantén las cargas con mucho churn dentro del sistema de archivos Linux (ext4 en el VHDX) en lugar de trabajar desde /mnt/c. La interoperabilidad con el sistema de archivos de Windows es buena, pero no es tan “nativa de Linux”.

Docker Desktop y Kubernetes en WSL2: ¿quién manda realmente?

Cuando Docker entra en juego, muchos equipos pierden el control de dónde vive el control de recursos. Ajustan límites en Docker y luego se preguntan por qué vmmem sigue creciendo. O ajustan límites de WSL2 y se preguntan por qué Kubernetes falla.

Entiende la jerarquía

• El límite de la VM WSL2 fija el techo de toda la VM Linux. Docker dentro de ella está aguas abajo de ese tope.
• Las configuraciones de recursos de Docker (si usas la UI de Docker Desktop) pueden o no aplicarse como piensas dependiendo del backend y la versión. Cuando el backend es WSL2, los límites de WSL2 son el techo duro.
• Kubernetes añade churn en segundo plano. Incluso clusters “inactivos” ejecutan componentes del plano de control, controladores y watchers. Eso es actividad CPU y huella de memoria en estado estable.

Mi consejo operativo: decide si tu portátil puede albergar un cluster local y aplica esa decisión con límites. Si lo permites, presupúestalo. No lo dejes como un pasajero accidental.

Tareas prácticas: comandos, salidas y decisiones

Estos son los chequeos prácticos que realmente uso. Cada tarea incluye un comando, una salida representativa y la decisión que tomo a partir de ella. Ejecuta los comandos del lado de Windows en PowerShell; ejecuta los comandos de Linux dentro de WSL.

Task 1: Confirmar versión de WSL y qué está en ejecución

cr0x@server:~$ wsl.exe --list --verbose
  NAME            STATE           VERSION
* Ubuntu-22.04    Running         2
  Debian          Stopped         2

Significado: Ubuntu está en ejecución en WSL2. Debian está detenida. Si pensabas “no hay nada corriendo”, estabas equivocado.

Decisión: Si vmmem está alto, céntrate en la(s) distro(s) en ejecución. Detén lo que no necesites.

Task 2: Reinicio forzado de WSL para recuperar memoria del host

cr0x@server:~$ wsl.exe --shutdown

Significado: Todas las distros WSL y la VM WSL2 se terminan. La memoria debería bajar poco después.

Decisión: Usa esto cuando Windows esté bajo presión ahora. No lo uses como ritual diario para evitar poner límites.

Task 3: Ver la huella de memoria WSL en el host (rápido y sucio)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-Process vmmem | Select-Object Name,Id,@{n='WS(MB)';e={[math]::Round($_.WorkingSet64/1MB,0)}},CPU"
Name  Id   WS(MB) CPU
vmmem 9480 10324  812.55

Significado: La VM está reteniendo alrededor de 10 GB en working set. El tiempo de CPU indica que ha estado activa.

Decisión: Si Windows está haciendo paging y esto es grande, aplica un tope de memoria y/o apaga WSL.

Task 4: Revisar memoria dentro de WSL (separar cache de presión)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.6Gi       2.1Gi       1.2Gi       128Mi       4.3Gi       5.1Gi
Swap:          4.0Gi       0.0Gi       4.0Gi

Significado: La mayor parte de la memoria está en buff/cache, pero available está saludable. Esto no es una emergencia dentro de Linux.

Decisión: Si Windows está bien, ignóralo. Si Windows no está bien, los límites/reclamación importan más que perseguir “usado”.

Task 5: Identificar los mayores usuarios de memoria (RSS real, no sensaciones)

cr0x@server:~$ ps aux --sort=-rss | head -n 8
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      1321  3.2  6.1 912648 475832 ?       Ssl  09:12   2:44 dockerd
cr0x      4882  1.1  4.8 2879300 376544 ?      Sl   10:01   0:51 node
cr0x      5021 18.9  4.2 1845500 332100 ?      Rl   10:05   1:32 rustc
postgres  2110  0.7  2.0  891200 158300 ?      Ssl  09:20   0:33 postgres
root       823  0.2  1.1  368012  88224 ?      Ss   09:10   0:08 containerd

Significado: Esta es memoria real de procesos (RSS). Aquí, Docker y las compilaciones son consumidores importantes.

Decisión: Si alcanzas topes, reduce paralelismo, detén servicios o mueve cargas pesadas fuera del portátil.

Task 6: Ver si estás haciendo swap dentro de WSL

cr0x@server:~$ swapon --show
NAME      TYPE SIZE USED PRIO
/swapfile file   4G  512M   -2

Significado: El swap está en uso. No es automáticamente malo, pero es una etiqueta de advertencia de rendimiento.

Decisión: Si el rendimiento interactivo es pobre, trata el uso de swap como disparador para reducir la carga o subir el tope de memoria.

Task 7: Encontrar espera de I/O (¿es el disco el verdadero cuello de botella?)

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0 524288 842000  68000 3380000  20   45  1200   800  560  940 18  7 62 13  0
 1  1 524288 812000  68000 3310000  10   25  2400  1900  620 1020 12  6 58 24  0
 0  1 524288 798000  68000 3290000   0   12  3100  2200  640 1090 10  5 52 33  0

Significado: wa (espera de I/O) está subiendo. Se está haciendo swap in/out. Ahora estás pagando intereses por la deuda de memoria.

Decisión: Reduce la presión de memoria primero. Si persiste, considera almacenamiento más rápido, menos swap o menos trabajos concurrentes.

Task 8: Comprobar contención CPU y carga dentro de WSL

cr0x@server:~$ uptime
 10:14:22 up  1:08,  0 users,  load average: 9.12, 7.44, 5.81

Significado: El load average es alto respecto a las CPUs asignadas. Si limitaste a 4 CPUs y la carga es 9, tienes cola.

Decisión: O aumentas processors o reduces el paralelismo (make -j, herramientas de build, réplicas de contenedores).

Task 9: Confirmar cuántas CPUs ve WSL

cr0x@server:~$ nproc
4

Significado: Tu VM WSL2 actual ve 4 CPUs. Eso coincide con un tope processors=4.

Decisión: Si las compilaciones son lentas pero Windows está inactivo, aumenta el tope de CPU. Si Windows sufre, mantenlo limitado.

Task 10: Localizar los culpables reales de uso de disco en WSL

cr0x@server:~$ sudo du -xh /var/lib | sort -h | tail -n 8
1.1G	/var/lib/apt
2.4G	/var/lib/snapd
6.2G	/var/lib/docker
6.2G	/var/lib/docker/overlay2
7.9G	/var/lib

Significado: El almacenamiento de Docker domina. Esto se correlaciona con la presión de memoria también (page cache, churn de metadatos).

Decisión: Purga imágenes/volúmenes, mueve builds o acepta que acaparar contenedores localmente tiene costes.

Task 11: Ver límites de memoria actualmente aplicados desde Windows (comprobación de coherencia)

cr0x@server:~$ cat /proc/meminfo | head -n 5
MemTotal:        7961888 kB
MemFree:         1214320 kB
MemAvailable:    5389120 kB
Buffers:           68040 kB
Cached:          3129480 kB

Significado: MemTotal está alrededor de 7.6–7.9 GB, lo que implica que tu tope de memoria de WSL2 está en efecto.

Decisión: Si esperabas 16 GB y obtuviste 8 GB, tu tope es demasiado bajo para esa carga (o es el tope correcto y la carga debe cambiar).

Task 12: Buscar servicios systemd que silenciosamente consumen recursos

cr0x@server:~$ systemctl --no-pager --type=service --state=running | head -n 12
  UNIT                         LOAD   ACTIVE SUB     DESCRIPTION
  cron.service                  loaded active running Regular background program processing daemon
  dbus.service                  loaded active running D-Bus System Message Bus
  docker.service                loaded active running Docker Application Container Engine
  rsyslog.service               loaded active running System Logging Service
  ssh.service                   loaded active running OpenBSD Secure Shell server
  systemd-journald.service      loaded active running Journal Service

Significado: Docker y SSH están en ejecución, además de servicios base. Esto es una huella real en segundo plano.

Decisión: Detén lo que no necesitas. Si usas Docker solo ocasionalmente, no lo dejes idling para siempre.

Task 13: Detener un servicio pesado y confirmar la diferencia

cr0x@server:~$ sudo systemctl stop docker
cr0x@server:~$ ps aux --sort=-rss | head -n 5
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
cr0x      4882  0.8  4.6 2879300 362112 ?      Sl   10:01   0:54 node
postgres  2110  0.7  2.0  891200 158100 ?      Ssl  09:20   0:33 postgres
root       823  0.1  0.9  342200  72140 ?      Ss   09:10   0:08 containerd

Significado: Los procesos relacionados con Docker disminuyeron. La memoria debería reducirse con el tiempo; los picos de CPU disminuirán inmediatamente.

Decisión: Si esto mejora materialmente la capacidad de respuesta de Windows, has encontrado un contribuyente importante. Establece la política: no ejecutes Docker 24/7 a menos que lo necesites.

Task 14: Confirmar que Windows ve los límites después del reinicio

cr0x@server:~$ wsl.exe --shutdown
cr0x@server:~$ wsl.exe -d Ubuntu-22.04 -- cat /proc/meminfo | head -n 1
MemTotal:        7961888 kB

Significado: La VM se reinició y sigue limitada a ~8 GB.

Decisión: Si no cambió, editaste el archivo equivocado, usaste sintaxis inválida o no reiniciaste la VM.

Tres micro-historias del mundo corporativo (porque producción siempre tiene opinión)

Micro-historia 1: El incidente causado por una suposición errónea

Un equipo desplegó WSL2 como entorno de desarrollo por defecto. Fue una decisión razonable: herramientas consistentes, menos debates de “funciona en mi máquina” y onboarding más sencillo. Dijeron a todos “es ligero”. La frase hizo daño.

En una semana, llegaron quejas de portátiles: desconexiones de VPN, Teams congelándose en medio de llamadas, toda la UI de Windows con tartamudeos. IT culpó inicialmente a la protección de endpoints. Los desarrolladores echaron la culpa a actualizaciones de Windows. La realidad fue más simple: la gente ejecutaba pilas pesadas de contenedores todo el día, y la VM WSL2 se expandió felizmente para llenar la memoria. El host empezó a paginar y todo lo que depende de latencia predecible comenzó a tambalearse.

La suposición equivocada no fue “WSL2 es malo”. Fue “WSL2 es pequeño por defecto”. En un mundo de VMs, “por defecto” suele significar “sin tope”. Lo arreglaron publicando una base estándar .wslconfig (topes de memoria y CPU), más una regla interna: si necesitas más, lo solicitas y lo justificas.

Lo sorprendente: los tiempos de build cambiaron poco. La estabilidad interactiva mejoró de inmediato. Eso pasa cuando dejas de pelear por los últimos 2 GB de RAM como si fueran un mineral escaso.

Micro-historia 2: La optimización que salió mal

Otra organización tuvo una cruzada de rendimiento bienintencionada: “Hagamos builds más rápidos dando más núcleos a WSL2”. Empujaron una configuración que igualaba processors al número total de núcleos de la máquina. Las compilaciones volaron. Todos colgaron capturas de pantalla. Hubo momentum.

Luego vino el revés: los desarrolladores también ejecutan IDEs en Windows, navegadores y agentes de seguridad. Darle a WSL2 todos los CPUs no los “roba” de forma permanente, pero creó contención persistente. Builds paralelos, health checks de contenedores e indexados en segundo plano dentro de WSL2 generaron hilos ejecutables constantes. Windows siguió siendo responsive en el sentido trivial (el ratón se movía) pero el trabajo sensible a latencia se degradó: llamadas de vídeo, compartir pantalla, incluso escribir con retardo bajo carga.

Intentaron un segundo “arreglo”: bajar la memoria de WSL2 mientras mantenían CPU ilimitada. Eso convirtió el sistema en una fábrica de swap. Las builds se hicieron más lentas que antes. Peor aún, impredecibles—rápidas un día, malas al siguiente, según lo que más corría en ese momento.

La solución real fue aburrida: limitar CPU a una fracción sensata, limitar memoria para proteger al host y ajustar el paralelismo de las builds por proyecto. El rendimiento pico bajó un poco. La experiencia media del desarrollador mejoró mucho. En entornos corporativos, la media es lo que importa.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo de plataforma mantuvo un “perfil de estación de trabajo conocido bueno”. No era glamoroso. Era un pequeño conjunto de defaults: un archivo .wslconfig, una configuración estándar de Docker y una lista de verificación para repos pesados. La gente se quejó por el control central, como siempre hasta que algo falla.

Entonces llegó una gran actualización de dependencias. Las builds crecieron en uso de memoria, las imágenes de contenedor aumentaron y los clusters de pruebas locales se hicieron más pesados. La org sin estándares empezó a apagar incendios: “¿por qué se están derritiendo las máquinas de todos?” La org con el perfil vio algunas ralentizaciones, sí, pero no vieron inestabilidad en masa.

Porque su perfil incluía una práctica simple: antes de builds grandes o trabajo con clusters, los desarrolladores hacían una comprobación rápida (memoria disponible, uso de swap, servicios en ejecución). Y después, apagaban WSL si habían terminado. No era automatización elegante; era higiene operativa.

Cuando el salto de dependencias aumentó las necesidades de memoria, el equipo de plataforma ajustó los límites base cuidadosamente y comunicó las compensaciones. A nadie le encantó, pero nadie perdió un día por latencia misteriosa. Lo aburrido salvó el día otra vez. Eso es básicamente SRE en una frase.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: Windows está lento, el Administrador de tareas muestra vmmem usando “demasiada” RAM

Causa raíz: La VM WSL2 se infló por page cache o memoria de la carga, y el host ahora tiene presión de memoria.

Solución: Establece memory= en .wslconfig, luego wsl.exe --shutdown. Si necesitas recuperar la memoria inmediatamente, apaga primero y luego ajusta.

2) Síntoma: WSL2 está lento aunque “le puse límites”

Causa raíz: Los límites son demasiado estrictos y Linux está haciendo swap o reclamando caché constantemente.

Solución: Revisa swapon --show y vmstat. Aumenta memory o reduce el paralelismo de la carga. No pases hambre al invitado y esperes velocidad.

3) Síntoma: CPU al máximo, la UI de Windows tartamudea durante compilaciones

Causa raíz: WSL2 tiene demasiadas vCPU o las herramientas de build se están sobre-suscribiendo.

Solución: Define processors= a un valor sensato. También ajusta la concurrencia de compilación (por ejemplo, reduce -j o contadores de workers específicos).

4) Síntoma: vmmem permanece grande después de detener procesos Linux

Causa raíz: La page cache queda asignada; la reclamación por parte del host no es inmediata.

Solución: Acepta si el host tiene margen. Si no, usa wsl.exe --shutdown e implementa topes para que no crezca más allá del presupuesto.

5) Síntoma: Disco ocupado, ventiladores suenan, todo se pausa periódicamente

Causa raíz: Swap y actividad intensiva en el sistema de archivos (a menudo overlay de Docker) provocando picos de I/O wait.

Solución: Reduce la presión de memoria, purga almacenamiento de Docker, evita builds pesadas en /mnt/c y mantén el swap moderado. Si necesitas mucha memoria, mejora la RAM en vez de “afinar más”.

6) Síntoma: La red parece lenta; la gente culpa a CPU o memoria

Causa raíz: A menudo configuración DNS, interacción con VPN o problemas de reenvío localhost—enmascarado como “lentitud del sistema”.

Solución: Verifica que WSL esté realmente limitado por CPU/memoria antes de afinar. Mantén localhostForwarding=true salvo que tengas una razón específica para no hacerlo.

7) Síntoma: Después de editar .wslconfig, nada cambia

Causa raíz: El archivo está en la ubicación equivocada, la sintaxis es inválida o WSL no se reinició.

Solución: Asegúrate de que esté en la ruta del perfil de usuario de Windows, valida las claves, luego wsl.exe --shutdown y arranca la distro otra vez. Confirma con /proc/meminfo y nproc.

Listas de verificación / plan paso a paso

Plan A: Evitar que WSL2 se coma tu RAM (sin romper tu flujo)

1. Mide primero. Revisa el working set de vmmem y la presión de memoria en Windows.
2. Inventario de lo que está en ejecución. wsl.exe --list --verbose, luego dentro de WSL revisa los procesos principales.
3. Decide tu presupuesto. Elige topes de memoria y CPU según la RAM/núcleos del host y qué debe permanecer responsivo en Windows.
4. Aplica .wslconfig. Fija memory, processors y swap de forma intencional.
5. Reinicia WSL. wsl.exe --shutdown y vuelve a lanzar la distro.
6. Valida los límites. Usa /proc/meminfo y nproc.
7. Vigila el swap. Si el swap crece durante trabajo normal, los límites son demasiado bajos o la carga es muy pesada.
8. Arregla la carga. Detén servicios en segundo plano que no necesitas, purga almacenamiento de contenedores, reduce el paralelismo de builds.

Plan B: Tu portátil ya está en llamas (modo triage)

1. Alivio inmediato: wsl.exe --shutdown.
2. Confirma que Windows se recupera: la memoria baja, el disco deja de thrasear, la UI vuelve a ser responsiva.
3. Aplica topes antes de reiniciar cargas pesadas: crea o ajusta .wslconfig.
4. Reinicia solo lo necesario: inicia una distro; evita autoarrancar Docker/Kubernetes hasta confirmar estabilidad.
5. Vuelve a ejecutar el guion rápido de diagnóstico: verifica si el próximo cuello de botella es CPU, memoria o disco.

Plan C: Hacerlo sostenible para equipos

1. Estandariza una base. Publica un .wslconfig recomendado para tiers comunes de portátiles (16 GB, 32 GB).
2. Define rutas de escalado. Si alguien necesita 20 GB en WSL2, eso es una solicitud de hardware o una estrategia de build remota, no un ajuste local secreto.
3. Enseña que “la caché no es mala”. Enseña a la gente a leer available, uso de swap y espera de I/O.
4. Construye con presupuestos. CI debe representar la realidad; no dejes que los entornos locales se conviertan en mini-datacenters sin guardrails.

FAQ

1) ¿Por qué WSL2 usa tanta RAM incluso cuando “no hago nada”?

Porque Linux cachea agresivamente y WSL2 es una VM. “Nada” a menudo incluye demonios de Docker, watchers, servidores de lenguaje y datos de cache del sistema de archivos. Revisa free -h y mira available vs buff/cache.

2) ¿Es seguro limitar la memoria de WSL2?

Sí. A menudo es la medida correcta. El riesgo es ajustarla demasiado baja y forzar swap o kills por OOM dentro de Linux. Ponla lo bastante alta para tu carga real, no la optimista.

3) ¿Por qué cerrar mis apps de Linux no reduce inmediatamente vmmem en el Administrador?

Porque la VM puede seguir reteniendo memoria para caché y el host puede no reclamarla al instante. Si Windows la necesita ahora, apaga WSL. Si Windows está bien, no te alarmes por un número.

4) ¿El comando wsl.exe --shutdown borra algo?

No. Termina instancias de WSL. Tus archivos y el estado de la distro persisten en disco. Perderás sesiones en memoria y cualquier estado volátil, como si reiniciaras.

5) ¿Debería poner swap a 0?

A veces. Si prefieres fallar rápido (OOM) en vez de lento thrash, deshabilitar swap puede ser defendible. Para la mayoría de desarrolladores, un swap moderado es red de seguridad. Si lo deshabilitas, prepárate para kills abruptos bajo presión.

6) ¿Cuál es un valor sensato para processors?

La mitad de tus núcleos es un buen defecto. Si tienes 8 núcleos, da 4. Si tienes 16, da 6–8. Si haces compilaciones paralelas pesadas y Windows está inactivo, súbelo. Si te importa la capacidad de respuesta de la UI, capéalo.

7) ¿Trabajar en /mnt/c es más lento que en el sistema de archivos de Linux?

Normalmente sí—especialmente para cargas con muchas operaciones de archivos pequeños (node_modules, directorios target de Rust, capas de contenedor). Mantén árboles de build pesados dentro del sistema de archivos de la distro para rendimiento y menos casos raros.

8) Uso Docker Desktop con WSL2. ¿Debo afinar Docker o WSL?

Empieza por WSL2 porque es el techo duro para la VM. Luego ajusta las cargas de Docker (purga imágenes, ajusta réplicas de compose, fija límites de memoria en contenedores) para permanecer dentro de ese techo.

9) ¿Puedo establecer límites diferentes por distro?

.wslconfig es global para el comportamiento de la VM WSL2. Si necesitas aislamiento por distro, estás en territorio de “usar VMs separadas u otras herramientas”, no solo ajustes de WSL2.

10) ¿Cómo sé si mi problema es memoria o disco?

Busca actividad de swap y espera de I/O. Dentro de WSL, swapon --show te dice si se usa swap; vmstat muestra wa y swap in/out. Si wa es alto y el swap está activo, el disco es ahora el cuello de botella.

Siguientes pasos que realmente funcionan

Si WSL2 se está comiendo tu RAM, no lo trates como un bug espeluznante de Windows. Trátalo como lo que es: una VM ejecutando un sistema operativo real con comportamiento real de caché. Luego haz lo que hacen los adultos en sistemas de producción: establece presupuestos, mide y responde a la presión temprano.

1. Elige un presupuesto hoy: configura memory y processors en .wslconfig y reinicia WSL.
2. Valida con evidencia: confirma que /proc/meminfo y nproc coincidan con tu intención.
3. Vigila swap y espera de I/O: si los ves durante trabajo normal, o sube el tope o reduce la carga.
4. Deja de tener servicios pesados en idling: Docker/Kubernetes deben ser una decisión deliberada, no un estilo de vida en segundo plano.
5. Usa el shutdown como herramienta, no como muleta: es una palanca de emergencia genial, pero los límites son la solución a largo plazo.

Una vez hecho eso, WSL2 se vuelve lo que debería ser: un entorno Linux sólido sobre Windows. No un compañero de piso no invitado con opiniones fuertes sobre tu presupuesto de memoria.