Cómo monitorizar el TarMK | AEM 6.3 | OAK 1.6

* La siguiente información es aplicable para las versiones Oak 1.6+ y AEM 6.3+.

Problema
Debido a la limitada memoria disponible (off y on heap), cuando el repositorio de la instancia crece a un cierto nivel, las cachés se sobrecargan.
Como resultado, la mayoría del repositorio accede a los datos de lectura directamente desde el disco, lo que es mucho más lento, lo que resulta en una mala experiencia para el usuario final.

Síntomas
En general, la instancia se vuelve lenta: el tiempo de respuesta aumenta y la limpieza de la revisión en línea toma mucho más tiempo para completarse, a veces sobrepasando la ventana de mantenimiento asignada.
A nivel de sistema, se observa una actividad de IO alta y constante.

Pasos

Solución de problemas

Hay varios puntos finales que se supervisan para determinar cuándo el sistema se convierte en IO. 
En los párrafos siguientes se examinan los parámetros disponibles y los principales indicadores.

Monitorización de endpoints

Existen varios puntos finales para la monitorización de métricas relacionadas con E/S en AEM, la JVM y el sistema operativo. 

Juntos proporcionan diferentes perspectivas sobre el rendimiento global del sistema en las distintas capas: desde las sesiones JCR para confirmar en el TarMK hasta el disco IO del TarMK.

Combinados con la información recopilada con herramientas a nivel de JVM y SO, proporcionan una gran cantidad de información sobre la salud del sistema y para ayudar a encontrar cuellos de botella.

• Cada sesión expone una instancia de SessionMBean, que contiene contadores como el número y la velocidad de lectura y escribe en la sesión.
• El RepositoryStatsMBean expone los endpoints para monitorear el número de sesiones abiertas, la tasa de acceso a la sesión, la carga total de lectura y escritura en todas las sesiones, los tiempos generales de lectura y escritura en todas las sesiones y la carga total y los tiempos de consulta y observación.
• El SegmentNodeStoreStatsMBean expone los endpoints para monitorizar las confirmaciones: número y tasa, número de confirmaciones en cola y tiempos de espera.
•  FileStoreStatsMBean expone los endpoints reflejando la cantidad de datos escritos en el disco, el número de archivos tar en el disco y la huella total en el disco.

Además de estos puntos finales, existen muchas herramientas específicas para JVM y sistemas operativos que ayudan a obtener más información sobre lo que el sistema está haciendo:

• Java Mission Control (jmc) es una potente herramienta para recopilar todos los aspectos de rendimiento de una JVM en ejecución. Su capacidad de grabar IO por proceso Java a veces puede ser invaluable.
• Las herramientas de línea de comandos jstat, jstack y jmap son útiles para entrar en JVM's garbage collector, el JVM's threads, y el JVM's heap, respectivamente.
• Las herramientas de nivel de sistema operativo vmstat e iostat se utilizan para examinar el uso de E/S y CPU a nivel de sistema operativo.

Monitorización de IO de disco

Qué: el número de operaciones de disco (lecturas/escrituras) por unidad de tiempo (segundo)

Cómo: Herramientas a nivel de sistema operativo (por ejemplo: vmstat, iostat en UNIX)

Normal: bajo nivel de lecturas de disco (cerca de cero); constante, bajo número de escrituras (ver imagen). Picos durante la limpieza de revisión.

Advertencia: un nivel alto y creciente de lecturas de disco es una señal de que la memoria está subdimensionada (ver imagen).

AVISO: un alto volumen de IO de disco se debe a otras operaciones que se ejecutan en AEM (por ejemplo: ingestión de activos) o por otro proceso (por ejemplo: escaneo de virus), así que asegúrese de excluir cualquier otra causa antes de diagnosticar Segment Tar como culpable. En general, la tendencia a lo largo de los días es más relevante que los picos locales.

Monitorización de la CPU

• Qué: tiempo que pasa la CPU en varias operaciones, especialmente esperando por IO.
• Cómo: Herramientas a nivel de SO (por ejemplo: vmstat en UNIX). No todas las herramientas informan de esto (por ejemplo: arriba).
• Normal: La CPU es utilizada principalmente por la aplicación a nivel de usuario y la espera de IO es un pequeño porcentaje.
• Advertencia: La CPU está gastando la mayor parte de los ciclos de espera de IO, con una tendencia creciente, en detrimento de la aplicación de usuario.
• ADVERTENCIA: un alto porcentaje de CPU esperando por IO se debe a otras operaciones que se ejecutan en AEM (por ejemplo: ingestión de activos) o por otro proceso (por ejemplo: escaneo de virus), así que asegúrese de excluir cualquier otra causa antes de diagnosticar a Segment Tar como el culpable. En general, la tendencia a lo largo de los días es más relevante que los picos locales.

Supervisión de la cola de confirmación

• Qué: la cola de confirmación es un mecanismo de búfer utilizado por Segment Tar cuando el volumen entrante de confirmaciones es superior a la velocidad de procesamiento.
• Cómo: el tamaño de la cola de confirmación en tiempo real se muestra a través de JMX MBean: org.apache.jackrabbit.oak: COMMIT_QUEUE_SIZE (Métricas) (/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3DCOMMIT_QUEUE_SIZE%2Ctype%3DMetrics). Se accede a él a través de http en la consola del sistema o utilizando un cliente JMX.
• Normal: una cola vacía (size=0) muestra que el sistema está en un estado saludable y puede procesar todas las confirmaciones a la velocidad a la que llegan. Los picos locales que se procesan rápidamente también son normales.
• Advertencia: cola constante, distinta de cero, con una tendencia creciente significa que el segmento tar no puede procesar las confirmaciones a la velocidad de entrada. Existe el riesgo de que la cola se llene y se rechacen nuevas confirmaciones.
• ADVERTENCIA: una cola alta temporal (pico) se debe a una operación intensiva que se desencadena (por ejemplo: replicación o despliegue) o a un alto tráfico, así que asegúrese de excluir cualquier otra causa antes de diagnosticar a Segment Tar como el culpable. En general, la tendencia es más relevante que los picos locales.