Diagnosticar fallos de caché y evitar pérdida de datos en Windows

Cuando Windows empieza a ir a tirones, tarda siglos en abrir aplicaciones o se queda sin memoria aparentemente “de la nada”, muchas veces el origen del problema está en cómo el sistema gestiona su caché (tanto de archivos como de memoria) y en cómo determinadas aplicaciones usan esa memoria. Entender lo que ocurre por debajo es clave para evitar cuelgues, pérdidas de rendimiento e incluso riesgos de pérdida de datos en determinadas cargas de trabajo.

La buena noticia es que Windows incluye contadores de rendimiento, herramientas de diagnóstico y ajustes específicos que permiten detectar comportamientos anómalos de la caché, identificar fugas de memoria y afinar parámetros críticos como el umbral de páginas desfasadas en escrituras remotas. Con un poco de método y las utilidades adecuadas, es posible localizar qué componente se está “comiendo” la memoria y tomar medidas preventivas.

Qué es la caché en Windows y por qué puede dar problemas

La caché, tanto en hardware como en software, es básicamente un almacén rápido donde se guardan datos para acelerar accesos posteriores. En procesadores y memoria hablamos de cachés L1, L2 o L3; en sistemas operativos como Windows, la caché de archivos del sistema guarda datos de disco que es probable que se vuelvan a leer, reduciendo accesos lentos al almacenamiento físico.

En el caso concreto de Windows, la caché de archivos del sistema está gestionada por el administrador de caché, que decide qué páginas mantener en memoria, qué descartar y cuándo liberar espacio. Bajo ciertas cargas de trabajo (millones de archivos, accesos muy aleatorios, servidores con clientes remotos muy rápidos, etc.), esa caché puede crecer demasiado y dejar al sistema prácticamente sin memoria disponible.

Cuando la caché acapara buena parte de la RAM física y no se libera a tiempo, el resultado es un equipo lento, con procesos que tardan en responder y, en casos extremos, con errores derivados de falta de memoria virtual. Esto no solo afecta al rendimiento: si el almacenamiento es lento y hay mucha escritura pendiente en caché, pueden aparecer timeouts en conexiones remotas o retrasos enormes al volcar los datos al disco.

En otros escenarios, el problema no es la caché de archivos del sistema, sino fugas de memoria en procesos concretos. Estas fugas se manifiestan como un consumo creciente y sostenido de memoria virtual (tamaño de confirmación), sin que el proceso la libere nunca, lo que termina agotando los recursos del sistema y dispara eventos de advertencia como el identificador 2004 del detector de agotamiento de recursos.

A nivel web, también existe el concepto de fallo de caché: cuando una aplicación (por ejemplo, un WordPress con plugins de caché) solicita datos que no están en la caché y tiene que ir a la base de datos o al origen. Estos fallos incrementan la latencia, ralentizan las páginas y, si son frecuentes, tiran por tierra buena parte de las ventajas del caché.

Contadores clave para vigilar la caché de archivos en Windows

Antes de Windows Server 2012 existían dos problemas típicos que hacían que la caché de archivos creciera de forma descontrolada hasta agotar prácticamente la memoria disponible. Aunque la arquitectura se ha mejorado en versiones recientes, sigue siendo útil saber qué contadores observar para detectar situaciones similares.

Los contadores de rendimiento más importantes para monitorizar estos escenarios son:

• Memory\Long-Term Average Standby Cache Lifetime (s): tiempo medio de vida a largo plazo de la memoria en espera. Si este valor se mantiene por debajo de 1800 segundos (30 minutos), indica que las páginas en espera se reciclan demasiado rápido porque el sistema va justo de memoria.
• Memory\Available (Bytes / KBytes / MBytes): refleja la memoria disponible en el sistema. Valores persistentemente bajos combinados con un gran uso de caché de sistema suelen ser una señal de alerta.
• Memory\System Cache Resident Bytes: indica cuánta memoria física está ocupando la caché de archivos del sistema. Cuando este valor es una fracción muy grande de la RAM total y la memoria disponible es baja, la caché puede estar sobredimensionada.

Si observas que Memory\Available es bajo y, al mismo tiempo, Memory\System Cache Resident Bytes ocupa una parte considerable de la RAM, el siguiente paso es averiguar en qué se está usando exactamente esa caché. Para ello, una herramienta fundamental es RAMMap.

Usar RAMMap para identificar qué llena la caché de archivos

RAMMap es una utilidad de Sysinternals que muestra de forma gráfica y detallada en qué se está utilizando la memoria física. Entre otras cosas, permite ver cuántas páginas están asignadas a metarchivos NTFS, a archivos mapeados, a caché de sistema, etc.

Uno de los problemas históricos en servidores muy cargados era la acumulación masiva de páginas de metarchivo NTFS en la caché. Esto se daba sobre todo en equipos con millones de archivos y accesos intensivos: el almacenamiento de datos de metarchivos (información de estructura del sistema de archivos, no el contenido en sí) no se liberaba correctamente de la memoria caché, disparando el consumo.

En la salida de RAMMap, este escenario se detecta por un número muy alto de páginas de metarchivo activas. Visualmente se aprecia cómo esa categoría se lleva un porcentaje desproporcionado de la memoria. Históricamente se mitigaba con herramientas como DynCache, que ajustaban los límites de la caché del sistema para contener el problema.

A partir de Windows Server 2012 la arquitectura interna de la gestión de caché se rediseñó precisamente para que este tipo de crecimiento descontrolado de los metarchivos no se produjera, por lo que en sistemas modernos no debería aparecer… aunque sigue siendo útil conocer el síntoma para diagnosticar comportamientos parecidos.

Otro escenario que RAMMap ayuda a destapar es cuando la caché de archivos del sistema contiene un gran volumen de archivos asignados a memoria. En la herramienta se observa como un número elevado de páginas activas de archivos mapeados, muchas veces asociado a aplicaciones que abren numerosos ficheros grandes.

Impacto de FILE_FLAG_RANDOM_ACCESS y buenas prácticas de aplicaciones

Un patrón típico de sobredimensionamiento de la caché de archivos se da cuando una aplicación abre muchísimos ficheros grandes usando CreateFile con la marca FILE_FLAG_RANDOM_ACCESS. Esta bandera es, básicamente, una pista para el administrador de caché: le indica que mantenga las vistas mapeadas en memoria el máximo tiempo posible, porque se espera un acceso muy aleatorio a los datos.

Al marcar FILE_FLAG_RANDOM_ACCESS, el administrador de caché intenta conservar los datos en memoria hasta que el administrador de memoria declare una condición de baja memoria. Además, esa misma marca deshabilita la lectura anticipada (prefetch) de datos de archivo, ya que en teoría los accesos no seguirán un patrón secuencial.

Este comportamiento, combinado con muchas aperturas de archivos grandes y accesos realmente aleatorios, puede hacer que la caché del sistema crezca en exceso. Aunque Windows Server 2012 y versiones posteriores introducen mejoras en el recorte de espacios de trabajo, el verdadero responsable de corregirlo es el proveedor de la aplicación.

La recomendación fuerte para los desarrolladores es evitar FILE_FLAG_RANDOM_ACCESS salvo que sea estrictamente necesario. Como alternativa, pueden acceder a los archivos con una prioridad de memoria baja, de manera que las páginas usadas puedan expulsarse del espacio de trabajo de forma más agresiva cuando se necesite memoria para otros procesos.

Esta prioridad de memoria baja se puede configurar mediante la API SetThreadInformation. Con ella, los hilos que realizan los accesos a disco pueden marcarse como de baja prioridad de memoria, lo que reduce el impacto de su actividad en el conjunto de trabajo general del sistema.

En Windows Server 2016 el administrador de caché va un paso más allá y, a la hora de recortar, ignora la sugerencia de FILE_FLAG_RANDOM_ACCESS, tratando esos archivos igual que cualquier otro en términos de recorte de caché (aunque sigue deshabilitando el prefetch, tal y como indica la marca). Esto mitiga en parte el problema, pero no elimina el riesgo de una caché desproporcionada si la aplicación sigue abriendo muchos ficheros con esa bandera y realiza accesos muy dispersos.

Umbral de páginas desfasadas en archivos remotos y riesgo de timeouts

Otro problema específico que puede repercutir tanto en rendimiento como en la estabilidad de las conexiones remotas aparece cuando un sistema recibe escrituras muy rápidas desde un cliente remoto hacia un almacenamiento de destino relativamente lento.

En versiones anteriores a Windows Server 2016, cuando se alcanzaba el umbral de páginas desfasadas (dirty pages) en caché para un archivo remoto, las escrituras adicionales se gestionaban como si fueran escrituras simultáneas. Esto provocaba el vaciado masivo de datos al disco, y si el almacenamiento no daba la talla, se producían grandes latencias e incluso tiempos de espera agotados (timeouts) en las conexiones de red.

Para abordar este problema, Windows Server 2016 introduce un umbral independiente de páginas desfasadas para escrituras remotas. Cuando ese umbral se supera, el sistema realiza un vaciado en línea (flush) al disco, es decir, va escribiendo los datos de forma progresiva para evitar picos enormes que saturen el subsistema de almacenamiento.

Este mecanismo puede causar alguna ralentización puntual durante periodos de escritura muy intensiva, pero a cambio reduce muchísimo la probabilidad de que un cliente remoto experimente un timeout por exceso de datos pendientes de escribir.

El valor por defecto de este umbral remoto es de 5 GB por archivo. Dependiendo de la configuración de hardware y de la carga de trabajo, puede ser conveniente ajustarlo: en algunos entornos un límite mayor da mejor resultado, en otros es preferible mantener el valor predeterminado.

Cómo ajustar RemoteFileDirtyPageThreshold en el Registro

Si el límite de 5 GB no encaja con tus necesidades, puedes modificar el umbral remoto de páginas desfasadas mediante el Registro de Windows. Este ajuste se controla con el valor RemoteFileDirtyPageThreshold.

• Ruta de la clave: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
• Tipo: DWORD
• Nombre del valor: RemoteFileDirtyPageThreshold
• Datos: número de páginas, donde cada página equivale al tamaño de página gestionado por el administrador de caché (normalmente 4096 bytes).

Para calcular el valor correcto, debes convertir la cantidad deseada de bytes en número de páginas. Por ejemplo, si quieres fijar el umbral en 10 GiB, primero calculas 10 737 418 240 bytes / 4096 = 2 621 440 páginas; ese es el valor decimal que debes introducir en el DWORD.

Las recomendaciones generales indican trabajar en un rango seguro entre 128 MB y hasta el 50% de la memoria disponible, siempre traducido a páginas. Lo ideal es ir incrementando el límite en pasos de 256 MB, midiendo el rendimiento tras cada cambio, hasta encontrar el punto de equilibrio.

Ten en cuenta que cualquier modificación de RemoteFileDirtyPageThreshold requiere reiniciar el equipo para que el nuevo valor surta efecto. Sin el reinicio, el sistema seguirá utilizando el umbral que estuviera activo anteriormente.

También es posible deshabilitar por completo este umbral estableciendo el valor en -1, pero no es recomendable: al hacerlo, vuelve a existir el riesgo de que grandes ráfagas de escrituras remotas llenen la caché con páginas desfasadas y desencadenen tiempos de espera y problemas en las conexiones de los clientes.

Detección de agotamiento de memoria y eventos 2004 en Windows

Además de los mecanismos de caché, Windows dispone de un detector de agotamiento de recursos que vigila el uso de la memoria virtual. Cuando se alcanza una condición de memoria virtual baja, se registra el evento 2004 en el registro de sistema, con información detallada sobre los procesos que más memoria están consumiendo.

Un ejemplo típico de evento 2004 (Microsoft-Windows-Resource-Exhaustion-Detector) incluye un mensaje indicando que Windows ha diagnosticado correctamente una condición de memoria virtual baja y lista los programas que han consumido más memoria en ese momento, con su nombre de ejecutable, PID y número de bytes comprometidos.

Es importante entender que la columna de memoria que se ve por defecto en muchas vistas del Administrador de tareas no es la más relevante para este tipo de diagnóstico. Suele reflejar la memoria privada respaldada por RAM (el conjunto de trabajo), pero lo que interesa aquí es el uso de memoria virtual total que el sistema ha comprometido para cada proceso.

La métrica que hay que vigilar en estos casos es el tamaño de confirmación (Commit Size), que representa la memoria virtual que Windows reserva para el proceso, independientemente de si está respaldada por RAM física o por archivo de paginación. Cuando el commit total del sistema se acerca al límite, se disparan los eventos 2004.

Este comportamiento puede darse tanto con procesos de Microsoft como con aplicaciones de terceros. Para procesos propios de la plataforma, suele haber símbolos públicos que permiten profundizar más en el análisis; en el caso de software de terceros, a menudo hay que recurrir al proveedor para obtener información adicional si las pilas de llamadas no muestran funciones con nombre claro.

Uso de VMMap para clasificar el tipo de memoria que se está filtrando

Cuando se sospecha de una pérdida de memoria (memory leak), el primer paso es determinar qué tipo de memoria está creciendo sin control. Para ello, VMMap es una herramienta muy útil, ya que desglosa el uso de memoria de un proceso en categorías: datos privados, montones, imágenes, pilas, etc.

Si la fuga se produce en memoria de asignación virtual genérica, en VMMap se verá como un incremento sostenido en la categoría de datos privados. Esa memoria no está asociada directamente a un montón gestionado, sino a reservas y compromisos de espacio de direcciones que el proceso no libera.

Cuando se dispone de un volcado de memoria del proceso, se puede usar WinDbg para ejecutar el comando !address -summary. En el resumen, la memoria de asignación virtual problemática suele aparecer bajo la categoría <unknown>, indicando grandes regiones de memoria no clasificadas que ocupan una parte muy significativa del espacio ocupado.

Si la fuga está relacionada con el montón (heap) del proceso, en VMMap se verá reflejada en las categorías Heap. El uso de memoria de montón irá creciendo de manera constante conforme pasa el tiempo, sin retornos apreciables.

De nuevo, con un volcado y !address -summary en WinDbg, en estos casos se observará un porcentaje muy alto etiquetado como Heap32 o Heap64, dependiendo de la arquitectura del proceso. El resto de categorías (imágenes, pilas, otros) representarán una fracción mucho menor del uso total.

Identificar correctamente si estamos ante fugas de asignación virtual o de montón es crucial, porque determina qué tipo de seguimiento debemos activar a continuación y qué herramientas específicas nos ayudarán a encontrar el componente responsable.

Recopilar trazas con WPR para memoria de asignación virtual

Una vez claro que hay una fuga de asignación virtual, el siguiente paso es recopilar datos reproducibles que permitan ver quién está haciendo esas reservas. Para ello puede usarse Windows Performance Recorder (WPR), incluido de forma nativa desde Windows 10 y Windows Server 2016.

El procedimiento básico consiste en iniciar una sesión de trazado enfocada a asignación virtual, dejar que el proceso se comporte de forma natural mientras su uso de memoria crece, y detener la captura cuando se haya acumulado suficiente información sobre las asignaciones.

C:\>wpr -start VirtualAllocation

Con la traza en marcha, se monitoriza el crecimiento del consumo de memoria mediante el tamaño de confirmación del proceso, ya sea con el Administrador de tareas, el Monitor de recursos o herramientas similares. Lo bueno de este perfil de WPR es que, al centrarse solo en asignación virtual, el archivo .etl resultante no suele crecer demasiado, por lo que puede mantenerse activo varios minutos.

C:\>wpr -stop virtalloc.etl

Ese archivo virtalloc.etl contendrá los eventos de asignación virtual que luego se analizarán con Windows Performance Analyzer (WPA), permitiendo ver qué funciones y módulos están detrás de las reservas de memoria que no se liberan.

Recopilar trazas con WPR para memoria de montón

En el caso de fugas asociadas al montón del proceso, el siguiente paso es recopilar trazas específicas de heap. Para ello, WPR puede configurarse para registrar eventos de heap del ejecutable objetivo, normalmente mediante una entrada en el Registro que habilite el seguimiento.

Se puede modificar el Registro manualmente o usar WPR para configurar el binario de destino. Por ejemplo, para habilitar trazado de montón para VirtMemTest32.exe, se lanza desde un símbolo de sistema con derechos de administrador:

C:\>wpr -heaptracingconfig VirtMemTest32.exe enable

Este comando crea una clave de configuración bajo HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\VirtMemTest32.exe, con un valor DWORD llamado Tracing Flags establecido normalmente a 1, activando así el seguimiento de heap para ese ejecutable.

Tras la fase de diagnóstico, es importante desactivar de nuevo el seguimiento, ya sea eliminando la clave o poniendo el valor Tracing Flags a 0, para evitar una sobrecarga innecesaria en tiempo de ejecución.

Con la configuración aplicada, la captura del seguimiento de montón se realiza con:

C:\>wpr -start Heap

De igual forma que con la asignación virtual, se deja que el proceso funcione unos minutos mientras se observa el tamaño de confirmación. Dado que solo se registran eventos de heap, el tamaño de la traza es manejable en la mayoría de escenarios.

C:\>wpr -stop Heap.etl

El resultado es un archivo Heap.etl con los eventos de asignación y liberación de montón, que después se estudiará con WPA para localizar las pilas de llamadas responsables de las fugas.

Análisis de trazas con Windows Performance Analyzer (WPA)

El último eslabón del proceso de diagnóstico es abrir las trazas .etl con Windows Performance Analyzer, una herramienta incluida en el Windows Performance Toolkit, que a su vez forma parte del ADK (Assessment and Deployment Kit).

Antes de empezar a examinar los datos, es esencial configurar correctamente las rutas de símbolos, de manera que las pilas de llamadas se resuelvan con nombres de funciones legibles. En WPA, esto se hace desde el menú Trace > Configure Symbol Paths, añadiendo una ruta similar a:

srv*C:\LocalPubSymbols*https://msdl.microsoft.com/download/symbols

Con los símbolos configurados, se cargan a través del menú de símbolos y se abre el archivo .etl correspondiente. En el caso de fugas de asignación virtual, se debe reproducir una vista centrada en el proceso problemático, asegurándose de que la columna Commit Stack queda a la izquierda de la línea dorada o amarilla de la cuadrícula.

Al expandir las pilas de commit, se identifican las funciones que originan las asignaciones virtuales que no se liberan. El módulo que aparece inmediatamente por encima de la función de asignación en la pila suele ser el responsable lógico que está pidiendo memoria repetidamente.

Para fugas de montón, el enfoque es similar, pero la vista debe incluir columnas como Handle y Stack a la izquierda de la línea de división. Explorando esas pilas se descubren las funciones que realizan las llamadas de reserva en el heap sin la correspondiente liberación.

En ambos casos, una vez identificado el módulo y la función implicada, el siguiente paso suele ser revisar actualizaciones del software, parches conocidos o, si es una aplicación propia, depurar y corregir el patrón de asignación para eliminar la fuga.

Fallos de caché a nivel de aplicaciones web y cómo reducirlos

Más allá del sistema operativo, el concepto de fallo de caché es muy relevante en aplicaciones web como WordPress. Un fallo de caché se produce cuando los datos solicitados por el sistema o la aplicación no están disponibles en la caché y hay que ir a buscarlos a la base de datos o al origen.

En contraposición, un acierto de caché (cache hit) se da cuando el contenido se recupera directamente de la caché, ya sea en memoria, en disco o a nivel de servidor. Cuantos más aciertos de caché haya, más rápidas serán las respuestas; cuantos más fallos, mayor será la latencia y más carga soportarán el servidor y la base de datos.

Las causas típicas de un fallo de caché incluyen que los datos nunca se hayan almacenado inicialmente, que hayan sido desalojados por falta de espacio, que se haya purgado la caché manual o automáticamente, o que haya caducado la política de tiempo de vida (TTL) asociada a esos datos.

Cuando se produce un fallo de caché, el sistema suele hacer un segundo intento, esta vez contra el origen de los datos. Si el recurso solicitado existe, se lee de la base de datos o del almacenamiento principal, se devuelve al cliente y, en la mayoría de casos, se almacena de nuevo en la caché para acelerar futuras peticiones.

El problema es que cada vez que hay que bajar en la jerarquía (de caché L1 a L2, de L2 a memoria principal, de memoria a disco, etc.) se introduce una penalización por fallo. En sitios muy concurridos, un exceso de estos fallos degrada notablemente los tiempos de respuesta.

Estrategias prácticas para disminuir fallos de caché en entornos web

Para reducir la frecuencia de los fallos de caché en un sitio web, el objetivo es conseguir que los datos relevantes permanezcan en la caché el mayor tiempo posible, siempre equilibrando rendimiento y frescura del contenido.

Una táctica básica es establecer una vida útil (TTL) adecuada para la caché. Cada vez que se purga, los datos deben recalcularse y escribirse de nuevo tras la siguiente solicitud, lo que implica fallos iniciales. Extender el TTL cuando el contenido no cambia con frecuencia ayuda a que haya menos invalidaciones y, por tanto, menos misses.

En proveedores gestionados, es habitual que solo se purguen secciones concretas de la caché al detectar cambios relevantes. Por ejemplo, plugins como los usados por algunos hostings especializados solo limpian la caché de la entrada modificada o de determinadas áreas del sitio, en lugar de arrasar toda la caché del servidor.

Otra forma de recortar fallos de caché es aumentar el tamaño de la propia caché o la memoria RAM disponible. A mayor capacidad, más objetos se pueden mantener simultáneamente sin expulsar los menos utilizados, reduciendo el número de desalojos forzados.

Esto tiene un coste, ya que incrementar la RAM o contratar planes de hosting escalables supone un gasto adicional, pero en proyectos con mucho tráfico puede ser una de las optimizaciones más rentables en términos de rendimiento y estabilidad.

Por último, resulta muy útil elegir políticas de reemplazo de caché acordes al patrón de acceso de la aplicación. Entre las más habituales se encuentran FIFO (First In First Out), LIFO (Last In First Out), LRU (Least Recently Used) y MRU (Most Recently Used), cada una con ventajas e inconvenientes según el tipo de carga.

Aplicar una combinación inteligente de estas políticas permite controlar qué objetos de la caché se expulsan primero cuando es necesario hacer hueco, manteniendo en memoria aquellos que son más valiosos o se usan con mayor frecuencia, incluso cuando no es viable seguir aumentando el tamaño de la caché.

En la práctica, coordinar la configuración de caché del sitio con el proveedor de alojamiento suele ser la mejor manera de ajustar TTL, políticas y capacidad, especialmente en entornos gestionados donde muchas decisiones de caché se toman a nivel de servidor.

Comprender cómo Windows gestiona la caché y la memoria, cómo diagnosticar fugas y umbrales problemáticos, y cómo optimizar el uso de caché en aplicaciones como WordPress permite evitar cuellos de botella, reducir la latencia y minimizar el riesgo de pérdida de datos o timeouts tanto en servidores locales como en entornos web exigentes.