Tomando un Dump: Usando Heap Dumps para Encontrar y Solucionar Problemas de Memoria y CPU en NodeJS

A veces tomar un volcado puede ser un verdadero salvavidas. Estoy hablando, por supuesto, de usar heap dumps para encontrar y solucionar problemas de memoria y CPU en Node.js. ¿Qué pensaste que estaba diciendo? De todos modos, mi nombre es Dan Shapir. Bienvenidos a JS Nation y a mi charla sobre heap dumps, memory dumps y problemas de CPU.

Quiero comenzar con una historia de terror. Eres la persona de guardia y acabas de recibir una llamada telefónica informándote que el servidor se ha caído. O tal vez simplemente está funcionando muy, muy lento y no está atendiendo las solicitudes en un tiempo razonable. ¿Qué haces? Así que obviamente comienzas a investigar. Miras los registros. Miras los diversos gráficos de rendimiento.

Y luego ves algo que se parece a esto. Es un gráfico de la memoria utilizada por el servidor. Y ves que sigue subiendo y subiendo, ocasionalmente bajando cuando el servidor se reinicia o reinicia. Pero luego simplemente sigue subiendo nuevamente. Así que ahora sabes que tienes una fuga de memoria. Y ese es un gran problema porque, ¿qué haces después?

Bueno, en esta charla, te daré las herramientas que te convertirán en el fontanero de tu organización, capaz de resolver y solucionar fugas de memoria y los problemas que causan. Pero primero, necesitamos discutir por qué las fugas de memoria son incluso un problema en un entorno Node.js. Quiero decir, JavaScript es un lenguaje de programación con recolección de basura después de todo. ¿No significa eso que toda la memoria se recupera automáticamente y que las fugas de memoria nunca deberían ocurrir? Bueno, cualquiera que sepa algo sobre cómo funciona realmente la recolección de basura en la vida real sabe que este no es el caso.

Y incluso en entornos con recolección de basura, las fugas de memoria pueden ocurrir tanto en la vida real como en la programación. Y para entender por qué sucede eso, necesitamos hablar sobre cómo funciona realmente la recolección de basura en JavaScript y en los lenguajes de programación en general.

Así que digamos que este es el estado de nuestra memoria donde tenemos múltiples objetos viviendo en el heap. Algunos objetos son referenciados directamente desde la raíz, la raíz en JavaScript siendo ya sea el ámbito global o el contexto de ejecución actual. Así que algunos objetos son referenciados directamente desde la raíz.

Otros objetos son referenciados por otros objetos. Y a veces incluso puede ser una conexión circular. Así que esto es un grafo, no un árbol. Bueno, JavaScript utiliza un enfoque de recolección de basura llamado marcado y barrido, que en realidad tiene dos fases.

En la primera fase, que se llama marcado, el recolector de basura comienza desde la raíz o múltiples raíces y busca cada objeto al que puede llegar. Sigue estas conexiones, a lo largo de estos enlaces, y marca cada uno de ellos. Cuando ve que no hay objetos adicionales que pueda marcar, sabe que es hora de detenerse porque ha alcanzado todos los objetos a los que puede llegar. Luego pasa a la etapa de barrido.

En la etapa de barrido, observa todos los objetos que no han sido marcados y entiende que estos objetos son inalcanzables. Eso es porque no hay forma de acceder a ellos desde una de las raíces. Como resultado, ya no pueden ser utilizados y, por lo tanto, pueden ser recuperados. Su memoria puede ser liberada.

La recolección de basura hace un poco más que eso, pero eso es suficiente para el alcance de esta conversación. Entonces, ¿cuál es el problema real? Bueno, el problema es que, como podemos ver, la recolección de basura no recoge todos los objetos que ya no son necesarios. Recoge todos los objetos que ya no pueden ser utilizados porque ya no pueden ser alcanzados. Si un objeto aún puede ser alcanzado, incluso si ya no es necesario, la recolección de basura no lo sabe. Sabe que aún podría ser utilizado y, por lo tanto, no es seguro recuperarlo.

La causa de las fugas es que cierta memoria todavía se mantiene ya sea por globals que la referencian directa o indirectamente, o por el contexto que, nuevamente, todavía mantiene una referencia a ella ya sea directa o indirectamente. Considere, por ejemplo, un cache global que es ilimitado, lo que significa que puedes seguir poniendo más y más cosas en él y las cosas nunca se van. Obviamente, esto puede causar una fuga porque seguirás agregando cosas al cache y nunca las eliminarás. Incluso si eliminas elementos del cache, si los eliminas a una tasa que es menor a la que realmente se agregan, eventualmente saturarás tu memoria.

Con closures y contactos, una causa común de fugas de memoria podría ser un hook que conectas a un evento receptor y tienes un closure para ejecutar una instrucción particular con un contexto relevante. El problema allí es lo que sucede cuando no desconectas ese hook cuando ya no es necesario. Todavía estás registrado para recibir eventos aunque ya no te importen, y efectivamente filtras toda la memoria que está referenciada, nuevamente, directa o indirectamente por el closure.

En realidad, el grafo de memoria no es tan limpio, tan plano como lo viste, al menos si haces zoom lo suficiente. Incluso si no tienes una fuga, la memoria sigue fluctuando hacia arriba y hacia abajo. Lo que realmente sucede es que el uso de memoria sube, y luego el recolector de basura entra en acción, y el uso de memoria baja a medida que se libera la memoria no utilizada, y luego comienza a subir nuevamente. Así que lo que vemos aquí es una fluctuación, un patrón tipo sierra, pero eso realmente indica que no hay una fuga de memoria.

Una fuga de memoria, en realidad, de cerca se ve algo así. El uso de memoria disminuye cada vez que el recolector de basura entra en acción, pero no baja tanto como antes. Gradualmente sube y sube y sube hasta que eventualmente nos quedamos sin memoria. Pero no se trata solo de la memoria. También se trata del CPU. Por ejemplo, debido a un evento llamado GC storm. Un GC storm es lo que sucede cuando la memoria disponible es tan baja que el sistema necesita constantemente hacer GC para intentar liberar algo de memoria. Pero debido a que hay una fuga, nunca logra liberar lo suficiente. Así que solo ejecuta este GC más y más y más a menudo, y llega al punto en que efectivamente todo lo que hace el sistema es ejecutar el GC todo el tiempo y no queda CPU para nada más. De hecho, en nuestro propio entorno real, cuando tuvimos una fuga de memoria real, y vimos que el uso de memoria subía y subía, de hecho, también vimos que el uso de CPU aumentaba significativamente durante ese tiempo. Y de hecho, la razón por la que un servidor con fugas de memoria se vuelve no responsivo es a menudo exactamente por esto. Así que obviamente, realmente queremos evitar las fugas de memoria, y si las tenemos, queremos solucionarlas lo más rápido posible. Pero el problema es que identificar la causa de una fuga de memoria puede ser realmente, realmente difícil. Eso es porque no es local a un entorno o ubicación particular en la aplicación. Lo que quiero decir es que una fuga de memoria en cualquier parte de la aplicación impacta a toda la aplicación en su conjunto, no solo a ciertas partes de ella. Y eso hace que identificar la causa de una fuga sea muy difícil y desafiante. Otro problema es que la fuga de memoria a menudo se manifiesta solo en entornos de producción donde el sistema está bajo una carga sustancial. Podría manifestarse en un entorno de prueba también, pero allí la fuga es tan pequeña y minúscula que nunca la notaremos realmente.

Ahora, obviamente, puedes hacer pruebas de carga, pero eso puede ser muy difícil y desafiante. Es muy difícil crear un entorno de prueba que realmente emule escenarios de producción reales. Entonces, ¿qué hacemos al respecto? Bueno, afortunadamente, tenemos heap dumps y memory dumps para rescatarnos. Un heap dump o un memory dump, es efectivamente lo mismo en este contexto, toma una instantánea de todos los objetos alcanzables en memoria en un punto específico en el tiempo, y luego podemos analizar lo que realmente está sucediendo al mirar esa instantánea. Hay múltiples maneras de generar heap dumps para un entorno Node.js. Podemos usar DevTools, podemos usar la línea de comandos, y podemos usar una API. Así que comencemos con DevTools. Y para este propósito, de hecho, te mostraré una demostración rápida. Así que aquí tengo una aplicación simple de Node.js, realmente solo un archivo JavaScript que genera una fuga de memoria. Intencionalmente crea una fuga de memoria. Tenemos un array global llamado leak data en el que pondremos objetos y nunca los eliminaremos. Creé un endpoint especial que cada vez que llego a ese endpoint, genero 10,000 nuevas instancias de un objeto que simplemente tiene tres propiedades que contienen números aleatorios, y empujo estos objetos en ese array filtrado para que nunca sean liberados.

Y luego solo devuelvo alguna información de estado sobre el uso de memoria. Así que lancemos esta aplicación de Node.js. La ejecuto en modo de depuración porque voy a usar los DevTools para encontrar y arreglar la fuga de memoria. Así que ahora veamos cómo realmente causamos el enlace. Abriré otra terminal, y haré ping a ese endpoint usando curl.

Como podemos ver, tuvo éxito. Creó la fuga, y devolvió la información de uso del heap. Y si hago ping de nuevo, veo que el uso del heap realmente sube porque cada vez filtro más y más memoria debido a todos los objetos que se crean y nunca se liberan. Pero, ¿cómo los encontraría en un entorno de producción real? Bueno, para eso, abramos los Chrome DevTools. Abro una nueva pestaña de Chrome. Hago Chrome inspect, y hago clic en el enlace de inspección.

Porque esa instancia de node está ejecutándose en modo dev, realmente puedo conectarme a ella. Y vemos los DevTools, que son realmente similares a los DevTools que vemos al depurar un sitio web, menos varias pestañas que no son relevantes. Por ejemplo, no hay pestaña de elementos, porque no hay elementos. Es una instancia de node, no una pestaña de navegador. Así que lo que hago ahora, estoy en la pestaña de memoria, y estoy en la opción de instantánea de heap. Hay otras opciones interesantes, pero están fuera del alcance de esta conversación.

Así que solo tomaré una instantánea. Y ahora tengo un volcado de memoria o un volcado de heap de todos los objetos que residen en la memoria. Veo los varios tipos de objetos. Hay objetos de código. Hay objetos de objeto general. Hay matrices de contexto, etcétera. Para cada uno, veo el tamaño superficial, que es el tamaño real de ese tipo particular, de todas las instancias de ese objeto particular, y el tamaño retenido, que también incluye referencias de objetos por esas instancias.

Pero como puedes ver, hay muchas cosas aquí. Hay cadenas y otras cosas que no son relevantes para este escenario de fuga en particular. Entonces, ¿cómo identifico exactamente lo que estoy buscando? Hay una gran manera de abordar esto, y es creando una diferencia entre dos instantáneas. Así que lo que hago ahora es causar otra fuga. Realizo la operación que causa una fuga, y obtengo otra instantánea. Ahora, en lugar de mirar el resumen, miro la comparación entre estas dos instantáneas, y puedo ordenar por el delta el cambio de tamaño.

Y veo que filtré un objeto que tiene la estructura ABC. También filtré muchos números porque A y B y C contienen números, y esos números también son objetos en memoria. Pero veamos los objetos reales. Podemos ver que filtré 10,000 objetos, que es exactamente el número que tenemos aquí en el código que creamos cada vez que se hace ping a ese endpoint. Bien, sé lo que estoy filtrando, pero ¿cómo encuentro qué lo está reteniendo para que pueda solucionarlo fácilmente? Para eso, lo abro y selecciono una instancia de objeto específica.

Incluso puedo ver los valores que tiene en sus números. Y aquí puedo ver qué lo está referenciando realmente. Así que veo que estoy en la matriz de datos filtrados. Puedo realmente subir por la lista de referencias hacia la raíz y ver qué objeto o qué variable, ya sea global o en un contexto, lo está reteniendo realmente. Y aquí puedo ver que es la matriz de datos filtrados, exactamente porque lo empujamos en la matriz de datos filtrados y nunca lo eliminamos de ella. Así que ahora también puedo saber y entender qué está reteniendo realmente estas instancias, y sé qué arreglar. Así que volvamos a la presentación.

Como podemos ver, DevTools y el mecanismo de instantáneas de heap de memoria es una gran manera de encontrar y solucionar fugas de memoria y de esta manera resolver los problemas de CPU y memoria. Pero, ¿es la única manera? Pero primero que todo, hablemos de los beneficios y limitaciones de este enfoque. Los beneficios son que es muy fácil de usar en el ciclo de desarrollo. Hay múltiples herramientas de desarrollo que puedo usar. Puedo usarlo con los Chrome DevTools. Puedo usarlo con los DevTools que están integrados, por ejemplo, en VS Code. También puedo perfilar una fuga durante el inicio usando Inspect BRK en lugar de Inspect. Pero también hay desventajas en este enfoque. Requiere un reinicio para agregar ese flag de CLI que pone el node en modo de desarrollo. Requiere acceso desde el entorno de desarrollo a la instancia de node usando el protocolo de depuración de Chrome, lo cual es un problema de seguridad aunque puedes tunelarlo sobre SSH. Obviamente hay una sobrecarga de rendimiento al ejecutar la instancia de node en modo de depuración, y también puedo romper accidentalmente el servicio simplemente presionando el botón de pausa en el entorno de desarrollo. Además, tomar instantáneas es realmente pesado, y si no tengo cuidado, puedo realmente matar el proceso solo tomando una instantánea de memoria.

Otra manera interesante de obtener una instantánea es usar un nuevo flag experimental de node, heap snapshot near heap limit, y especificas cuántas instantáneas de heap tomar. Entonces, lo que sucede es que cuando node se acerca al límite de memoria del heap, tomará una instantánea hasta tres veces en este caso, para que aún pueda hacer la diferencia y encontrar la razón de lo que realmente está filtrando al hacer la comparación entre las instantáneas. Esta es una manera interesante, pero necesitas tener cuidado con ella porque, nuevamente, tomar esa instantánea podría simplemente llevarte más allá del límite y causar que el proceso se bloquee. En realidad, prefiero otra manera, que es especificar que node tomará una instantánea automáticamente cuando reciba una señal. Así que en este caso, uso el node snapshot signal equals siguser2, y luego si uso el comando kill de linux para enviar esa señal a ese proceso, realmente haré que genere un archivo de volcado de heap en una carpeta especificada. ¿Cuáles son los beneficios de este enfoque? Primero que todo, es configurar y olvidar. Puedes ponerlo en producción siempre que no estés tomando instantáneas. No hay sobrecarga, y es seguro porque no necesito abrir un puerto de depuración a esa instancia. En el lado negativo, necesito poder acceder a esa caja de Linux, por ejemplo, usando SSH para enviar la señal a ese proceso. Además, los volcados en sí mismos ocupan espacio en el servidor, y necesitas tener cuidado con cuántos volcados realmente pones allí antes de limpiar para asegurarte de que no explotes tu disco. Y, nuevamente, tomar la instantánea, sigue siendo una operación pesada y puede llevarte más allá del límite.

La tercera manera es realmente usar una API. Hay APIs integradas en Node que puedes usar para generar volcados de heap. Así que puedes implementar, por ejemplo, tu propio endpoint TCP que escuche algún tipo de instrucción y genere un volcado de heap bajo demanda y lo coloque donde quieras que vaya. Obviamente, eso requiere un poco más de esfuerzo. Los beneficios de usar una API, puedes controlar exactamente cuándo y cómo invocarla. Y, nuevamente, no hay sobrecarga cuando está inactiva. Solo hay sobrecarga cuando realmente invocas ese endpoint.

En el lado negativo, hay consideraciones de seguridad porque si conoces ese endpoint, tal vez otros también lo sepan, y literalmente pueden hacer un DDoS a tu servidor muy fácilmente al hacer ping a ese endpoint. Además, como antes, necesitas tener cuidado con el uso del espacio en disco donde pones los dumps. Además, otra cosa que realmente necesitamos pensar y considerar al usar volcados de heap es que los volcados de heap, porque contienen una instantánea de todo el contenido de la memoria del proceso, definitivamente pueden contener información sensible. Por ejemplo, información relevante en PII o HIPAA. Así que realmente necesitas tener cuidado sobre dónde pones esos archivos de instantáneas, a quién les das acceso, y obviamente eliminarlos tan pronto como sea posible cuando ya no sean necesarios.

Así que para resumir lo que hablamos hoy, GC no previene fugas de memoria. Eso es porque solo recupera memoria que ya no puede ser utilizada, no la memoria que ya no es necesaria. Las fugas son difíciles de encontrar y arreglar porque, como hablamos, pueden ocurrir en cualquier parte de la aplicación y afectar a la aplicación en su conjunto, y usualmente se manifiestan solo en entornos de producción. Puedes usar volcados de heap para encontrarlas y arreglarlas identificando las fugas e identificando qué es lo que realmente las está causando. Como vimos, hay múltiples métodos para obtenerlos, y puedes usar el que mejor se adapte a tus necesidades. Deberías usar comparaciones para encontrar los deltas, y de esta manera es la forma más fácil de analizar realmente la causa de la fuga. Usas los retainers para identificar la causa. Como viste, miramos y encontramos en nuestro caso que era ese array de datos de fuga.

Y luego, después de crear una solución, deberías verificar la solución para ver que la fuga esté realmente resuelta y que no haya otras fugas ocultas en el sistema detrás de esa fuga más significativa. Y obviamente, ten mucho cuidado con la seguridad debido a los datos sensibles que pueden estar contenidos dentro de esos volcados de heap. Muchas gracias por acompañarme en esta charla. Espero que puedan ser efectivos como los fontaneros de su organización ayudando a resolver y arreglar fugas de memoria. Gracias, y adiós.