Algunas pérdidas de memoria son fáciles de detectar. El proceso asigna memoria, se olvida de liberarla y luego sigue creciendo hasta que algo sale mal. Esta no es esa clase de filtración.
Esta es la historia de cómo Canonical Support ayudó a una organización minorista global a rastrear la causa de una pérdida de memoria inusual que se originó en el PID 1, el primer proceso iniciado por el kernel durante la secuencia de inicio del sistema. El uso de memoria es 10 veces mayor de lo esperado. Al investigar el problema en tres capas separadas del sistema (un coordinador de almacenamiento mal configurado, una condición de carrera central y el asignador de glibc), nuestro equipo pudo identificar la fuente y rastrear rápidamente un parche.
síntomas sin sentido
El cliente es el departamento de innovación e ingeniería de una empresa minorista global. Son responsables de impulsar la transformación minorista de la empresa: operar granjas de servidores que funcionan como parte de los clústeres de almacenamiento de Ceph. En varios de los nodos del clúster, comenzaron a observar un patrón que no tenía sentido inmediato: /sbin/init (enlace simbólico a systemd, ejecutándose como PID 1) consume más del 50% de la memoria disponible del sistema. En un servidor con 125 GB de RAM, esto significa que solo el PID 1 podría contener unos 70 GB, frente a los 8 GB esperados. El sistema está pasando por una eliminación por falta de memoria y los procesos centrales de eliminación forzada para liberar memoria disponible para sobrevivir.
No hay explicación para la aparente ubicación diagnóstica. El consumo de memoria sigue creciendo y nunca se libera. La investigación no encontró ninguna causa obvia a nivel de aplicación. El cliente ha descartado que la carga de trabajo que se ejecuta en el servidor sea el problema. El problema se encuentra más profundo, debajo de la capa de aplicación.
Empiece a investigar: obtenga el artefacto adecuado
El primer paso del equipo de soporte de Canonical fue solicitar un informe SOS del nodo afectado, que es el punto de partida estándar para las investigaciones a nivel del sistema. Pero el resultado del informe sos, aunque completo, no contiene nada que explique la huella de 70 GB en el PID 1. El siguiente paso es más sencillo: el ingeniero solicita un volcado del núcleo del propio PID 1, producido utilizando gcore 1.
Esta no es una investigación de rutina. Producir un volcado de núcleo del proceso inicial (PID 1) en un sistema de producción en funcionamiento es el equivalente técnico de realizar una cirugía a corazón abierto mientras el paciente corre una maratón. PID 1 no es un proceso cualquiera; Es la raíz de todo el ecosistema del espacio de usuario. Si se dispara, todo el sistema colapsa. Debido a que el archivo resultante es grande (en este caso, el volcado de núcleo comprimido de 70 GiB a menos de 10 GiB, lo cual es una importante señal de alerta de que hay mucha duplicación en la memoria del proceso), transferir, descargar y analizar el archivo puede retrasar significativamente el inicio de la solución de problemas, y la investigación en sí puede llevar una cantidad de tiempo impredecible. El cliente lo subió y este artefacto fue lo que resolvió el caso.
Salto diagnóstico: de la memoria a la instalación
Al analizar el volcado de núcleo, los ingenieros de Canonical pueden ver directamente qué está ocupando la memoria del PID 1. Las huellas están asociadas con entradas de la tabla de instalación. Específicamente, se ejecutan las entradas del contenedor Docker ceph-volume. La tabla de montaje, que systemd mantiene y analiza cada vez que ocurre un cambio, ha crecido hasta alcanzar millones de entradas.
El comportamiento de systemd es por diseño: monitorea /proc/self/mountinfo y analizar toda la tabla en cada cambio. En circunstancias normales, la reparación no es un problema, pero dado que la representación ahora es tan grande, la reparación constante puede causar problemas graves. Cada vez que systemd lo analiza, el asignador de glibc reserva la memoria en lugar de devolverla al núcleo. La memoria se acumula pero nunca se libera.
Esto explica el mecanismo, pero aún no explica por qué la tabla de montaje se volvió tan grande o por qué el contenedor ceph-volume se ejecutaba con tanta frecuencia.
El segundo salto: el fracaso silencioso del que nadie sabe
Aquí es donde entra en juego la investigación entre capas.
Al rastrear la frecuencia de la actividad del contenedor de volumen ceph, los ingenieros determinaron la fuente real: el proceso cephadm (parte de la capa de orquestación de Ceph) intentó repetidamente «eliminar» (una operación destructiva que borra todos los datos y metadatos del disco y lo restablece a un estado limpio) un OSD (demonio de almacenamiento de objetos) que ya no existía. Como no hay ningún volumen lógico asociado, la operación falla siempre. Después de cada error, lo intentará nuevamente. Los contenedores Docker de volumen ceph se giran y desmontan en un bucle continuo.
Nadie se dio cuenta de esto ya que la capa de orquestación en Ceph falló silenciosamente y el único síntoma visible (el que llevó a los clientes al soporte de Canonical) fue que el PID 1 consumió 70 GB de memoria en un nodo sin ningún problema aparente.
La solución es detener el ciclo. Una vez que se soluciona cephadm y se detienen los repetidos intentos de zap, la agitación de montaje/desmontaje se detendrá, las condiciones de carrera dejarán de activarse y el uso de la memoria se estabilizará. El cliente confirma que la acción correctiva resolvió el problema inmediato.
Una vez que se implementó una solución alternativa, el equipo de Canonical pudo centrar su atención en encontrar una solución permanente.
Del diagnóstico al upstream
Los ingenieros de soporte de Canonical rastrearon el error hasta el código fuente y trabajan regularmente con la comunidad de código abierto para implementar correcciones más allá del alcance directo del cliente. Al proporcionar a los mantenedores principales de Linux errores completamente descritos y desencadenantes verificados, obtienen una solución que beneficia a todo el ecosistema de código abierto.
Al reducir el problema a un mínimo reproducible, montando y desmontando tmpfs en un circuito cerrado, el equipo aisló el mecanismo preciso y reproducible: la condición central de carrera. Este cambio provocó que las entradas de la tabla de montaje aumentaran intermitentemente en millones de filas, lo que provocó análisis continuos de systemd y reservas de memoria glibc, lo que resultó en una huella de memoria de 70 GB en PID 1.
El parche se ha fusionado con el núcleo principal. Después de pasar por el proceso de actualización de la versión estable (SRU), la solución apareció en varias versiones principales de Ubuntu.
Por qué este caso es convincente
Lo que parece una pérdida de memoria no es toda la historia. Cuando systemd libera memoria correctamente y glibc rastrea la memoria, no está disponible para el resto del sistema, lo que efectivamente priva al nodo. El verdadero problema es que una mala configuración silenciosa en la capa de orquestación de almacenamiento (bucles cehadm en un OSD inexistente) desencadena una condición de carrera a nivel central que se manifiesta como una huella misteriosamente grande. Ninguna capa puede contar la historia completa:
- El informe sos señaló este síntoma.
- El volcado de memoria identificó el mecanismo.
- El seguimiento de la actividad del contenedor identifica los desencadenantes. Sólo así podrá haber suficiente precisión para resolver el problema.
La cadena desde los síntomas de producción hasta los diagnósticos entre niveles y los parches principales es lo que parece el soporte de Enterprise Linux cuando el problema no es obvio y no cae en una categoría conocida.
Si desea conocer qué soporte ofrece Canonical para resolver problemas complejos de infraestructura, visite nuestra página de soporte o contáctenos.
