Analizar los procesos lentos y bloqueados

Preguntas frecuentes

¿Cuáles son las situaciones típicas que causan un alto consumo de CPU?

Ciertas actividades de mantenimiento pueden causar un mayor uso de la CPU de lo habitual: compactación de jar, recolección de residuos del almacén de datos, copias de seguridad en línea, activación de árboles, implementación de una actualización de la aplicación que provoque el vaciado de las cachés, ....

¿Cuál puede ser la razón de un consumo de CPU del 0%?

Un punto muerto en el nivel de Java puede causar tal situación. En este caso, haga unos cuantos volcados de hilos, abrir un vale de soporte y reinicie la instancia AEM.

¿Hay consejos de ajuste de rendimiento disponibles?

Sí, en https://helpx.adobe.com/es/experience-manager/kb/performance-tuning-tips.html

Véase también la sesión sobre de gem: http://dev.day.com/content/ddc/en/gems/dispatcher-caching---new-features-and-optimizations.html

Soluciones

Vídeo gem: sesión técnica de inmersión profunda

Vídeo sesión de gem disponible en http://dev.day.com/content/ddc/en/gems/cq-aem-5-6-troubleshooting.html

Adobe Experience Manager 5.6 o posterior y CRX 2.3 o posterior

Utilice http://localhost:4502/system/console/profiler durante al menos unos minutos durante el período de lentitud o alto uso de la CPU. La salida le ayuda a determinar qué hilos de JVM están consumiendo la mayoría de los ciclos de CPU, y sus paquetes y clases asociados.

Arriba CRX 2.2 

Utilice la sencilla herramienta de creación de perfiles de CPU que se incluye en CRX 2.0.x. Para iniciarla, abra

http://localhost:7402/crx/diagnostic/prof.jsp

CRX 1.x

Para ayudar a analizar el problema, cree unos cuantos volcados de subprocesos completos. Esas descargas de hilos pueden ser analizadas. Creación de Volcados de Temas Completos

Obtener el ID de proceso

Para obtener el identificador de proceso de su proceso Java, use

jps -l

Si esto no funciona (ruta no establecida, JDK no instalado, o una versión anterior de Java), utilice

ps -el | grep java

Volcados completos de hilos

Para analizar un problema de rendimiento o un proceso bloqueado, cree unos diez hilos de subprocesos completos con un retraso de aproximadamente un segundo. Si el problema puede estar relacionado con la agrupación en cluster, cree al menos diez volcados de hilos completos en cada nodo de cluster. Si es posible, los volcados de hilos deben crearse aproximadamente al mismo tiempo (no es necesario que sean exactos).

Un volcado de hilos completo comienza con esta información como ejemplo:

2015-07-22 10:26:30
Descarga completa Java HotSpot(TM) 64-Bit Server VM (24.65-b04):

"Thread-76273" daemon prio=3 tid=0x111061 nid=0x111061 en ejecución [0x111061]
.... la pila y el objeto bloqueado DEBEN estar presentes

Si el volcado de hilo no se parece al anterior, entonces no será posible realizar las investigaciones adecuadas.

Puede utilizar la “herramienta” que se proporciona en el paquete compartido tal y como se describe en la página. Proporciona una herramienta de volcado de hilos que le permite realizar múltiples volcados de hilos, volcado en el formato anterior.

Alternativamente, si está instalado, use jstack. Este comando imprime los volquetes de la hebra al sistema:

jstack <pid>

Este comando agrega un volcado completo del hilo a un archivo:

jstack <pid> >> threadDumpNode1.txt

En algunos sistemas puede que tenga que usar: sudo -u aem jstack -J-d64 -l <pid>

Si esto no funciona, use kill -QUIT. Este comando imprime los volquetes de hilos al archivo de registro:

kill -QUIT <pid>

Si no hay volcado de hilos en la salida estándar del último comando, puede añadirlo a los parámetros de java:

-XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=jvm.log

Nota: Si los pasos anteriores para obtener descargas de roscas no funcionan en su entorno, consulte este artículo.

Comprobar el uso de la CPU

Para analizar el problema, es importante saber si CRX /CQ está funcionando en un bucle sin fin, o si simplemente está durmiendo. Para averiguarlo, escriba

top

Este comando le da la lista de procesos, ordenados por uso de CPU. Si el proceso superior es un “proceso Java”, y si el PID coincide con CRX/CQ, entonces el proceso se está ejecutando a toda velocidad.

Si no está seguro de cómo interpretar los resultados, ejecute la siguiente declaración e incluya el archivo top.txt en el informe del problema:

top -l5 -s5 > top.txt

Comprobar el recuento de sesiones

En muchos casos el problema es que el número de sesiones abiertas es demasiado grande. En algún momento, ralentiza el procesamiento. Para averiguar si este es el caso, ejecute

jps -l (para obtener el id de proceso del proceso Java)

jmap -histo <pid> | grep CRXSession (para obtener el número de sesiones abiertas)

Si éste es, de hecho, el problema (el número es superior a unos pocos cientos de sesiones) entonces necesita ser analizado. Posiblemente se utiliza un pool de sesiones (dependiendo de la versión de CRX / CQ podría haber una corrección para el problema en cuestión), o una caché interna (posiblemente a nivel de aplicación) que haga referencia a las sesiones. Para analizar dónde se abren esas sesiones, consulte la página “Analizar sesiones no cerradas”.

No matar el proceso

El proceso CRX nunca debe ser eliminado, ni siquiera cuando la parada es demasiado larga. Si necesita matar un proceso que no está respondiendo, cree primero un volcado de hilo completo y registre un error.

Si usted mata el proceso CRX, la próxima vez que lo inicie el Tar PM puede crear archivos de backup_.tar.

Herramientas de soporte

Utilice la herramienta Thread Dump Collection and Analysis para recoger los volcados de subprocesos de una instancia de CQ en ejecución para solucionar los siguientes problemas:
- desempeño

- controversia de bloqueo

- deadlock

- otras cuestiones relacionadas con el hilo conductor