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 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, siendo 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. Que incluso en entornos con recolección de basura, pueden ocurrir fugas de memoria, 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.

Supongamos 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 puede incluso 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. Va a lo largo de 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 reclamados. 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?

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 reclamarlo. Y esa es la causa de las fugas. La causa de las fugas es que cierta memoria todavía se mantiene ya sea por globales 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 caché global, que no tiene límites, lo que significa que puede seguir poniendo más y más cosas en él, y las cosas nunca se van. Obviamente esto puede causar una fuga, porque simplemente seguirá agregando cosas al caché y nunca las eliminará. Incluso si elimina elementos del caché, si los elimina a una tasa que es menor a la que realmente se agregan, eventualmente explotará su memoria. Con closures y contextos, una causa común de fugas de memoria podría ser un hook que conecta para recibir un evento, y tiene un closure para ejecutar una instrucción particular con un contexto relevante.

El problema allí es lo que sucede cuando no desconecta ese hook cuando ya no es necesario. Todavía está registrado para recibir eventos, aunque realmente ya no le importan, y efectivamente filtra 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 vio, al menos si se acerca lo suficiente. Incluso si no tiene 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 cae a medida que se libera la memoria no utilizada.

Luego comienza a subir de nuevo. Lo que vemos aquí es una fluctuación, un patrón tipo sierra, pero eso en realidad indica que no hay una fuga de memoria. Una fuga de memoria, en realidad, de cerca, se ve algo así. El uso de memoria cae cada vez que el recolector de basura entra en acción, pero no cae tan bajo como antes. Gradualmente sube y sube y sube hasta que eventualmente nos quedamos sin memoria.

Pero no se trata solo de memoria. También se trata de CPU, por ejemplo, debido a un evento llamado tormenta de GC. Una tormenta de GC 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, por lo que simplemente 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 las fugas de memoria a menudo se manifiestan solo en entornos de producción donde el sistema está bajo una carga sustancial. Podría manifestarse también en entornos de prueba, 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 el rescate. Un heap dump o memory dump, es efectivamente lo mismo en este contexto, toma una instantánea de todos los objetos accesibles en memoria en un momento específico. Y luego podemos analizar lo que realmente está sucediendo al mirar esa instantánea. De hecho, hay múltiples formas de generar heap dumps para un entorno Node.js. Podemos usar herramientas de desarrollo, podemos usar la línea de comandos y podemos usar una API.

Así que, comencemos con las herramientas de desarrollo, 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. Crea intencionalmente una fuga de memoria. Tenemos un array global llamado leak data en el cual 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 las herramientas de desarrollo 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 aumenta 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 las Chrome DevTools. Abro una nueva pestaña de Chrome, hago Chrome inspect y hago clic en el enlace de inspección. Debido a que esa instancia de Node está ejecutándose en modo de desarrollo, realmente puedo conectarme a ella. Y vemos las herramientas de desarrollo, que son realmente similares a las herramientas de desarrollo 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. Entonces, lo que hago ahora, estoy en la pestaña de memoria. Y estoy en la opción de heap snapshot. 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 memory dump o un heap dump de todos los objetos que residen en memoria. Veo los varios tipos de objetos. Hay objetos de código, hay objetos generales, hay arrays de contexto, etc.

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 en 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 lo que estoy buscando? Hay una gran manera de abordar esto, y es creando una diferencia entre dos instantáneas. Entonces, 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 poder 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 el array 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 el array de datos filtrados, exactamente porque lo empujamos en el array de datos filtrados y nunca lo eliminamos de él. 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 Memory Heap snapshot es una gran manera de encontrar y solucionar fugas de memoria y de esta manera resolver los problemas de CPU y memoria. Pero, ¿es esta la única manera? Pero primero, hablemos sobre los beneficios y limitaciones de este enfoque. Los beneficios son que es muy fácil de usar en un 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 InspectBRK en lugar de Inspect.

Pero también hay desventajas en este enfoque. Requiere un reinicio para agregar esa bandera CLI que pone el nodo en modo de desarrollo. Requiere acceso desde el entorno de desarrollo a la instancia de nodo usando el protocolo de depuración de Chrome, lo cual es un problema de seguridad aunque se puede tunelizar sobre SSH. Obviamente, hay una sobrecarga de rendimiento al ejecutar la instancia de nodo 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 snapshots es realmente pesado. Y si no tengo cuidado, puedo realmente matar el proceso simplemente tomando un snapshot de memoria.

Otra forma interesante de obtener un snapshot es usar una nueva flag experimental de node, heap snapshot near heap limit, y especificas cuántos heap snapshots tomar. Entonces, lo que sucede es que cuando un nodo se acerca al límite de memoria del heap, tomará un snapshot hasta tres veces en este caso para que aún pueda hacer la diferencia y encontrar qué es lo que realmente está filtrando al hacer la comparación entre los snapshots. Esta es una forma interesante, pero debes tener cuidado con ella porque, nuevamente, tomar ese snapshot podría llevarte justo por encima del límite y causar que el proceso falle. En realidad, prefiero otra manera, que es especificar que node tomará un snapshot automáticamente cuando reciba una señal. Así que en este caso, uso la señal de snapshot de node igual a 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? En primer lugar, es configurar y olvidar. Puedes ponerlo en producción. Mientras no estés tomando snapshots, no hay sobrecarga. Y es seguro porque no necesito abrir un puerto de depuración para 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 dumps en sí mismos ocupan espacio en el servidor, y necesitas tener cuidado con cuántos dumps realmente pones allí antes de limpiar para asegurarte de que no llenes tu disco.

Y nuevamente, tomar el snapshot sigue siendo una operación pesada y puede llevarte por encima del límite. La tercera forma es usar una API. Hay APIs integradas en Node que puedes usar para generar heap dumps, por lo que puedes implementar, por ejemplo, tu propio endpoint TCP que escuche algún tipo de instrucción y genere un heap dump 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á inactivo, 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 conozcan, por lo que puedes literalmente hacer un DDos a tu servidor muy fácilmente al hacer ping a ese endpoint.