¿Qué representa realmente el «uso de memoria» de Windows? — Cómo interpretar correctamente Working Set, Private Bytes, Commit y el archivo de paginación

En el Administrador de tareas, la «Memoria» de un proceso aparece como 1.2 GB. Sin embargo, en Process Explorer el Working Set es 1.5 GB, Private Bytes es 2.4 GB, y en VMMap el Size es todavía mayor. Al mirar todo el sistema, se muestra «Comprometido 19.6/31.8 GB».

Entonces, ¿cuántos GB de memoria está usando realmente esta aplicación?

La respuesta es que el número que hay que mirar depende de qué se quiera saber. El indicador cambia según si lo que interesa es la cantidad actualmente cargada en RAM, la cantidad asignada específicamente a ese proceso, la cantidad que el sistema promete sostener en el futuro, o simplemente el rango de direcciones virtuales reservado.

Los indicadores de memoria de Windows resultan difíciles porque todos se muestran bajo la misma palabra, «memoria», aunque en realidad miden los siguientes ejes distintos.

• Cuánto espacio de direcciones se está usando
• Cuánto Commit se está consumiendo
• Si está residente en la RAM física en este momento
• Si esa página es propia del proceso o puede compartirse
• Cuánta asignación adicional puede sostener todo el sistema

Este artículo está dirigido a quienes investigan el crecimiento de memoria de una aplicación o la falta de memoria de todo el sistema en Windows 10/11 y en las versiones actuales de Windows Server, y conecta en un solo esquema la relación entre Working Set, Private Working Set, Private Bytes, Commit, Virtual Bytes, el archivo de paginación, Available y los fallos de página.

El procedimiento para rastrear por qué no se liberan objetos de .NET se trata en detalle en «Distinguir entre espera del GC y fuga de memoria en .NET», y el manejo concreto de VMMap y Process Explorer se trata en «Práctica con Process Explorer / Handle / VMMap». Este artículo se centra en la base de todo eso: cómo leer los números del lado del sistema operativo Windows.

1. Primero, la conclusión

• Working Set son las páginas actualmente residentes en la RAM. No incluye solo páginas propias del proceso, sino también páginas que pueden compartirse con otros procesos, como el código de DLL o los archivos mapeados en memoria.¹
• Private Working Set es la parte de Working Set que en este momento pertenece exclusivamente a ese proceso. Sirve como aproximación de «la RAM que este proceso ocupa en exclusiva ahora mismo», pero no es el total de memoria que la aplicación tiene reservado.²
• Private Bytes es la cantidad de Commit propia de ese proceso. Es un indicador independiente de si en este momento está o no cargado en RAM. El campo PagefileUsage de las estructuras de la API Win32 también representa, en las versiones actuales de Windows, prácticamente el mismo Commit Charge, y no es la cantidad de bytes realmente escritos en el archivo de paginación.²
• «Comprometido X/Y» del Administrador de tareas: X es la cantidad de Commit actual de todo el sistema, e Y es el límite de Commit. X no es el uso del archivo de paginación. Y se determina, a grandes rasgos, por la suma de la RAM y el archivo de paginación.³
• Reserve y Commit son cosas distintas. Si solo se hace Reserve de una dirección virtual, únicamente se está apartando ese rango para usarlo en el futuro, y no se consume ni RAM ni límite de Commit en esa misma cantidad.⁴⁵
• Un fallo de página no siempre implica I/O de disco. Existen fallos blandos, que se resuelven dentro de la RAM, y fallos duros, que leen desde el archivo de paginación, el ejecutable, archivos mapeados en memoria, entre otros.¹⁶
• Una fuga de memoria no se juzga por un valor puntual, sino por la tendencia al repetir la misma carga. En particular, se observa si Private Bytes y su desglose siguen aumentando de forma escalonada después de terminar el proceso, sin volver al mismo estado estable.

Resumido en una frase: Working Set es «la cantidad que está ahora en RAM», Private Bytes es «la cantidad prometida específicamente a este proceso» y Commit es «la cantidad que todo el sistema ha prometido».

flowchart TB
    accTitle: Elegir el indicador de memoria principal de Windows
    accDescr: El indicador que hay que mirar cambia según si lo que se quiere saber es la cantidad residente en RAM, la Commit propia del proceso, la Commit de todo el sistema o el rango de direcciones reservado
    question["¿Qué se quiere saber con «uso de memoria»?"]
    question -->|Cantidad actual en RAM| workingSet["Working Set"]
    question -->|Compromiso propio del proceso| privateBytes["Private Bytes"]
    question -->|Compromiso de todo el sistema| systemCommit["System Commit"]
    question -->|Rango de direcciones reservado| virtualBytes["Virtual Bytes / Reserved"]
    workingSet --> resident["Residencia en RAM física"]
    privateBytes --> privateCommit["Commit propia del proceso"]
    systemCommit --> commitLimit["Comparar con el Commit Limit"]
    virtualBytes --> addressSpace["Espacio de direcciones virtuales"]

Figura 1: La observación de que «hay mucha memoria» se descompone primero en cuatro tipos de pregunta.

2. Dividir el «uso de memoria» en cuatro ejes

Antes de nada, conviene pensar la memoria de Windows no como «una sola barra», sino según cuatro ejes.

flowchart TB
    accTitle: Los cuatro ejes independientes para clasificar una página
    accDescr: El estado de la dirección virtual, el respaldo de las páginas comprometidas, la residencia en RAM física y la posibilidad de compartir con otros procesos se confirman por separado
    page["Ver una página según cuatro ejes"]
    page --> address["Estado de la dirección"]
    address --> addressValues["Free / Reserved / Committed"]
    page --> backing["Respaldo"]
    backing --> backingValues["Page-file-backed / File-backed"]
    page --> residentAxis["Residencia en RAM"]
    residentAxis --> residentValues["Resident / Not resident"]
    page --> sharing["Posibilidad de compartir"]
    sharing --> sharingValues["Private / Shareable"]

Figura 2: Incluso para una sola página, el estado de la dirección, el respaldo, la residencia y la posibilidad de compartir se determinan por separado.

Mapped no es un estado de dirección al mismo nivel que Free, Reserved o Committed, sino un tipo de región: las páginas de una vista mapeada también pueden llegar a estar Committed. Asimismo, Private no es un medio de respaldo, sino una clasificación de posibilidad de compartir. Por eso conviene leer el respaldo (Page-file-backed o File-backed) y la posibilidad de compartir (Private o Shareable) como cosas separadas.

Al combinar estos cuatro ejes, la relación entre los indicadores representativos queda así.

flowchart TB
    accTitle: Correspondencia entre tipos de página e indicadores principales
    accDescr: Muestra en qué indicador se incluyen las páginas Private residentes, las Private no residentes, las compartidas residentes y los rangos solo reservados
    privateResident["Private, Commit hecho, residente en RAM"]
    privateNonresident["Private, Commit hecho, no residente"]
    sharedResident["Página compartida, residente en RAM"]
    reservedOnly["Reserved, sin Commit"]
    workingSet["Working Set"]
    privateWorkingSet["Private Working Set"]
    privateBytes["Private Bytes"]
    virtualBytes["Familia Virtual Bytes"]
    privateResident --> workingSet
    privateResident --> privateWorkingSet
    privateResident --> privateBytes
    privateResident --> virtualBytes
    privateNonresident --> privateBytes
    privateNonresident --> virtualBytes
    sharedResident --> workingSet
    sharedResident --> virtualBytes
    reservedOnly --> virtualBytes

Figura 3: Working Set y Private Bytes cuentan conjuntos de páginas distintos, por lo que no guardan una relación simple de inclusión.

Lo importante aquí es que Working Set y Private Bytes no están en una relación simple de inclusión.

Private Bytes incluye páginas propias del proceso que ahora mismo no están residentes en RAM. Working Set, por su parte, incluye páginas compartidas que Private Bytes no cuenta, como el código de DLL o la memoria compartida. Por eso, según el proceso y el momento, Working Set puede ser mayor que Private Bytes, o viceversa.

Además, sumar sin más el Working Set de varios procesos puede contar varias veces la misma página física, por ejemplo la de una DLL compartida. «La suma del Working Set de cada proceso = la RAM en uso» no siempre es cierto.

3. Espacio de direcciones virtuales — Reserve y Commit son cosas distintas

3.1. La dirección virtual no es la dirección de la RAM física

Cada proceso tiene su propio espacio de direcciones virtuales. Los punteros que maneja una aplicación no indican directamente una posición de la RAM física; Windows usa tablas de páginas para asociar cada dirección virtual con una página física o con datos de un archivo.⁷

Por eso puede ocurrir que, incluso en un PC con 64 GB de RAM instalados, el espacio de direcciones virtuales disponible para un proceso de 32 bits sea normalmente mucho menor que esa cantidad. A la inversa, también es habitual que un proceso de 64 bits tenga un espacio de direcciones virtuales mayor que la RAM física.

3.2. Reserved solo «reserva la dirección»

MEM_RESERVE de VirtualAlloc reserva un rango continuo de direcciones virtuales para usarlo en el futuro. En esta etapa no se asocia ningún almacenamiento físico a las páginas, y tampoco es posible leer ni escribir en ese rango.⁴⁵

Por ejemplo, aunque una base de datos o un runtime haga Reserve de un rango de 8 GB de direcciones para un crecimiento futuro, eso por sí solo no implica que se hayan consumido 8 GB de RAM ni 8 GB de Private Bytes.

3.3. Committed es el estado en el que Windows promete «respaldarla cuando se necesite»

MEM_COMMIT pone esa página virtual en estado Committed y es la operación con la que Windows promete proporcionar el respaldo necesario. Si de hecho se permite leer, escribir o ejecutar se decide aparte, mediante la protección de página (PAGE_READONLY, PAGE_READWRITE, PAGE_EXECUTE, PAGE_NOACCESS, etc.); el mero hecho de tener Commit no significa «se puede leer y escribir». En el momento del Commit se contabiliza en el Commit Charge del sistema, pero es posible que la página física real no se asigne hasta el primer acceso. La primera vez que se toca una página, esta se inicializa a cero y entra en Working Set a través de un Demand-zero fault.⁵¹

Por lo tanto, aunque se diga «reservado» de manera genérica, en realidad hay tres etapas distintas.

flowchart TB
    accTitle: Las tres etapas desde Reserve hasta Commit y la residencia en RAM
    accDescr: Muestra el flujo de reservar direcciones virtuales, comprometer las páginas y, en el primer acceso, asignar la página física para entrar en el Working Set
    reserve["MEM_RESERVE: reserva el rango de direcciones"]
    reserve -.-> virtualMetric["Se refleja en Virtual Bytes"]
    reserve -->|MEM_COMMIT| committed["Commit hecho: accesible según la protección de página"]
    committed -.-> commitMetric["Se refleja en Private Bytes / System Commit"]
    committed -->|Primer acceso, Demand-zero fault| resident["Asigna la página física y queda residente en RAM"]
    resident -.-> workingSetMetric["Se refleja en Working Set"]
    committed -.->|Si no se accede| nonresident["Con Commit pero no residente"]

Figura 4: Reserve, Commit y el primer acceso son sucesos distintos, y cada uno mueve un indicador diferente.

Estas tres etapas mueven por separado los números de Virtual Bytes, Private Bytes y Working Set, respectivamente.

3.4. Por qué puede producirse un OutOfMemory aunque haya RAM libre

El éxito o fracaso de una asignación de memoria no depende solo de la RAM libre.

• Se agotó el espacio de direcciones virtuales del proceso
• No hay un rango de direcciones libres continuo del tamaño necesario
• El Commit Charge de todo el sistema alcanzó el Commit Limit
• Un Job Object, un contenedor, el runtime o una biblioteca tienen su propio límite
• Se trata de un proceso de 32 bits
• El heap nativo está fragmentado

Incluso en Windows de 64 bits, el espacio de direcciones virtuales en modo usuario de un proceso de 32 bits es normalmente de 2 GB si IMAGE_FILE_LARGE_ADDRESS_AWARE está desactivado. Una aplicación de 32 bits con ese indicador activado puede llegar a usar hasta 4 GB en Windows de 64 bits.⁸

Por eso no es ninguna contradicción que «el PC tenga 20 GB de RAM libre y aun así una aplicación de 32 bits falle en torno a 1.6 GB». No se trata de un problema de RAM, sino de que posiblemente se está topando con la fragmentación o el límite del espacio de direcciones.

4. Working Set — las páginas que están actualmente en la RAM

Working Set es el conjunto de páginas del espacio de direcciones virtuales de un proceso que están actualmente residentes en la RAM física.¹

En él se mezclan los siguientes elementos.

• El heap y la pila propios del proceso
• El código y los datos de solo lectura del EXE y las DLL
• Archivos mapeados en memoria
• Memoria compartida
• Páginas que pasaron a ser propias del proceso tras un Copy-on-write
• Páginas tocadas por el runtime o por distintas bibliotecas

4.1. Que Working Set aumente no significa que haya aumentado la asignación

Si se accede por primera vez a una página que ya tenía Commit, puede que Working Set aumente sin que Private Bytes cambie. Al mapear un archivo grande en memoria y leerlo en orden, las páginas procedentes del archivo también entran en Working Set, y es posible que Private Bytes apenas aumente.

A la inversa, cuando Windows hace Trim del Working Set en respuesta a la presión de memoria, Working Set disminuye aunque la aplicación siga reteniendo lógicamente la misma memoria. Si más tarde se vuelve a tocar, la página regresa a través de un fallo de página.

Por lo tanto, que Working Set baje no siempre significa «la aplicación liberó memoria», ni que suba significa «la aplicación reservó memoria nueva».

flowchart TB
    accTitle: Flujo típico en el que solo sube y baja Working Set
    accDescr: La misma página con Commit hecho entra en RAM en el primer acceso, queda no residente al hacer Trim y vuelve a entrar al reaccederla, mientras Private Bytes sigue contabilizándola todo el tiempo
    committed["Misma página con Commit hecho"]
    committed -->|Primer acceso| resident["Residente en RAM"]
    resident -->|Trim por presión de memoria| nonresident["No residente"]
    nonresident -->|Page Fault al reacceder| resident
    resident -.-> inWorkingSet["Incluida en Working Set"]
    nonresident -.-> outsideWorkingSet["No incluida en Working Set"]
    committed -.-> privateBytes["Contabilizada en Private Bytes mientras tenga Commit"]

Figura 5: Working Set sube y baja según el estado de residencia, pero Private Bytes no disminuye mientras el Commit de esa misma página siga vigente.

4.2. Working Set incluye páginas compartidas

Cuando 10 procesos comparten las páginas de código de una misma DLL, esa página puede aparecer en el Working Set de cada uno de ellos, pero en la RAM física puede existir una sola copia. Que la suma de los Working Set supere la RAM instalada no es, por sí solo, algo anómalo.

Si se quiere aproximar «la RAM que ocupa en exclusiva este proceso ahora mismo», hay que mirar Private Working Set. Sin embargo, esto tampoco es «toda la memoria que ese proceso tiene reservada», sino únicamente las páginas Private que están residentes en este momento.

4.3. Reducir Working Set a la fuerza no corrige una fuga de memoria

Con EmptyWorkingSet o SetProcessWorkingSetSize se pueden expulsar páginas del Working Set de un proceso. Sin embargo, esto no es una operación que libere el Commit ni las referencias en el heap. Es posible que el uso aparente de RAM baje sin que Private Bytes cambie, y que en el siguiente acceso aumenten los fallos de página.⁹

Si el número del Administrador de tareas solo baja justo después de pulsar un botón de «reducir memoria» y vuelve enseguida al reanudar la operación, puede que no se haya «liberado» memoria, sino simplemente hecho Trim del Working Set.

5. Private Bytes — la cantidad de Commit propia del proceso

Private Bytes es la cantidad de memoria virtual comprometida en exclusiva para ese proceso. Representa el Commit Charge que no puede compartirse con otro proceso, sin importar si actualmente está residente en RAM. En PROCESS_MEMORY_COUNTERS_EX de Microsoft, PrivateUsage corresponde a este valor.¹⁰²

La API Win32 también tiene un campo con un nombre confuso, PagefileUsage, pero la documentación actual lo define como «el Commit Charge de ese proceso» y explica que tiene el mismo valor que PrivateUsage. Es decir, que Private Bytes sea 2 GB no significa que se hayan escrito 2 GB en pagefile.sys.²

Entre los factores representativos que afectan a Private Bytes están los siguientes.

• El Commit del heap nativo que usan HeapAlloc, malloc, new, etc.
• Los Private Data comprometidos directamente con VirtualAlloc
• Las regiones con Commit del heap del GC de .NET
• La parte de la pila de hilo que realmente tiene Commit
• El Commit Charge de toda la vista, reservado al mapear una vista Copy-on-write (FILE_MAP_COPY)
• Los búferes Private que retienen internamente bibliotecas o SDK de dispositivos

En una vista Copy-on-write creada con FILE_MAP_COPY, cada página puede llegar a volverse Private en el futuro, así que Windows reserva, en el momento del mapeo, el Commit Charge necesario para que toda la vista pueda respaldarse con el archivo de paginación. Por eso, incluso antes de escribir de verdad y de que se cree la copia Private, tanto el System Commit como el Commit Charge del proceso (Private Bytes) pueden aumentar en la cantidad correspondiente a toda la vista.¹¹

5.1. Por qué Private Bytes no baja después de free o del GC

Aunque, desde el punto de vista de la aplicación, la memoria se «libere», es posible que el runtime o el asignador de heap no haga Decommit de esa región al SO y la conserve para reutilizarla en el futuro. En ese caso, aunque internamente la aplicación pueda reutilizarla, Private Bytes se mantiene alto.

También se mantiene alto por otras razones, como que solo sobreviva una parte de una región grande, que esté fragmentada, o que una caché o un pool se haya «calentado» hasta su límite.

Por lo tanto, que Private Bytes sea alto por sí solo no demuestra una fuga. Lo que hay que observar es lo siguiente.

1. Repetir el mismo proceso el mismo número de veces
2. Dejar el mismo tiempo de espera después del proceso
3. Comprobar si Private Bytes vuelve al mismo nivel o se estanca en un valor constante
4. Confirmar con VMMap o un volcado de heap qué región o tipo aumentó

Es decir, una comparación diferida en el tiempo.

flowchart TB
    accTitle: Por qué Private Bytes no baja después de free o del GC
    accDescr: Private Bytes cambia de forma distinta según si el asignador devuelve al SO la región que la aplicación dejó de necesitar o la conserva para reutilizarla
    release["La aplicación la deja de necesitar con free / GC"]
    release --> decision{"¿El asignador la devuelve al SO?"}
    decision -->|Decommit / Release| returned["Baja el Commit Charge"]
    returned --> lower["Private Bytes baja"]
    decision -->|La conserva para reutilizar| retained["La región sigue con Commit hecho"]
    retained --> high["Private Bytes se mantiene alto"]
    retained --> reasons["Pools, caché, fragmentación"]

Figura 6: Que algo se vuelva reutilizable dentro de la aplicación no es lo mismo que devolver el Commit al SO.

5.2. La forma más sospechosa de una fuga

Un aumento «en forma de escalera», en el que el nivel base sube en cada ciclo de carga como se muestra a continuación, merece atención.

Private Bytes
  ^
  |                    ________
  |             ______|
  |      ______|
  |_____|
  +----------------------------> Repetición del mismo proceso

Sin embargo, incluso con forma de escalera, puede tratarse solo de unos pocos aumentos por el calentamiento inicial del JIT, fuentes, decodificadores de imagen, pools de conexión o caché, y luego estabilizarse. Lo importante no es que haya aumentado, sino que no converja a un estado estable.

6. System Commit — qué es realmente «Comprometido X/Y»

«Comprometido X/Y», que se encuentra en [Rendimiento] → [Memoria] del Administrador de tareas, es un indicador de todo el sistema.

• X: System Commit Charge — La memoria comprometida que Windows promete sostener actualmente en todo el sistema
• Y: System Commit Limit — El límite de Commit que el sistema puede sostener

El Commit Limit se determina, a grandes rasgos, por la suma de la RAM física y todos los archivos de paginación. Si no hay archivo de paginación, queda algo por debajo de la RAM instalada.³⁶

flowchart TB
    accTitle: Relación entre System Commit Charge y Commit Limit
    accDescr: El Commit de cada proceso, de las secciones compartidas y del kernel forman el valor actual X, mientras la RAM física y el archivo de paginación sostienen el límite Y
    processCommit["Private Commit de cada proceso"] --> charge["System Commit Charge: X"]
    sharedCommit["Commit de secciones compartidas respaldadas por el archivo de paginación"] --> charge
    kernelCommit["Commit del kernel"] --> charge
    physicalRam["RAM física"] --> limit["System Commit Limit: Y"]
    pageFiles["Archivo de paginación"] --> limit
    charge -->|X no puede superar a Y| limit

Figura 7: X es la cantidad prometida actualmente, e Y es el límite hasta el que puede sostenerse esa promesa; no es una indicación del uso del archivo de paginación.

System Commit Charge incluye, además de la suma de Private Bytes de cada proceso, el Commit de las secciones compartidas respaldadas por el archivo de paginación y el Commit que consume el kernel. Por eso, la suma de Private Bytes por proceso por sí sola no explica por completo el valor de X.

6.1. Commit Charge no es el uso del archivo de paginación

Considere un sistema con 16 GB de RAM, 16 GB de archivo de paginación y un valor Committed de 20/31 GB.

Esos 20 GB no significan que se hayan escrito 20 GB en el archivo de paginación. Son el total que Windows promete respaldar, con RAM o con el archivo de paginación según haga falta, para páginas Private modificables, entre otras.

En ese momento coexisten estados como los siguientes.

• Gran parte está residente en RAM
• Una parte se ha retirado al archivo de paginación
• Tiene Commit pero todavía no ha recibido su primer acceso
• Se consume como Commit del lado del kernel

Si se quiere ver el uso real del archivo de paginación, hay que revisar Paging File(*)\% Usage por separado del Commit. No obstante, la propia documentación de Microsoft explica que un uso alto del archivo de paginación no siempre indica un problema de rendimiento, y que hay que valorarlo junto con si se alcanzó el Commit Limit, la Modified Page List y la I/O de paginación real.⁶

6.2. Qué ocurre al acercarse al Commit Limit

Cuando System Commit Charge alcanza el Commit Limit, ya no se pueden sostener nuevas solicitudes de Commit. Esto puede derivar en fallos de asignación de memoria en los procesos, caídas de aplicaciones o la imposibilidad de operar el sistema.³

Aquí, la X/Y del Commit importa más que la «RAM libre». Aunque se haga Trim del Working Set para crear RAM libre, si el Commit Charge en sí no disminuye, no se resuelve el hecho de haber alcanzado el Commit Limit.

6.3. Las tres funciones del archivo de paginación

El archivo de paginación cumple principalmente las siguientes funciones.

1. Ampliar el Commit Limit
2. Permitir retirar de la RAM las páginas modificadas de uso poco frecuente
3. Sostener el volcado de memoria del sistema (crash dump) según la configuración

Deshabilitar el archivo de paginación no implica una relación simple del tipo «menos I/O de disco y, por tanto, más rápido». Al contrario, puede reducir el Commit Limit, hacer que sea más fácil que queden en RAM páginas modificadas que no se usarán por ahora, y hacer imposible obtener el volcado necesario en caso de un fallo del sistema.³⁶

El tamaño adecuado del archivo de paginación no se determina solo por la RAM instalada. Microsoft también explica que no puede generalizarse, porque el System Commit Charge en el pico y el tipo de volcado de memoria necesario varían de un sistema a otro.⁶

7. El desglose de la RAM física — no juzgar solo porque Available sea bajo

La RAM física no se usa únicamente para el Working Set de los procesos de usuario.

• El Working Set de cada proceso
• La caché de archivos del sistema
• Las listas de páginas Standby, Modified, Free, Zeroed, etc.
• El Paged Pool / Nonpaged Pool del kernel
• La memoria retenida por los controladores de dispositivo
• El almacén de compresión de memoria
• Las regiones compartidas o reservadas con la GPU u otros dispositivos
• Las reservas de hardware

7.1. Available incluye caché reutilizable

Available MBytes de Windows no es simplemente la RAM completamente sin usar. Es un indicador que, además de Free y Zeroed, también incluye las páginas Standby que pueden reutilizarse en caso necesario.¹²

• Free: páginas que actualmente no están asignadas a ningún uso
• Zeroed: páginas puestas a cero para poder entregarlas de forma segura a otro proceso
• Standby: páginas que salieron del Working Set pero cuyo contenido sigue en caché en la RAM
• Modified: páginas cuyo contenido cambió y que deben escribirse en su respaldo correspondiente antes de reutilizarse

flowchart TB
    accTitle: Movimiento entre Working Set y las listas de páginas
    accDescr: Una página en uso pasa a Standby si no cambió y a Modified si cambió, y muestra el flujo de reacceso, escritura diferida y reutilización
    workingSet["Working Set: en uso"]
    workingSet -->|Retira página sin cambios| standby["Standby: candidata a reutilizar, conserva el contenido"]
    workingSet -->|Retira página modificada| modified["Modified: pendiente de escritura diferida"]
    modified -->|Escritura completada| standby
    standby -->|Reacceso| workingSet
    standby -->|Reutilización para otro fin| reused["Asignada a otro fin"]
    free["Free: sin usar"] -->|Puesta a cero| zeroed["Zeroed: lista para nueva asignación"]
    zeroed -->|Acceso tras asignar| workingSet
    standby -.-> available["Incluida en Available"]
    free -.-> available
    zeroed -.-> available

Figura 8: Available incluye no solo lo completamente libre, sino también Standby, que puede reutilizarse en caso necesario.

«Descartar toda la caché para aumentar la RAM libre» no siempre es beneficioso. Si los datos necesarios permanecen en Standby, al volver a acceder pueden regresar rápidamente al Working Set sin leer disco.

Por lo tanto, aunque el Administrador de tareas muestre poco Free, si Available es suficiente y los fallos de página duros o las esperas de disco no son un problema, puede que Windows simplemente esté aprovechando la RAM como caché.

7.2. Cuando la RAM disminuye sin que haya procesos grandes

No es raro que haya consumo de memoria que no se explica sumando el Private Working Set de cada proceso.

• Caché de archivos y archivos mapeados en memoria
• Nonpaged Pool / Paged Pool
• Páginas bloqueadas por controladores
• Páginas compartidas
• Compresión de memoria
• Asignaciones relacionadas con virtualización o GPU

En este caso, en lugar de seguir mirando la lista de procesos, conviene revisar Use Counts, Processes, Priority Summary y File Summary con RAMMap de Sysinternals. RAMMap es la herramienta oficial para desglosar la memoria física por uso, por lista de páginas y por archivo.¹³

Si solo el Nonpaged Pool sigue creciendo, es momento de sospechar de una fuga en un controlador o del lado del kernel, más que de Private Bytes de una aplicación en modo usuario.

8. Page Fault — que sean muchos no significa que haya un problema

Cuando un proceso accede a una página que no está en el Working Set actual, se produce un Page Fault. Aunque el nombre incluya «Fault», no es un fallo excepcional, sino el mecanismo normal con el que funciona la memoria virtual.¹

8.1. Fallos de página blandos (soft page faults)

Son los que se resuelven sin leer del disco.

• La página sigue en Standby o en Transition
• La misma página compartida está en el Working Set de otro proceso
• Es el primer acceso a una página con Commit y se le asigna una página en cero
• Ya está en RAM gracias a la lectura anticipada del administrador de memoria

Por eso, aunque \Memory\Page Faults/sec sea alto, eso no implica necesariamente que se esté produciendo I/O de disco o latencia.

8.2. Fallos de página duros (hard page faults)

Son los que necesitan leer el contenido desde el Backing Store en disco. El origen de la lectura no se limita al archivo de paginación.

• El código y los datos de un .exe o .dll
• Archivos mapeados en memoria
• El archivo de paginación

flowchart TB
    accTitle: Bifurcación entre fallo de página blando y duro
    accDescr: Al acceder a una página que no está en Working Set, se procesa como fallo blando si no requiere I/O de almacenamiento y como fallo duro si sí lo requiere
    access["Acceso a una página fuera de Working Set"] --> storageIo{"¿Requiere I/O de almacenamiento?"}
    storageIo -->|No: Standby, compartida, Demand-zero, etc.| soft["Fallo de página blando"]
    soft --> resident["Entra en Working Set sin leer disco"]
    storageIo -->|Sí| hard["Fallo de página duro"]
    hard --> source{"¿De dónde se lee?"}
    source --> image["EXE / DLL"]
    source --> mapped["Archivo mapeado en memoria"]
    source --> pagefile["Archivo de paginación"]
    image --> loaded["Entra en Working Set tras cargarse"]
    mapped --> loaded
    pagefile --> loaded

Figura 9: El nombre «Page Fault» por sí solo no permite saber si hay o no I/O de disco.

Microsoft menciona como contadores para medir los fallos duros a \Memory\Pages/sec, \Memory\Page Reads/sec, \Memory\Pages Input/sec, entre otros. Que estos valores sean altos no siempre significa poca memoria, así que conviene correlacionarlos con Available MBytes, la latencia de disco y el tiempo de respuesta real.⁶

8.3. No fijar un umbral uniforme

Un valor fijo del tipo «si Page Faults/sec supera 1000 es anómalo» cambia de significado según el almacenamiento, el tamaño de página, la carga de trabajo y la localidad de acceso.

En la práctica, conviene alinear lo siguiente en el mismo eje temporal.

• Memory\Available MBytes
• Memory\Pages Input/sec
• Memory\Page Reads/sec
• Read latency / Queue del disco objetivo
• Working Set y Private Bytes del proceso objetivo
• El tiempo de procesamiento, los timeouts y la respuesta de la interfaz de la aplicación

Si, al mismo tiempo que aumenta la carga, Available disminuye, Pages Input/sec y la espera de disco suben, y el tiempo de procesamiento también empeora, se reúnen indicios suficientes para sospechar de paginación por presión de memoria física.

9. Qué pantalla o herramienta usar para ver cada cosa

flowchart TB
    accTitle: Elegir la herramienta de investigación de memoria en Windows
    accDescr: La herramienta a usar depende de si el objetivo es un proceso o todo el sistema, de si es un instante o una serie temporal, y de si hay que llegar hasta lo que retiene el runtime
    question["¿Qué se quiere aislar?"]
    question --> processScope{"¿El objetivo es un solo proceso?"}
    processScope -->|Sí| processTime{"¿Un instante o una serie temporal?"}
    processTime -->|Desglose de un instante| vmmap["VMMap"]
    processTime -->|Serie temporal| perfmon["PerfMon / PowerShell"]
    processScope -->|Todo el sistema| systemView{"¿Desglose de RAM física o eje temporal?"}
    systemView -->|Desglose de RAM física| rammap["RAMMap"]
    systemView -->|Eje temporal con CPU, I/O y esperas| wpa["WPR / WPA"]
    question --> runtime{"¿Hay que llegar a lo que retiene el runtime?"}
    runtime -->|Heap de .NET| dotnet["dotnet-dump / PerfView"]
    runtime -->|Heap nativo| native["WinDbg / Application Verifier"]

Figura 10: Si primero se decide el alcance del objetivo y el eje temporal, se puede elegir la herramienta necesaria sin excesos ni carencias.

9.1. Administrador de tareas

En el Administrador de tareas conviene mirar cada pantalla por separado.

• [Procesos] o [Detalles]: la familia Working Set y la familia Commit Size de cada proceso
• [Rendimiento] → [Memoria]: In use, Available, Committed, Cached, Paged pool y Non-paged pool de todo el sistema

No se debe juzgar solo por el nombre de columna «Memoria»: haga clic con el botón derecho en el encabezado de columnas de la pestaña [Detalles] y añada las columnas necesarias, como Working Set, Peak Working Set o Commit Size. Como el nombre de las columnas varía algo según la versión de Windows y el idioma mostrado, confirme el significado de la columna antes de registrar el dato.

9.2. Obtener una serie temporal con PowerShell

Si se conoce el Id del proceso objetivo, con Get-Process se puede capturar a la vez la tendencia de Working Set, Private Bytes y Virtual Bytes.

param(
    [Parameter(Mandatory)]
    [int]$ProcessId,

    [int]$IntervalSeconds = 5,
    [int]$SampleCount = 60
)

$samples = for ($i = 0; $i -lt $SampleCount; $i++) {
    $process = Get-Process -Id $ProcessId -ErrorAction Stop

    [pscustomobject]@{
        Timestamp      = Get-Date -Format 'yyyy-MM-dd HH:mm:ss'
        ProcessId      = $process.Id
        WorkingSetMB   = [math]::Round($process.WorkingSet64 / 1MB, 1)
        PrivateBytesMB = [math]::Round($process.PrivateMemorySize64 / 1MB, 1)
        VirtualBytesMB = [math]::Round($process.VirtualMemorySize64 / 1MB, 1)
        Handles        = $process.HandleCount
        Threads        = $process.Threads.Count
    }

    Start-Sleep -Seconds $IntervalSeconds
}

$samples | Format-Table -AutoSize
$samples | Export-Csv .\memory-samples.csv -NoTypeInformation -Encoding utf8

En .NET, Process.WorkingSet64 corresponde a Working Set, PrivateMemorySize64 a Private Bytes y VirtualMemorySize64 a Virtual Bytes.¹⁴¹⁵¹⁶

En aplicaciones con varias instancias, haga el seguimiento por PID y no por nombre. En una monitorización de larga duración en la que el PID cambia con cada reinicio, hay que diseñar el registro anotando la hora de inicio o el nombre del servicio, de modo que no se confunda el objetivo.

9.3. Alinear sistema y proceso en el mismo eje temporal con PerfMon

Como mínimo, registrar a la vez lo siguiente facilita el diagnóstico.

\Process(<objetivo>)\ID Process
\Process(<objetivo>)\Working Set
\Process(<objetivo>)\Working Set - Private
\Process(<objetivo>)\Private Bytes
\Process(<objetivo>)\Virtual Bytes

\Memory\Available MBytes
\Memory\Committed Bytes
\Memory\Commit Limit
\Memory\Pages Input/sec
\Memory\Page Reads/sec
\Memory\Pool Nonpaged Bytes
\Memory\Pool Paged Bytes

Cuando hay varios procesos con el mismo nombre, o el proceso se reinicia durante la monitorización, el nombre de instancia Process(name) o Process(name#N) por sí solo no fija el objetivo. Registre también ID Process en cada muestra y use únicamente las instancias cuyo valor coincida con el PID del objetivo que está siguiendo. Si la monitorización cruza un reinicio en el que cambia el PID, registre también, por separado, el momento del cambio.

El nombre de los contadores de rendimiento de Windows puede estar localizado según el idioma mostrado. Si especifica el nombre en inglés directamente en PowerShell y no lo encuentra, añádalo desde la interfaz gráfica de PerfMon, o confirme el nombre en el entorno local con Get-Counter -ListSet *.

9.4. No confundir los roles de VMMap y RAMMap

• VMMap: descompone la memoria virtual y el Working Set de un proceso en Heap, Image, Mapped File, Private Data, Managed Heap, entre otros
• RAMMap: descompone la RAM física de todo el sistema por uso, lista de páginas, proceso y archivo

Para «por qué aumentó Private Bytes en este proceso», use VMMap; para «en qué se usa la RAM que no se explica con la lista de procesos», use RAMMap.¹⁷¹³

10. Leer los síntomas a partir de la combinación de valores

Lo más importante de esta tabla es leerla combinando valores, no de forma aislada.

11. Procedimiento práctico para investigar una fuga de memoria

11.1. Primero, defina las condiciones de reproducción y el punto estable

Con solo decir «aumenta en unos días» no se puede comparar.

• Hasta dónde incluir el calentamiento tras el arranque
• El contenido de la operación de un ciclo
• Cuántos segundos esperar después de un ciclo
• Cuántas repeticiones hacen falta para llegar al límite de la caché
• Si se puede usar la misma entrada en la versión normal y en la versión con el problema

Hay que decidirlo de antemano.

11.2. Registre el proceso y el sistema al mismo tiempo

Como mínimo, registre lo siguiente en el mismo instante.

• Working Set del objetivo
• Private Bytes del objetivo
• Virtual Bytes del objetivo
• Committed Bytes / Commit Limit del sistema
• Available MBytes
• Pages Input/sec
• Número de handles y de hilos
• Número de operaciones o de elementos procesados

Si Private Bytes del proceso está estable pero el Commit del sistema sigue aumentando, hay que ampliar el foco hacia otros procesos, el kernel, los controladores o las secciones compartidas.

11.3. Decida primero qué «dimensión» está aumentando

• Solo Working Set: páginas residentes, de origen compartido o de archivo, Trim y recarga
• Private Bytes: Commit propio del proceso
• Solo Virtual Bytes: Reserve, mapeo, fragmentación del espacio de direcciones
• Solo System Commit: incluye también otros procesos y el lado del kernel
• Nonpaged Pool: lado de controladores y kernel
• Handles / GDI / USER: fugas de recursos distintos de la memoria

Si se salta este orden y se toma un volcado directamente, se acaba leyendo una gran cantidad de información sin haber acertado con el objetivo correcto.

11.4. Pase al desglose

• Proceso nativo: VMMap, WinDbg, Application Verifier, trazas de heap
• .NET: dotnet-counters, dotnet-gcdump, dotnet-dump, PerfView
• Todo el sistema: RAMMap, PerfMon, WPR/WPA
• Pool del kernel: PoolMon, WinDbg

VMMap muestra por tipo la memoria virtual comprometida de un proceso y el Working Set asignado a cada una. El coste de la investigación posterior cambia mucho según hasta qué punto se pueda acotar el aumento de Private Bytes entre «Heap», «Private Data», «Managed Heap» o «Mapped File».¹⁷

11.5. Después de corregir, compare la tendencia en las mismas condiciones

No basta con que el valor pico difiera antes y después de la corrección. Si el valor inicial es distinto, la comparación se invierte con facilidad.

• El mismo estado de arranque
• La misma entrada
• El mismo número de operaciones
• El mismo tiempo de espera
• El mismo intervalo de muestreo

Manteniendo esto, compare el valor base y la tendencia después de cada ciclo. La prueba de que se corrigió una fuga no es que «el valor máximo se hizo más pequeño», sino que el aumento converge aunque se repita la misma carga.

12. Reformular los malentendidos habituales

Malentendido 1: La «memoria» del Administrador de tareas es todo lo que reservó la aplicación

Reformulación: compruebe de qué columna se trata. Si es de la familia Working Set, es la cantidad actualmente residente en RAM; si es de la familia Commit Size, es el Commit propio del proceso.

Malentendido 2: Private Bytes son los bytes que hay en el archivo de paginación

Reformulación: Private Bytes es el Commit Charge Private. Es una cantidad prometida en el plano lógico que incluye tanto páginas que están en RAM como páginas que, en caso necesario, se respaldarían con el archivo de paginación.

Malentendido 3: Commit X/Y es el uso del archivo de paginación / su capacidad

Reformulación: X es el Commit Charge de todo el sistema, e Y es el Commit Limit. El archivo de paginación amplía Y, pero X no se traduce directamente en el uso en disco.

Malentendido 4: Un Page Faults/sec alto significa que se está intercambiando con el disco

Reformulación: también incluye los fallos blandos. Si implica I/O de disco se confirma con Pages Input/sec, Page Reads/sec y la latencia de disco.

Malentendido 5: Poca RAM Free significa falta de memoria

Reformulación: observe Available, Standby, la paginación dura y el tiempo de respuesta. Que la RAM se llene con caché reutilizable es normal.

Malentendido 6: Haber reducido Working Set significa haber corregido una fuga de memoria

Reformulación: puede que solo se hayan expulsado páginas de la RAM. Compruebe si de verdad disminuyó Private Bytes o lo que se retiene dentro del heap.

Malentendido 7: Que Private Bytes haya aumentado confirma una fuga

Reformulación: solo se puede juzgar después de comprobar si converge al repetir la misma carga de trabajo, qué tipo de memoria aumentó, y si se trata de una caché que puede liberarse.

13. Resumen

• El «uso de memoria» de Windows no es un solo número. Hay que pensarlo por separado en espacio de direcciones, Commit, residencia en RAM y posibilidad de compartir.
• Working Set son las páginas actualmente en RAM e incluye tanto páginas Private como Shared. Private Working Set es, dentro de esas, las páginas residentes propias del proceso.
• Private Bytes es el Commit Charge propio del proceso, y no es ni la cantidad actualmente en RAM ni la cantidad realmente escrita en el archivo de paginación.
• Committed X/Y es el Commit Charge / Commit Limit de todo el sistema. El archivo de paginación sostiene principalmente el Commit Limit, la retirada de páginas modificadas y el volcado en caso de fallo.
• Una dirección virtual con Reserve, una página con Commit y una página que realmente se tocó y entró en Working Set son etapas distintas.
• Page Fault es un funcionamiento normal, y los fallos blandos no leen del disco. Los fallos duros también se producen, además de desde el archivo de paginación, desde EXE, DLL o archivos mapeados.
• Una fuga de memoria se demuestra no por el tamaño en un instante, sino por el valor base y la tendencia después de la misma carga, y por el desglose.
• Como norma básica: para el desglose de un proceso individual, use VMMap; para la RAM física de todo el sistema, RAMMap; para series temporales, PerfMon; y para el interior del runtime, herramientas de volcado específicas.

La próxima vez que note en el Administrador de tareas que «la memoria está aumentando», pregúntese primero lo siguiente.

¿Lo que está aumentando es Working Set, Private Bytes, Virtual Bytes o System Commit?

Solo con esta pregunta, el punto de partida de la investigación se vuelve mucho más preciso.

Artículos relacionados

• Distinguir entre espera del GC y fuga de memoria en .NET — Procedimiento práctico para observar, comparar y demostrar el crecimiento de memoria
• Práctica con Process Explorer / Handle / VMMap — Rastrear cuelgues, fugas y «archivo en uso» desde el estado del instante actual
• Trampas y buenas prácticas de la memoria compartida — Diseñar de forma segura la compartición entre procesos en Windows
• La escritura diferida del Cache Manager de Windows — De WriteFile hasta que llega al disco
• Causas y soluciones de las caídas tras un uso prolongado por fugas de handles en aplicaciones de Windows

Áreas de consultoría relacionadas

En KomuraSoft LLC nos encargamos de investigar la causa raíz del crecimiento de memoria en aplicaciones de Windows, la degradación de rendimiento tras un uso prolongado, el OutOfMemory en procesos de 32 bits y la falta de memoria que solo se produce en el entorno del cliente, combinando PerfMon, VMMap, RAMMap, WinDbg y herramientas de diagnóstico de .NET. No nos quedamos en un simple «hay mucha memoria»: aislamos qué región, con qué operación, por qué aumenta y desde dónde se referencia o retiene.

• Desarrollo de aplicaciones Windows
• Investigación de fallos y análisis de causa raíz
• Consultoría técnica y revisión de diseño
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿La «Memoria» del Administrador de tareas es toda la memoria que la aplicación tiene reservada?

No. El Administrador de tareas tiene varias columnas de memoria — la familia Working Set, la familia Private Working Set, Commit Size, entre otras — y su significado cambia según la pantalla y la columna que se mire. Working Set es la cantidad de páginas actualmente cargadas en RAM; Private Bytes o Commit Size es la cantidad de Commit propia de ese proceso. No interprete una sola columna de «memoria» como la capacidad total reservada por la aplicación ni como la magnitud de una fuga.

¿En qué se diferencian Working Set y Private Bytes?

Working Set es la cantidad de páginas visibles para ese proceso que están actualmente residentes en la RAM física, e incluye páginas compartidas como el código de DLL o archivos mapeados en memoria. Private Bytes es la cantidad de memoria comprometida (Commit) que usa exclusivamente ese proceso, sin importar si está residente en RAM en este momento. Por lo tanto, ambos valores no coinciden y ni siquiera guardan una relación simple de mayor o menor.

¿«Comprometido 18/32 GB» en el Administrador de tareas significa que se han escrito 18 GB en el archivo de paginación?

No es así. El lado izquierdo es la cantidad de Commit que todo el sistema tiene actualmente prometida, y el lado derecho es el límite de Commit que el sistema puede sostener. Ese límite se determina, a grandes rasgos, por la suma de la RAM y el archivo de paginación, pero no todo el total del lado izquierdo está en el archivo de paginación. Muchas páginas comprometidas están en la RAM, y algunas páginas comprometidas todavía no han recibido nunca una página física. Por otro lado, las páginas que pueden volver a cargarse desde el archivo original, como EXE, DLL o archivos mapeados en memoria, no siempre aumentan el Commit privado en la misma medida que aumentan el Working Set.

¿Puede producirse un OutOfMemory aunque haya RAM libre?

Sí, puede ocurrir. Existen condiciones de fallo de asignación distintas de la RAM física: falta de espacio de direcciones virtuales en un proceso de 32 bits, falta de un rango continuo de direcciones libres, el límite de Commit del sistema, o límites propios de un Job Object o del runtime, entre otras. En particular, un proceso de 32 bits en Windows de 64 bits que no sea Large Address Aware tiene normalmente un límite de 2 GB de espacio de direcciones virtuales en modo usuario.

¿Deshabilitar el archivo de paginación hace que Windows vaya más rápido?

En general, no se puede dar por hecho que vaya a ir más rápido. Deshabilitar el archivo de paginación reduce el límite de Commit del sistema, dificulta retirar de la RAM las páginas modificadas que no se están usando, y también afecta a la configuración del volcado de memoria en caso de fallo. El tamaño del archivo de paginación debe decidirse midiendo el Commit en el pico de uso y el volcado de memoria que se necesite, y no es una opción que deba deshabilitarse sin fundamento.

¿Un Page Faults/sec elevado significa falta de memoria?

Con ese dato solo no se puede juzgar. Los fallos de página incluyen fallos blandos, que se resuelven con páginas Standby en RAM o compartidas con otro proceso, y fallos duros, que requieren leer desde disco. No se fije solo en Page Faults/sec: revise en el mismo eje temporal Pages Input/sec, Page Reads/sec, Available MBytes, la latencia de disco y el tiempo de procesamiento.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.