Entrevista de Linux: ¿Por qué el RSS se mantiene alto después de liberar memoria?

Planteamiento y escenario aplicable

Un servicio Linux de 64 hilos que utiliza glibc malloc comienza en 800 MiB de RSS. Un lote periódico eleva el RSS a 6 GiB. Veinte minutos después de que finaliza el lote, el heap profiler de la aplicación reporta 1.1 GiB de asignaciones activas, pero el RSS permanece en 5.2 GiB. El proceso se ejecuta bajo un límite de cgroup de 8 GiB y tiene un SLO de latencia p99 de 120 ms. Explique por qué free() no garantiza que el RSS disminuya, demuestre si la brecha es una fuga, retención del asignador, fragmentación u otro mapeo, y elija una solución segura.

El recuento de hilos, los valores de memoria, el intervalo de inactividad, el límite y el SLO son suposiciones del ejercicio. Asuma un proceso nativo, glibc malloc, cgroup v2, sin procesos secundarios y un lote reproducible. Un runtime administrado agregaría su propio heap, recolector de basura y capas de asignación nativa. Esta pregunta pertenece a general porque la habilidad central es la contabilidad de procesos y el comportamiento del asignador en Linux, no la sintaxis del lenguaje de la aplicación.

El material de entrevistas actual trata explícitamente las listas libres, las clases de tamaño, la asignación local por hilo y la fragmentación como puntos de discusión en entrevistas de sistemas. La documentación de producción de Redis describe el mismo síntoma observable: eliminar datos lógicos puede dejar el RSS cerca de su pico anterior porque los fragmentos libres siguen disponibles para el asignador o las páginas aún contienen objetos activos. La documentación de Linux y glibc proporciona entonces las superficies de medición y control necesarias para una respuesta basada en evidencia. Estas fuentes establecen la relevancia y la mecánica; no demuestran que una empresa en particular use este planteamiento exacto ni que se pregunte con una frecuencia específica.

Qué evalúa el entrevistador

La primera señal es si usted separa la propiedad de la residencia. Después de free(p), quien llama ya no posee esa asignación y el asignador puede reutilizar el bloque. El contrato de asignación de C no promete un munmap, un RSS más bajo o una reclamación inmediata de páginas físicas. Decir tanto “free siempre devuelve memoria” como “free nunca devuelve memoria” pasa por alto las rutas específicas del asignador.

La segunda señal es si usted separa cuatro capas de medición:

• asignaciones activas de la aplicación;
• bytes en uso, libres, mapeados y liberables del asignador;
• mapeos del proceso y páginas residentes;
• cargos y presión a nivel de cgroup.

El RSS no es un contador del heap activo. Linux define VmRSS como RssAnon + RssFile + RssShmem. Los mapeos de archivos, la memoria compartida, las pilas, los metadatos del asignador y las bibliotecas nativas pueden ampliar la brecha. Por lo tanto, un perfil de heap y una sola lectura de top no pueden probar ni refutar una fuga.

La tercera señal es la discriminación diagnóstica. Una fuga deja las asignaciones accesibles o activas de otro modo. La retención significa que la memoria libre permanece mapeada para una reutilización eficiente. La fragmentación significa que el asignador tiene bytes libres pero no puede formar regiones liberables del tamaño de una página, a menudo porque unos pocos objetos activos anclan páginas o el espacio libre está dividido entre arenas y clases de tamaño. Estos estados pueden coexistir, por lo que el candidato necesita observaciones controladas en lugar de una etiqueta inferida a partir de una sola proporción.

Finalmente, el entrevistador busca una decisión de producción. Reducir el recuento de arenas, recortar agresivamente o reemplazar el asignador puede reducir la memoria residente mientras agrega bloqueos, fallos de página, llamadas al sistema o trabajo de CPU. Una respuesta sólida protege tanto el límite de 8 GiB como el SLO p99 de 120 ms con un canary, una reproducción de la carga de trabajo, umbrales de aceptación y reversión.

Preguntas a aclarar antes de responder

• ¿Qué asignador y versión están activos? Las variables ajustables de glibc y malloc_trim no describen jemalloc, tcmalloc, mimalloc, un asignador de runtime de lenguaje o un reemplazo enlazado estáticamente. Confirme el asignador cargado y la imagen de despliegue antes de usar sus contadores.
• ¿Qué reporta exactamente 1.1 GiB? Un perfil de heap muestreado, un contador exacto del asignador, el heap de un runtime administrado y una métrica de caché de negocio cubren bytes diferentes. Confirme si se incluyen bibliotecas nativas, pilas, mapeos directos y metadatos del asignador.
• ¿Qué componente de RSS se mantiene alto? RssAnon apunta al heap, pilas y mapeos anónimos; RssFile a mapeos respaldados por archivos; RssShmem a memoria compartida. Si el aumento no es anónimo, el ajuste del asignador es el primer paso equivocado.
• ¿La meseta se repite o sube después de cada lote idéntico? Una meseta de nivel máximo estable que atiende el siguiente lote sin otro aumento de 5 GiB sugiere reutilización. Una escalera en asignaciones activas o RSS requiere una explicación de fuga, carga de trabajo o mapeo.
• ¿Cambiaron el recuento de hilos, los tamaños de asignación o la vida útil de los objetos? Muchos hilos y liberaciones entre hilos pueden dispersar bloques entre arenas o cachés. Mezclar objetos de vida corta y larga puede dejar un sobreviviente en muchas páginas que de otro modo estarían libres.
• ¿El cgroup está realmente bajo presión? Compare memory.current, memory.events, PSI, swap y procesos vecinos. Un RSS alto con amplio margen puede ser un problema de eficiencia; eventos repetidos de memory.high o proximidad a 8 GiB hacen que el comportamiento de liberación sea operativamente urgente.
• ¿Cuándo se ejecutará el siguiente lote? Mantener 4 GiB reutilizables durante cinco minutos puede ser racional. Mantenerlo durante doce horas de inactividad bajo un límite estricto puede justificar una purga posterior al lote o un patrón de asignación diferente.
• ¿Qué presupuesto de regresión es aceptable? La solución cambia si el servicio puede gastar un 2% más de CPU pero no puede agregar 5 ms al p99, o si el costo de memoria importa más que la latencia de asignación en frío.

Marco de respuesta de 30 segundos

“free() devuelve un bloque al asignador; no promete desmapear sus páginas, por lo que el RSS puede mantenerse alto sin que haya una fuga. Alinearía la línea de tiempo de un lote y compararía perfiles de asignación activa, bytes en uso y libres del asignador, RssAnon, smaps por mapeo y uso de cgroup. Luego repetiría el lote tres veces. Si los bytes activos crecen, indica una fuga; bytes activos estables más un RSS plano que el siguiente lote reutiliza indica retención; abundantes bytes libres en el asignador con poca memoria liberable y páginas ancladas por objetos sobrevivientes indica fragmentación. Usaría malloc_trim(0) solo como un experimento canary en glibc, no como una solución general. La solución final podría ser reparar la propiedad, separar ciclos de vida, un recorte acotado post-lote, ajuste probado de arenas o un cambio de asignador, aceptado solo si una reproducción representativa de producción se mantiene por debajo del objetivo de memoria sin romper los 120 ms de p99.”

Análisis detallado paso a paso

Paso 1: Construir una línea de tiempo de memoria

Registre versión de despliegue, PID, ruta de cgroup, recuento de hilos, volumen de solicitudes y lotes, distribución de tasas de asignación, bytes activos, componentes de RSS, memory.current, memory.peak, presión y eventos de OOM. Tome muestras antes del lote, en el pico de 6 GiB, inmediatamente después de la desasignación y a lo largo de la ventana de inactividad de 20 minutos. Un PID, cgroup o carga de trabajo diferente invalida la comparación.

La primera pregunta es operativa: ¿el RSS es meramente alto, o el servicio se está acercando a un límite y reclamando bajo presión? A 5.2 GiB dentro de un límite de 8 GiB, el margen aparente es de 2.8 GiB antes de otros cargos de cgroup. Esa resta es solo una verificación de escala porque el cgroup también contabiliza memoria más allá del RSS anónimo de este proceso. Use memory.current y memory.stat para el dominio real.

Paso 2: Explicar el límite entre el asignador y el kernel

Un asignador solicita regiones más grandes al sistema operativo y las divide en fragmentos. glibc puede extender arenas ordinarias y puede crear mapeos anónimos separados para asignaciones suficientemente grandes. Cuando una aplicación libera un fragmento, el asignador primero hace que ese fragmento sea reutilizable. Puede fusionar fragmentos libres adyacentes, colocarlos en depósitos (bins) o cachés, retenerlos para evitar futuras llamadas al sistema o liberar las páginas adecuadas.

Los fragmentos grandes mapeados independientemente a menudo se pueden desmapear al liberarse. La memoria del heap ordinario es más difícil. Un bloque libre en el medio de una región no puede reducir el final del heap, y una página que contenga incluso un solo objeto activo con puntero sin procesar no se puede desmapear sin reubicar ese objeto. Los asignadores de C y C++ generalmente no pueden compactar objetos activos arbitrarios porque los punteros de la aplicación quedarían invalidados.

Esto produce tres tipos diferentes de sobrecarga:

• Fragmentación interna: una solicitud de 20 bytes puede consumir un bloque más grande alineado o de una clase de tamaño.
• Fragmentación externa o a nivel de página: existe espacio libre, pero está dividido o anclado de modo que no se pueden liberar páginas enteras.
• Retención intencional: páginas completas o parciales permanecen mapeadas porque el asignador prevé su reutilización y la liberación/readquisición tiene un costo.

Las etiquetas describen mecanismos, no conclusiones extraídas de una sola proporción de RSS / live_bytes.

Paso 3: Reconciliar las cuatro capas de medición

Comience con la contabilidad de procesos de Linux:

VmRSS = RssAnon + RssFile + RssShmem

Lea /proc/PID/status para la división general y /proc/PID/smaps_rollup para información agregada de RSS, PSS, anónima, de archivo, compartida y lazy-free. Use /proc/PID/smaps solo cuando necesite identificar los mapeos específicos anónimos o respaldados por archivos que crecieron. Un valor puntual de pmap o total de RSS es menos informativo que los deltas sincronizados.

Luego agregue las estadísticas del asignador. En glibc, mallinfo2 puede exponer bytes obtenidos a través de sbrk, bytes en fragmentos mapeados, bytes entregados a los llamadores, bytes libres y el fragmento liberable superior. Estos campos no cubren todas las fuentes de asignación y deben muestrearse de manera consistente, pero ayudan a responder si el asignador posee la mayor parte de la brecha anónima. Prefiera el perfilado nativo del asignador de la aplicación cuando proporcione datos más completos sobre memoria mapeada, activa, residente, retenida y por clase de tamaño.

Finalmente, reconcilie con cgroup v2. El cgroup incluye toda la memoria cargada en su jerarquía, por lo que puede exceder el RSS de un proceso o moverse por una razón diferente. Compare memory.current y memory.stat con la evidencia del proceso en lugar de forzarlos a ser iguales.

Paso 4: Utilizar un experimento de reutilización de tres ciclos

Ejecute el mismo lote tres veces en un canary representativo de producción con la misma concurrencia de 64 hilos y distribución de tamaño de entrada. Después de cada lote, espere los mismos 20 minutos y capture los mismos contadores.

Interprete las formas:

Una meseta no es automáticamente inofensiva. Si el siguiente lote alcanza un pico por encima de 8 GiB porque las páginas retenidas antiguas no pueden satisfacer su nueva distribución de tamaños, el servicio aún puede fallar a pesar de tener datos lógicos estables. Por el contrario, una meseta alta que satisface eficientemente la misma carga de trabajo puede ser preferible a una liberación forzada y fallos repetidos.

Paso 5: Utilizar el recorte como un diagnóstico acotado

En un canary con glibc, llame a malloc_trim(0) una vez en el límite posterior al lote y registre su valor de retorno, componentes de RSS, bytes activos del asignador, fallos de página, CPU y la latencia de las solicitudes posteriores. La interfaz de GNU intenta liberar memoria libre del heap y puede usar sbrk o madvise; no promete una reducción particular de RSS.

Si RssAnon cae sustancialmente mientras las asignaciones activas permanecen en 1.1 GiB, algunas páginas propiedad del asignador eran liberables. Eso acota el diagnóstico, pero no demuestra que llamar a trim en producción sea la mejor política. Si el RSS apenas cambia, es posible que no haya páginas libres completas disponibles, que el crecimiento esté fuera de glibc o que la métrica incluya mapeos diferentes. Que el recorte no tenga éxito no demuestra una fuga.

Nunca coloque trim en cada solicitud. Liberar páginas puede cambiar memoria residente por llamadas al sistema, fallos menores, llenado con ceros, pérdida de caché y latencia de cola cuando llegue el siguiente lote. Un límite de fase natural con una ventana de inactividad larga es un candidato más defendible, y aun así requiere un canary.

Paso 6: Hacer coincidir la solución con la causa comprobada

• Fuga: corrija la referencia propietaria, el límite de caché, la liberación faltante o el ciclo de vida de la biblioteca. Recortar no hace que la memoria activa sea liberable.
• Retención intencional con reutilización a corto plazo: consérvela, aprovisione para el pico medido y alerte sobre una escalera repetida en lugar de forzar que el RSS coincida con los bytes activos.
• Fragmentación impulsada por la vida útil: separe los objetos de lote de vida corta del estado de servicio de larga duración, use una arena o región de lote que se pueda liberar como una unidad y evite intercalar un solo objeto de larga duración en muchas páginas transitorias.
• Dispersión en arenas o cachés de hilos: pruebe con menos arenas, menor concurrencia en el punto crítico de asignación o un patrón de propiedad diferente. Menos arenas pueden ahorrar memoria pero aumentar la contención.
• Fase de inactividad larga bajo un límite estricto: pruebe un recorte explícito post-lote o una purga específica del asignador con límites de tasa y una bandera de reversión.
• Incompatibilidad del asignador: compare glibc con una alternativa adecuada bajo la traza exacta. El diseño de mimalloc de Microsoft Research ilustra la compensación fundamental: las páginas locales de cada hilo mejoran la escalabilidad y la localidad, mientras que la propiedad aislada puede retener memoria que otro hilo no puede reutilizar inmediatamente.

arena_max, trim_threshold y mmap_threshold de glibc son experimentos, no constantes mágicas. Configurarlos hace que el comportamiento sea más estático y puede cambiar la contención, el recuento de mapeos, la frecuencia de liberación y el costo de las llamadas al sistema. Cambie un factor a la vez y conserve la imagen original como respaldo para reversión.

Paso 7: Validar memoria y latencia conjuntamente

Reproduzca 30 ciclos idénticos en hardware representativo de producción. El número 30 es una ventana de prueba para el ejercicio, no un requisito universal. Monitoree asignaciones activas, bytes mapeados/libres/liberables del asignador, RssAnon, RSS total, memory.current, presión, fallos de página, latencia de asignación, CPU, rendimiento (throughput) y latencia de solicitudes p50/p99.

Un ejemplo de criterios de aceptación para este escenario podría ser: RssAnon posterior a la inactividad en o por debajo de 2.2 GiB dentro de los 20 minutos, sin escalera ascendente a lo largo de 30 ciclos, sin OOM ni presión sostenida, p99 en o por debajo de 120 ms y no más del 3% de regresión de CPU. Estos umbrales son supuestos prácticos que deben reemplazarse con el presupuesto real del servicio. Una solución que alcance 2.2 GiB pero impulse el p99 a 145 ms falla; una solución que preserve la latencia pero aún se acerque al límite de 8 GiB bajo la siguiente combinación de tamaños válida también falla.

Respuesta de muestra de alta calidad

“No calificaría esto como una fuga solo por el RSS. free() finaliza la propiedad de un bloque por parte de la aplicación, pero glibc puede mantener ese bloque en una arena para su reutilización, y unos pocos objetos activos pueden mantener residentes páginas que de otro modo estarían libres. Primero verificaría que la cifra de 1.1 GiB cubra asignaciones activas nativas, luego la alinearía con RssAnon, RssFile, mapeos de RssShmem, smaps, estadísticas del asignador y el cargo del cgroup a lo largo de un lote completo.

Reproduciría el mismo lote tres veces. Si las asignaciones activas aumentan después de cada período de inactividad de 20 minutos, compararía perfiles de objetos activos y corregiría la ruta de propiedad. Si los bytes activos se mantienen en 1.1 GiB, el RSS se mantiene cerca de 5.2 GiB y el siguiente lote reutiliza ese espacio sin otro aumento, la retención es la explicación más sólida. Si los bytes libres del asignador son altos pero las páginas liberables se mantienen bajas y la meseta cambia con la vida útil de los objetos o la concurrencia de 64 hilos, investigaría la fragmentación y la dispersión en arenas.

Como diagnóstico exclusivo de glibc, llamaría a malloc_trim(0) una vez en un canary después del lote. Un RssAnon más bajo con bytes activos sin cambios demuestra que algunas páginas del asignador eran liberables; no justifica recortar en cada solicitud. Luego elegiría el cambio más pequeño específico para la causa: reparar una fuga, separar los ciclos de vida del lote en una región liberable, o probar en canary un recorte post-lote acotado o ajuste de arenas. Reproduciría 30 ciclos y aceptaría el cambio solo si la memoria posterior a la inactividad cumple con el objetivo acordado, el RSS no sube en escalera, el cgroup permanece seguro y el p99 se mantiene dentro de los 120 ms.”

Errores comunes

• Llamar fuga a la brecha de 4.1 GiB → el RSS incluye páginas libres del asignador y mapeos no pertenecientes al heap → demuestre el crecimiento en asignaciones activas o propiedad retenida con perfiles sincronizados.
• Afirmar que free() siempre reduce el RSS → un fragmento liberado puede permanecer en una arena o compartir una página con fragmentos activos → describa la reutilización, la liberación de páginas completas y las asignaciones mapeadas independientemente.
• Afirmar que free() nunca devuelve memoria → los asignadores pueden desmapear mapeos grandes, recortar fragmentos superiores o descartar páginas libres enteras vía madvise → indique que la liberación depende del asignador, la disposición y la política.
• Usar una sola proporción de fragmentación como prueba → un pico reciente, mapeo de archivos, caché o retención intencional pueden inflarla → compare bytes activos, libres, mapeados, residentes y liberables a lo largo de ciclos repetidos.
• Llamar a malloc_trim(0) en cada solicitud → la liberación forzada puede agregar llamadas al sistema, fallos y latencia de cola → pruébelo una vez en un límite de inactividad natural y mida la siguiente ráfaga de asignación.
• Configurar arena_max en uno porque hay 64 hilos → la memoria puede caer mientras la contención de bloqueos aumenta → explore valores candidatos bajo la misma concurrencia y proteja el p99.
• Cambiar de asignador basándose en el titular de un benchmark → el tamaño de asignación, la vida útil y los patrones de liberación entre hilos determinan los resultados → haga pruebas A/B de la traza exacta con reversión y criterios tanto de memoria como de latencia.
• Ignorar la contabilidad de cgroup → el RSS de un proceso no es el dominio completo de la memoria → reconcilie memory.current, memory.stat, descendientes y presión con las métricas del proceso.

Preguntas de seguimiento y respuestas

Si malloc_trim(0) reduce el RSS de 5.2 GiB a 1.8 GiB, ¿qué ha demostrado?

Ha demostrado que glibc poseía una cantidad sustancial de memoria liberable a nivel de página en ese momento y que el alto RSS no correspondía en su totalidad a datos activos de la aplicación. No ha demostrado la ausencia de una fuga más pequeña, la causa de la retención ni la seguridad de un recorte frecuente. Vuelva a ejecutar la carga de trabajo y mida fallos de página, CPU, latencia de asignación y p99 antes de seleccionar una política.

Si trim devuelve cero y el RSS no se mueve, ¿es una fuga?

No. El espacio libre puede estar distribuido entre páginas que aún contienen fragmentos activos, la memoria puede estar retenida en otro asignador o mapeo, o puede que no existan páginas liberables de glibc. Compare perfiles activos, bytes libres y liberables del asignador y la propiedad de smaps. Una fuga requiere evidencia de que las asignaciones activas o retenidas están creciendo, no simplemente un recorte fallido.

¿Qué pasa si el RSS permanece plano pero memory.current continúa creciendo?

Investigue el delta del cgroup en lugar del heap. memory.stat puede revelar caché de archivos, shmem, sockets o memoria del kernel, y el cgroup puede incluir otros procesos o descendientes. Confirme la jerarquía y la propiedad de los mapeos. Ajustar glibc porque el RSS de un solo proceso es plano apuntaría a la capa equivocada.

¿Por qué no forzar a glibc a usar una sola arena?

Una sola arena puede reducir la dispersión pero serializa más trabajo de asignación. Con 64 hilos, eso puede cambiar memoria residente por contención de bloqueos y regresiones en el p99. Pruebe varios recuentos acotados de arenas bajo la traza de asignación real, capture la contención del asignador y la latencia, y seleccione el recuento más pequeño que satisfaga ambos presupuestos.

¿Cuándo sería mejor un asignador de arena de lote o de regiones?

Es atractivo cuando la mayoría de los objetos comparten un ciclo de vida claro: asígnelos desde una región durante el lote y libere la región completa después. Es inseguro cuando las referencias escapan al estado de servicio de larga duración, se requieren destructores o limpieza por objeto, o un lote contiene muchos ciclos de vida no relacionados. Asegure el límite de propiedad antes de confiar en una liberación en bloque.

¿Cómo evaluaría un asignador de reemplazo?

Use la misma compilación excepto por el enlace del asignador, la misma traza de entrada, recuento de hilos, asignación de CPU, calentamiento y ventana de 30 ciclos. Compare el RSS pico y posterior a la inactividad, la brecha entre memoria activa y residente, el rendimiento de asignación, CPU, fallos de página, p50/p99 y el comportamiento ante fallos cerca del límite de 8 GiB. Implemente en canary la opción ganadora con una reversión de despliegue; un RSS promedio más bajo por sí solo no es suficiente.