Cuánta memoria se puede liberar realmente en Windows

En esta página

Respuesta corta

En realidad se puede liberar menos de lo que prometen los «optimizadores de memoria». En este experimento, desactivar componentes en segundo plano liberó 1,0–1,5 GB de memoria disponible y redujo el volumen de confirmaciones (commit) en un 52 % en la serie 2. Pero los métodos rápidos populares no funcionan: terminar procesos del shell — Windows los reinicia por sí mismo en unos 20 segundos; limpiar el working set — las páginas descargadas permanecen en la RAM como caché; parámetros de registro del administrador de memoria — no hay beneficio confirmado. Las desactivaciones puntuales sobre un sistema ya optimizado dieron unos honestos +22–30 MB. La memoria en la lista standby es caché que ya está contabilizada en la «disponible».

Estado: las cifras finales se obtuvieron en una máquina virtual con 8 GB de RAM en Windows 11 (26H2, build 26300.9457). Las direcciones están confirmadas por la documentación de Microsoft y por nuestros experimentos controlados; los valores absolutos en otra configuración serán distintos.

Afirmaciones verificables

Verificamos cuatro afirmaciones:

Terminar procesos en segundo plano «innecesarios» libera memoria.
Limpiar el working set o la lista standby (la mecánica de los «optimizadores de RAM») libera memoria.
Los parámetros de registro del administrador de memoria liberan memoria de forma notable.
Desactivar componentes en segundo plano libera un gran volumen de memoria.

Ámbito del estudio

Windows 11 Pro, build 26300.9457 (26H2); máquina virtual, 8 GB de RAM;
dos estados de una misma instalación: el inicial («antes») y el posterior a aplicar el perfil de optimización de BoosterX — la medición se realizó en dos series independientes (el protocolo detallado y el resto de métricas están en «Inactividad silenciosa: el fondo de Windows antes y después de la optimización»);
sobre el estado «después» — un paquete de desactivaciones puntuales de fuentes en segundo plano (autologistas de diagnóstico ETW, servicios de notificaciones, de copia de instantáneas y de orquestador de actualizaciones);
métricas: memoria disponible y ocupada, volumen de confirmaciones (commit), nonpaged/paged pool, working set y private bytes por procesos, errores de página (hard faults).

No se incluyeron: hardware físico, sistemas con otro volumen de RAM, experimentos con la desactivación del pagefile y utilidades de terceros de «optimización de memoria».

Metodología

El inventario de memoria se tomó en inactividad estable: contadores del sistema (disponible, ocupada, commit, pools) y lista de procesos con working set y private bytes.
Experimento controlado «terminar procesos del shell»: se detuvieron dos procesos de interfaz (SearchHost.exe y StartMenuExperienceHost), el estado se comprobó a los 20 y 40 segundos; el commit se registró antes y después.
El paquete de desactivaciones puntuales se aplicó al estado «después», luego se realizó un reinicio y una comparación con cuatro arranques de control del mismo estado sin el paquete; las pruebas de arranque verificaron la ausencia de regresión de rendimiento.
La capa de medición (trazado, contadores, scripts de recolección) ocupa memoria por sí misma — hasta cien y más MB de working set en mediciones concretas; esto se indica en las limitaciones.

Resultados

Cuánto ocupa el fondo

Instantánea del inventario en inactividad (serie 1):

	Antes	Después	Cambio
Working set total, MB	3 841	1 868	−51 %
Private bytes totales, MB	1 524	660	−57 %
Memoria disponible, MB	5 490	6 518	+1 028

Serie 2: memoria ocupada 3 017 → 1 538 MB, disponible 5 174 → 6 653 MB, volumen de confirmaciones 2 617 → 1 249 MB. La dirección coincide en ambas series: los componentes en segundo plano mantienen aproximadamente la mitad de la memoria ocupada de este perfil.

Estructura de la memoria ocupada

En el estado «después», la memoria se distribuía así (working set totales, serie 1):

shell (explorador, DWM, búsqueda en el menú «Inicio», nodo de sesión) — unos 640 MB;
servicios en segundo plano — unos 640 MB (57 servicios en 39 procesos host);
componente web de búsqueda — unos 320 MB;
pools del kernel — unos 167 MB, de los cuales unos 76 MB los ocupan los pools del registro.

El working set de un proceso no es igual a la memoria liberable: incluye páginas compartidas (código de bibliotecas del sistema, datos comunes) que se contabilizan en cada proceso simultáneamente. En el estado «después» de la serie 1, la suma del working set de 75 procesos era de 1 868 MB, y la suma de private bytes — 660 MB; en los arranques de control del experimento con desactivaciones puntuales, el working set total era de 2 036 MB. Los procesos de interfaz más grandes (serie 2):

Proceso	Working set, MB	Private, MB
`SearchHost.exe` (búsqueda)	187	80
`explorer.exe` (explorador)	167	36
`StartMenuExperienceHost`	107	24
`dwm.exe` (DWM)	73	34

En el estado «después», la lista standby era de 711 MB. No es memoria perdida, sino caché: standby ya está contabilizada en la «disponible», y Windows reutiliza estas páginas al instante cuando una aplicación requiere memoria.

Experimento: terminar procesos del shell

Tras detener SearchHost.exe y StartMenuExperienceHost (serie 2):

ambos procesos se reiniciaron automáticamente en unos 20 segundos con nuevos identificadores; a los 40 segundos seguían funcionando;
el volumen de confirmaciones no disminuyó, sino que creció en 12,6 MB (de 1 386,9 a 1 399,5 MB) — el reinicio de los procesos del shell genera por sí mismo nuevo trabajo;
el aumento breve de la memoria «disponible» en 93 MB no es un ahorro: los procesos objetivo volvieron, el commit aumentó.

Terminar el explorador en una medición aparte (serie 1) tampoco dio un crecimiento estable de la memoria libre: en esa ventana la memoria libre incluso disminuyó en 97 MB con un aumento de standby de 13 MB — las páginas descargadas permanecen en el sistema como caché, y el shell y los procesos asociados siguen funcionando.

Conclusión del experimento: la terminación forzosa de procesos del sistema no libera memoria. Windows reinicia los componentes del shell automáticamente, y en lugar de un ahorro obtienes una carga adicional.

Limpieza del working set y de la lista standby

La mecánica está documentada por Microsoft. La descarga de páginas del working set (por ejemplo, con la función EmptyWorkingSet o SetProcessWorkingSetSize con tamaño «vacío» — precisamente las que usan los «optimizadores de RAM») traslada las páginas a un estado transitorio: permanecen en caché en la RAM hasta que se necesiten de nuevo o sean reutilizadas. El siguiente acceso del proceso a esa página es un error de página suave y el retorno al working set.

Por eso la limpieza del working set cambia la cifra de «libre» en los contadores, pero no crea memoria físicamente disponible: las páginas no desaparecen a ningún lado, y el acceso repetido a ellas se vuelve más costoso. La limpieza de la lista standby carece de sentido por la misma razón: standby es memoria ya disponible para el sistema. En nuestras mediciones no había pressure sobre la memoria en ninguno de los dos estados (los hard faults permanecían bajos), por lo que la descarga adicional no mejoraba nada.

Nuestro criterio a partir de este experimento: el resultado de «liberar memoria» debe evaluarse por el commit, los errores de página y las latencias al reutilizar la memoria, y no por el crecimiento breve de la línea «libre».

Desactivaciones puntuales: el aumento honesto

Sobre el estado «después» desactivamos nueve autologistas de diagnóstico ETW y cuatro servicios en segundo plano (notificaciones, copia de instantáneas, orquestador de actualizaciones) y comparamos el resultado con cuatro arranques de control:

Métrica	Arranques de control	Con el paquete	Diferencia
Memoria libre, MB	6 664–6 674	6 696	+22…+30
Nonpaged pool, MB	69,8–71,8	58,7	−11…−13
Working set total, MB	2 036	1 959	−77
Rendimiento de las pruebas	sin cambios	sin cambios	—

Solo los autologistas dieron −13,2 MB de nonpaged pool (medido aparte). Importante: la suma del working set de los componentes desactivados según el inventario era de unos 78 MB, y el aumento real de memoria libre — +22–30 MB. La diferencia surge porque parte de lo «desactivado» no estaba en ejecución de todos modos. Esta es la frontera honesta de las desactivaciones puntuales sin eliminar componentes del sistema; de forma colateral, ese mismo paquete redujo la actividad en segundo plano de la inactividad en otro 24 %.

Los parámetros de registro del administrador de memoria (tamaños de pools, de la caché del sistema y similares) en este experimento ni siquiera se consideraron como fuente de ganancia: su lectura y su utilidad práctica se analizan en «Memory Manager y la caché del sistema» — no tienen un beneficio confirmado para liberar RAM.

Lo que está confirmado

Reproducido (dos series): desactivar componentes en segundo plano libera 1,0–1,5 GB de memoria disponible; el working set total se redujo en un 51 % (serie 1), la memoria ocupada — en un 49 % y el volumen de confirmaciones (commit) — en un 52 % (serie 2).
Medido: el reinicio automático de los procesos del shell detenidos dentro de los 20 segundos; el commit no disminuye con ello (en nuestro experimento creció en 12,6 MB).
Medido: terminar el explorador no da un crecimiento estable de la memoria libre; las páginas descargadas permanecen en standby.
Documentado: la descarga de páginas del working set las traslada a un estado transitorio, en caché en la RAM; la memoria standby se contabiliza en la disponible.
Medido: las desactivaciones puntuales sobre un sistema optimizado dan +22–30 MB de memoria libre con un rendimiento invariable; la suma del working set de lo desactivado no es igual al aumento de lo libre.

Lo que no está confirmado

Los «optimizadores de RAM» de terceros no se probaron directamente: se verificó la mecánica (limpieza del working set) sobre la que se construyen.
La desactivación del pagefile no se midió; solo se sabe que el pagefile es necesario para el crash dump y el límite de confirmaciones de memoria.
El traslado de los valores a máquinas con otro volumen de RAM, otras builds y hardware físico.
La estabilidad del ahorro en ventanas largas: las mediciones se realizaron en inactividad estable.

Limitaciones

Máquina virtual con 8 GB de RAM: las cifras absolutas están ligadas a esta configuración; un perfil con un mayor volumen de componentes en segundo plano liberará más, un sistema «silencioso» — menos.
La suma del working set por procesos sobreestima la huella única debido a las páginas compartidas; por eso precisamente incluimos los private bytes al lado.
La capa de medición ocupaba por sí misma una memoria notable (hasta cientos de MB de working set en mediciones concretas) — las cifras del estado incluyen la presencia de la medición.
No había presión de memoria en el experimento (hard faults bajos), por lo que no comprobamos si el ahorro reduce el thrashing en condiciones de escasez de RAM.
Parte de la liberación está relacionada con la desactivación de componentes de protección de Microsoft Defender — es un compromiso con la seguridad, y no memoria obtenida gratis.

La investigación y las herramientas utilizadas pertenecen al desarrollador de BoosterX, y BoosterX es un optimizador de Windows, por lo que medir el efecto de la optimización es su interés directo. La metodología y los límites de aplicabilidad se describen arriba, y las conclusiones se pueden verificar con los datos abiertos y las fuentes públicas enumeradas. Los resultados negativos sobre los métodos populares de «liberar memoria» se publican al mismo nivel que los positivos.

Conclusión práctica

Lo que realmente libera memoria, según este experimento:

cerrar aplicaciones no utilizadas — sus private bytes se liberan por completo;
desactivar componentes en segundo plano realmente innecesarios — el efecto conjunto medido se describe en «Inactividad silenciosa»; es la única forma de las comprobadas que dio gigabytes, y su precio es la pérdida de las funciones correspondientes;
evaluar el resultado por el commit y la memoria disponible (Task Manager → «Rendimiento» → «Memoria»), y no por la línea «libre».

Lo que no funciona:

la terminación forzosa de procesos del sistema: Windows los reinicia en segundos, el commit crece;
los «optimizadores de RAM» y la limpieza de standby: las páginas descargadas permanecen en la RAM como caché, y devolverlas al trabajo cuesta errores de página suaves;
los parámetros de registro del administrador de memoria.

La memoria standby no es un problema, sino el trabajo de la caché: la «disponible» ya la incluye. Deja el pagefile bajo la gestión del sistema: es necesario para el límite de confirmaciones de memoria y los volcados de fallos.

Restauración del estado

Los experimentos se realizaron en una máquina virtual aislada sobre ramas de estado de prueba; tras las mediciones, las ramas de prueba se restablecieron y la máquina se devolvió a su estado inicial. El artículo no recomienda terminar procesos del sistema ni desactivar el pagefile, por lo que no se requiere una acción de restauración aparte en el equipo del usuario.

Fuentes primarias públicas

Microsoft: Working Set — composición del working set, descarga de páginas, páginas transitorias en caché en la RAM, y las funciones EmptyWorkingSet/SetProcessWorkingSetSize; verificado el 2026-09-20.
Microsoft: EmptyWorkingSet — API utilizada por las utilidades de «optimización de memoria»; verificado el 2026-09-20.
Microsoft: About Memory Management — modelo de memoria virtual y páginas compartidas; verificado el 2026-09-20.
Microsoft: Introduction to the page file — commit charge, límite de confirmaciones y el papel del pagefile; verificado el 2026-09-20.
Memory Manager y la caché del sistema — investigación de los parámetros de registro del administrador de memoria.
Inactividad silenciosa: el fondo de Windows antes y después de la optimización — protocolo de mediciones y el resto de métricas de este mismo experimento.
Cómo investigamos Windows — niveles de evidencia y reglas de medición.

Historial de cambios

2026-09-20: las cifras se ajustaron a las tablas de las series: el «después» de la serie 1 — 1 868/660 MB, se precisó la atribución de porcentajes por métricas y series; el descargo de responsabilidad sobre el conflicto de intereses se reforzó hasta la formulación completa.
2026-09-20: primera publicación — inventario de memoria en dos series, experimentos negativos con la terminación de procesos y la limpieza, el aumento honesto de las desactivaciones puntuales.