¿Por qué necesita monitoreo del desempeño? Hablemos del monitoreo del rendimiento de Node.js

Por qué es necesaria la supervisión del rendimiento

Node, como tiempo de ejecución de Javascript en el lado del servidor, enriquece enormemente los escenarios de aplicación de Javascript.

Sin embargo, Node.js Runtime en sí es un cuadro negro. No podemos percibir el estado del tiempo de ejecución y es difícil reproducir los problemas en línea.

Por lo tanto, la supervisión del rendimiento es la piedra angular del "funcionamiento normal" de las aplicaciones Node.js. No solo se pueden monitorear varios indicadores de tiempo de ejecución en cualquier momento, sino que también puede ayudar a solucionar problemas de escenarios anormales.

de los componentes

se puede dividir en dos partes:

• recopilación y visualización de indicadores de rendimiento

  • . Datos a nivel de proceso: CPU, memoria, montón, GC y otros
  • datos a nivel del sistema: ocupación del disco, carga de E/S, estado de la conexión TCP/UDP. etc.
  • Datos de la capa de aplicación:

• captura y análisis de datos de rendimiento

  como QPS, HTTP lento, registros de enlaces de procesamiento empresarial, etc.
  • Heapsnapshot: instantánea de la memoria dinámica
  • Cpuprofile: instantánea de la CPU
  • Coredump:

comparación de soluciones de instantáneas de fallos de la aplicación

En la imagen de arriba, puede ver las ventajas y desventajas de las tres soluciones actuales de monitoreo de rendimiento de Node.js. La siguiente es una breve introducción a la composición de estas tres soluciones:

• Prometheus

  • prom-client es la implementación de Nodejs de Prometheus.
  • Grafana
  • se utiliza para recopilar indicadores de rendimiento.
  • Se necesitan otras herramientas de instantáneas para solucionar problemas y formar un

• AliNode de circuito cerrado.

  • Alinode es un tiempo de ejecución extendido compatible con nodejs oficiales, que proporciona algunas funciones adicionales:

    • monitoreo del estado de la memoria en tiempo de ejecución de v8
    • monitoreo del estado del tiempo de ejecución de libuv
    • Funciones de diagnóstico de fallas en línea: instantánea del montón, perfil de CPU, seguimiento de GC, etc.

  • Agenthub es un proceso residente que se utiliza para recopilar indicadores de rendimiento e informar sobre ellos.

    • Agentx integrado + Las convenientes herramientas de commdx

  • forman un circuito cerrado desde el monitoreo, la visualización, la instantánea y el análisis. El acceso es conveniente y simple, pero aún existen riesgos al expandir el tiempo de ejecución

• • del que es responsable

  Easy-Monitor

.
• • muestreo de estado de tiempo de ejecución en tiempo real y registros de rendimiento de salida (es decir, obtención de datos de rendimiento)
  • xtransit es responsable de la recopilación y transmisión de registros de rendimiento.
  • La mayor diferencia con AliNode es el uso Node.js Addon para implementar el

indicador de rendimiento

de la CPU.

Los datos de consumo de tiempo de CPU del proceso actual se pueden obtener a través de process.cpuUsage() La unidad del valor de retorno es microsegundos.

• Usuario: el tiempo de CPU consumido por el proceso en sí cuando se ejecuta el proceso.
• Sistema: el tiempo de CPU consumido por el proceso actual. sistema cuando se ejecuta el proceso

Memoria

Los datos de asignación de memoria del proceso actual se pueden obtener a través de process.memoryUsage() . La unidad del valor de retorno es bytes

• rss: memoria residente, el tamaño total de la memoria asignada por el proceso del nodo
• heapTotal: el tamaño de la memoria del montón solicitado por v8.
• heapUsed: el montón utilizado por v8 Memory
• sizeexternal: el tamaño de memoria ocupado por C++ administrado por v8
• arrayBuffers: el tamaño de memoria asignado a ArrayBuffer

Como se puede ver en la figura anterior, rss incluye segmento de código ( Code Segment ), memoria de pila ( Stack ) y memoria de montón ( Heap ).

• Segmento
• de código: almacena segmentos de código
• : almacena variables locales y llamadas a funciones de administración.
• almacena objetos, cierres o todos los demás

montones.

Puede obtener datos de análisis de la memoria y el espacio del montón de v8 a través de v8.getHeapStatistics() y v8.getHeapSpaceStatistics() La siguiente figura muestra la distribución de la composición de la memoria del montón de v8:

El espacio de la memoria del montón primero se divide en espacios y el espacio se divide en páginas. La memoria se pagina según una alineación de 1 MB.

• Nuevo espacio: espacio de nueva generación, utilizado para almacenar algunos datos de objetos con un ciclo de vida relativamente corto, dividido en dos espacios (el tipo de espacio es semi space ): from space to space

  • Condiciones de promoción: aún sobrevive después de dos GC en el nuevo espacio

• Espacio antiguo : el espacio de generación anterior, utilizado para almacenar objetos promovidos por New Space

• Code Space: almacena el código ejecutable compilado por v8 JIT.

• Map Space: almacena el objeto puntero de la clase oculta apuntada por Object. v8 según el tiempo de ejecución La estructura de diseño de objetos se utiliza para acceder rápidamente a miembros de objetos.

• Espacio de objetos grandes: se utiliza para almacenar objetos de más de 1 MB que no se pueden asignar a páginas.

El algoritmo de recolección de basura de

GC

• Mayor. GC: utiliza Mark-Sweep-Compact Minor GC para el reciclaje de objetos en la generación anterior
• : el algoritmo Scavenge se utiliza para reciclar objetos en la nueva generación

Scavenge.

Premisa: New space se divide en dos espacios de objetos: from y to

Tiempo de activación: cuando New space está lleno.

Pasos:

• en from space , realice un recorrido en amplitud

• y descubra que el objeto superviviente (alcanzable)

  • ha sobrevivido una vez (. experimentó un Scavange), promovido al Old space y
  • otras copias to space

• Cuando finaliza la copia, solo quedan objetos supervivientes en to space , from space se vacía,

• se intercambia from space to space y comienza la siguiente ronda Scavenge .

es adecuado para reciclaje frecuente y memoria insuficiente Para objetos grandes, la estrategia típica de espacio por tiempo tiene la desventaja de desperdiciar el doble de espacio que

Mark-Sweep-Compact.

Tres pasos: marcar, borrar y organizar

. Tiempo de activación: cuando Old space está lleno.

Pasos:

• Marcar (método de marcado de tres colores).

  • Blanco: representa objetos reciclables.
  • Negro: representa objetos no reciclables y todas las referencias generadas.
  • Gris: representa objetos no reciclables y las referencias generadas por ellos aún no se han escaneado.
  • Coloque
  • los objetos a los que hace referencia directamente el objeto raíz V8 en una marking queue (pila explícita) y márquelos en gris.
  • Inicie la profundidad desde estos objetos. Priorice el recorrido Cada vez que se acceda a un objeto, pop el objeto de marking queue y márquelo en negro.
  Luego marque todos los objetos blancos
  • a
  • los que hace referencia el objeto como grises y push a marking queue .
  • todos los objetos de la pila se extraen hasta que se sueltan, solo hay dos tipos de objetos en la generación anterior: negros (no reciclables) y blancos (se pueden reciclar)
  • . empujado a la pila con espacio limitado, v8 mantendrá el objeto en gris y lo omitirá, marcará toda la pila como desbordada (desbordada), esperará a que se borre la pila y atravesará la marca nuevamente, lo que requerirá un escaneo adicional. El

• barrido

  del montón
  • para borrar los objetos blancos
  • hará que el espacio de memoria sea discontinuo

• . El barrido compacto

  • hará que el espacio de memoria sea discontinuo. Es útil que nuevos objetos ingresen al GC
  • y muevan los objetos negros (de supervivencia) a uno. final Old space , para que el espacio limpiado sea continuo y completo.
  • Aunque puede resolver el problema de fragmentación de la memoria, aumentará el tiempo de pausa (velocidad de ejecución lenta)
  • y no habrá suficiente espacio para los nuevos estudiantes. solo se usa al asignar objetos promocionados

Stop-The-World

Cuando v8 realiza inicialmente la recolección de basura, necesita detener el programa, escanear todo el montón y recuperar la memoria antes de volver a ejecutar el programa. Este comportamiento se denomina pausa completa ( Stop-The-World ).

Aunque los objetos activos en la nueva generación son pequeños y se reciclan con frecuencia, un punto final tiene poco impacto. Sin embargo, los objetos supervivientes en la generación anterior son muchos y grandes. y pausas provocadas por marcar, limpiar, clasificar, etc. Será más grave.

Estrategia de optimización

• de reciclaje incremental (marcado incremental): en la fase de marcado, cuando el montón alcanza un cierto tamaño, se inicia el GC incremental cada vez que se asigna una cierta cantidad de memoria, el programa en ejecución se pausa y el marcado se realiza durante unos milisegundos. a decenas de milisegundos y luego reanude el programa.

Este concepto es en realidad un poco como la arquitectura Fiber en el marco React. Solo durante el tiempo libre del navegador atravesará el Fiber Tree para realizar las tareas correspondientes, de lo contrario, la ejecución se retrasará, afectando lo menos posible las tareas del hilo principal. , evitando retrasos en las aplicaciones y mejorando el rendimiento de las mismas.

• Barrido concurrente: permita que otros subprocesos realicen el barrido al mismo tiempo sin preocuparse por el conflicto con el subproceso principal del programa en ejecución.
• Barrido paralelo: permita que varios subprocesos de barrido funcionen al mismo tiempo, mejore el rendimiento del barrido y acorte todo el período de GC.

Ajuste de espacio.

Porque v8 tiene un límite predeterminado en el espacio de las generaciones nuevas y antiguas.

• Límite predeterminado New space : 32 M para sistemas de 64 bits y 16 M para sistemas de 32 bits
• Old space 700M para sistemas de 32 bits

Por lo tanto, node Se proporcionan dos parámetros para ajustar el límite de espacio superior de las generaciones nueva y antigua

• --max-semi-space-size : establece el valor máximo del espacio New Space
• --max-old-space-size : establece el valor máximo de la vista de espacio Old Space

El

node de registro de GC también proporciona tres formas de ver los registros de GC:

• --trace_gc : una línea de registro describe brevemente el tiempo, el tipo, los cambios en el tamaño del montón y las causas de cada GC
• --trace_gc_verbose : muestra cada montón V8 después de cada GC Estado detallado del espacio
• --trace_gc_nvp : información detallada del par clave-valor de cada GC, incluido el tipo de GC, tiempo de pausa, cambios de memoria, etc.

Dado que el registro de GC es relativamente primitivo y requiere procesamiento secundario, puede usar v8-gc, desarrollado por el equipo de AliNode, la

herramienta de instantáneas

, Heapsnapshot,

toma una instantánea de la memoria del montón de un programa en ejecución y se puede usar para analizar el consumo de memoria y cambiar

los métodos de generación

.heapsnapshot generarse de las siguientes maneras:

• usando heapdump

• Usando el perfil de montón de v8

• Utilice la api

  • v8.getHeapSnapshot()

  proporcionada por el módulo v8 integrado de nodejs

  

  • v8.writeHeapSnapshot(fileName)

  

• Usando v8-profiler-siguiente

el método de análisis

.heapsnapshot cargar en la Memoria en la barra de herramientas de desarrollo de Chrome y los resultados se mostrarán como se muestra a continuación:

La vista predeterminada es Summary . Aquí debemos prestar atención a las dos columnas de la derecha: Shallow Size y Tamaño Retained Size

• Retained Size
• Shallow Size el tamaño del objeto asignado en la memoria del montón v8.
• Shallow Size de todos los objetos referenciados del objeto.

Cuando se descubre que Retained Size es particularmente grande, puede haber una pérdida de memoria dentro del objeto. Puede expandirse aún más para localizar el problema

Comparison Analice las instantáneas del montón de dos períodos diferentes. La columna Delta se puede utilizar para filtrar los objetos con los mayores cambios de memoria.

Cpuprofile

realiza un muestreo de instantáneas de la CPU que ejecuta el programa, que se puede utilizar para analizar el tiempo y la proporción de la CPU.

Hay varias formas de generar un archivo .cpuprofile :

v8

• -profiler (una herramienta proporcionada oficialmente por node, pero ya no puede)

• admite el nodo v10 o superior) y ya no se mantiene)
• v8-profiler-next (versión de mantenimiento china, admite el último nodo v18, bajo mantenimiento continuo)

Esta es una colección de muestra de perfil de CPU de 5 minutos

El archivo .cpuprofile generado Javascript Profiler

el método de análisis

La vista predeterminada es la vista Heavy . Aquí vemos dos columnas: Self Time y Total Time

• Self Time representa el tiempo de ejecución de esta función en sí (excluyendo otras llamadas).
• Total Time : representa el tiempo de ejecución de esta función (incluidas otras)
.
• funciones de llamada). Cuando se descubre que el tiempo total y el tiempo propio se desvían mucho, la función

Total Time Self Time un cálculo intensivo de la CPU que lleva mucho tiempo. También puede realizar más soluciones a los problemas

cuando

la aplicación falla y finaliza

el sistema lo registrará automáticamente. El proceso bloquea la información de asignación de memoria, el contador de programa, el puntero de la pila y otra información clave en ese momento para generar

métodos de generación

. Tres métodos para generar archivos .core :

• ulimit -c unlimited abre el límite del kernel.
• node --abort-on-uncaught-exception Agregar este parámetro al iniciar el nodo puede generar un archivo principal cuando ocurre una excepción no detectada en la aplicación
• gcore <pid> Generar manualmente

el método de análisis

. Después de obtener el archivo .core , analice y El diagnóstico se puede lograr a través de herramientas como mdb, gdb, lldb, etc. La causa real del bloqueo del proceso

• llnode `which node` -c /path/to/core/dump

observación

del análisis de caso

A partir del monitoreo se puede observar que la memoria del montón continúa aumentando, por lo que se necesitan instantáneas del montón para la resolución de problemas

y el análisis.

Según heapsnapshot podemos analizar y descubrir que hay un objeto newThing que siempre ha mantenido una memoria relativamente grande

.

un resumen

unused theThing newThing . Los casos replaceThing causados ​​​​por cierres

incluyen las siguientes situaciones:

• variables globales,
• cierres,
• temporizadores y
• cachés
• de escucha de eventos
.

Por lo tanto, en las situaciones anteriores, debe considerar cuidadosamente si el objeto en la memoria se reciclará automáticamente. no se puede reciclar automáticamente, es necesario el reciclaje manual, como configurar manualmente los objetos en null , eliminar temporizadores, desvincular detectores de eventos, etc.

concluye

este artículo. Este artículo ha brindado una introducción detallada a todo el sistema de monitoreo de rendimiento de Node.js.

Primero, presenta los problemas resueltos por el monitoreo del desempeño, sus componentes y una comparación de las ventajas y desventajas de las soluciones convencionales.

Luego, se presentan en detalle las dos partes principales de los indicadores de rendimiento y las herramientas de instantáneas.

• Los indicadores de rendimiento se centran principalmente en la CPU, la memoria, el espacio de almacenamiento dinámico y los indicadores de GC. Al mismo tiempo, se presentan la estrategia de GC y el plan de optimización de GC de v8.
Las herramientas
• de
• instantáneas incluyen principalmente instantáneas de montón, instantáneas de CPU y Coredump durante una falla.

Finalmente, se reproduce un caso simple de pérdida de memoria a partir de la observación, el análisis y la resolución de problemas, y se resumen situaciones y soluciones comunes de pérdida de memoria.

Espero que este artículo pueda ayudar a todos a comprender todo el sistema de monitoreo del rendimiento de Node.js.