¿Qué métrica de memoria deben usar las alertas y los autoscalers en un servicio en contenedores: RSS, PSS, working set o memory.current de cgroup?

Pregunta abierta

Las cifras disponibles no coinciden sobre lo que un contenedor "usa". La página del manual define el VmRSS de un proceso como la suma de RssAnon, RssFile y RssShmem, de modo que incluye páginas respaldadas por archivos que el kernel puede recuperar y cuenta las páginas compartidas una vez por cada proceso. La documentación de cgroup v2 define memory.current como la cantidad total de memoria que usa en ese momento el cgroup y sus descendientes, y memory.stat la desglosa en memoria anónima, cache de archivos (incluidos tmpfs y la memoria compartida) y memoria del kernel; sobre este total actúan memory.max y el OOM killer. La documentación de Kubernetes informa la memoria como working set, describe el ideal como la memoria en uso que no se puede liberar bajo presión, y señala que el cálculo varía según el sistema operativo del host, depende en gran medida de heurísticas y normalmente incluye algo de memoria respaldada por archivos.

En un servicio de larga duración sometido a un límite de memoria, ¿cuál de estas métricas debería activar una alerta o un autoscaler? Una alerta basada en RSS puede pasar por alto un contenedor que se acerca a su límite, porque la page cache y la memoria del kernel se contabilizan en el cgroup, pero no en el proceso. Una alerta basada en memory.current puede avisar por un contenedor cuya cache simplemente se recuperaría. El working set queda entre ambas, pero la documentación indica que su cálculo varía según el sistema operativo del host y depende en gran medida de heurísticas. Subpreguntas:

• ¿Qué señal se ha usado en la práctica durante un año o más, y con qué frecuencia produjo falsas alertas frente a OOM kills no detectados?
• ¿Un servicio que lee archivos grandes a través de la page cache (bases de datos, contenido multimedia, recolectores de logs) necesita una señal distinta de la de uno que mantiene su estado en memoria anónima?
• ¿La magnitud relevante es realmente un nivel, o más bien la tasa de crecimiento de la memoria anónima, o la información de bloqueo por presión de memoria (pressure stall information), que mide el tiempo perdido en la recuperación en lugar de bytes?
• ¿Cómo debe ajustarse la señal en servicios que llenan deliberadamente la memoria con cache hasta el límite?

Qué contiene una respuesta útil

Los nombres exactos de las métricas y sus fuentes (qué archivo de /proc o de cgroup, qué métrica del runtime), el tipo de carga de trabajo, la configuración del límite, durante cuánto tiempo estuvo activa la regla, el número de alertas y de OOM kills en ese periodo y cuántos de cada uno estaban justificados, y el razonamiento que relaciona la métrica elegida con la condición de OOM. Son más útiles las respuestas que comparan dos señales sobre el mismo servicio durante el mismo periodo que las que describen una sola señal; las respuestas que se limiten a repetir los valores por defecto del proveedor deberían indicarlo.