Objetivo

Problemas de rendimiento de AEM Sites

Síntomas de un problema de rendimiento

  1. Carga lenta de páginas
  2. Creación o edición lenta de páginas
  3. Los tiempos de respuesta de AEM son lentos
  4. AEM no responde a algunas solicitudes
  5. El archivo request.log en AEM muestra tiempos de respuesta lentos

Qué causa problemas de rendimiento

  1. Contención de subprocesos: solicitudes de larga duración tales como búsquedas lentas, trabajos de fondo con escritura pesada, traslado de fragmentos enteros de contenido del sitio, etc.
  2. Alta utilización de la CPU
  3. Solicitudes costosas como búsquedas costosas, componentes y códigos de aplicación ineficientes, etc.
  4. Falta de mantenimiento adecuado
  5. Insuficiente almacenamiento en caché de Dispatcher
  6. Ausencia de CDN
  7. Falta de almacenamiento en caché del navegador
  8. Demasiados scripts cargados en la página y en la parte superior de la página
  9. CSS cargado en toda la página en lugar de en el encabezado HTML
  10. Tamaño insuficiente del servidor o arquitectura incorrecta
  11. Problemas de memoria (consúltelos a continuación)

Análisis de problemas de rendimiento

1. Tome una serie de subprocesos y analícelos

2. Compruebe a nivel del Sistema operativo si el proceso de java AEM está causando un elevado uso de la CPU

    Linux: utilice el comando superior para comprobar la utilización de la CPU.

    Windows: utilice el Administrador de tareas de Windows

    Si AEM está causando una alta utilización de la CPU, ejecute la herramienta de creación de perfiles lista para usar durante unos minutos y analice el resultado.

3. Analice el archivo request.log para cualquier solicitud lenta

4. Revise los procedimientos de mantenimiento de su sistema y compruebe que está realizando un mantenimiento adecuado en AEM, incluidos los siguientes puntos:

  • Limpieza de revisión (solo MongoMK y la base de datos de DocumentNodeStore): frecuencia diaria o superior
  • Compactación de Tar sin conexión (solo TarMK): frecuencia quincenal
  • Colección de residuos en el almacén de datos (solo sistemas con FileDataStore o S3 DataStore): frecuencia semanal
  • Purga de flujo de trabajo: frecuencia semanal
  • Purga de versión: frecuencia semanal
  • Purga de AuditLog: frecuencia semanal

Consulte este artículo para saber más sobre el mantenimiento de AEM.

5. Revise las estrategias de almacenamiento en caché implementadas en el nivel de Dispatcher de AEM.  El mejor lugar para empezar es comprender cuándo y cómo el dispatcher almacena e invalida archivos en caché.

6. Revise el almacenamiento en caché de su sitio.

7. Utilice las herramientas de análisis de sitio del lado del cliente, como la función Auditorías en el panel Herramientas del desarrollador en el navegador de Google Chrome.  Estas herramientas le darán recomendaciones para mejorar el rendimiento del lado del cliente.

Soluciones a problemas comunes de rendimiento

Problemas de rendimiento de AEM Assets

Síntomas de un problema de rendimiento de Assets

  • Cargas lentas de archivos a /assets.html o a la IU de /damadmin
  • Las miniaturas tardan demasiado en generarse
  • Operaciones de Assets tales como mover, borrar, editar y actualizar metadatos llevan demasiado tiempo

Qué causa problemas con el rendimiento de Assets

  • Falta de mantenimiento adecuado
  • Los últimos paquetes de correcciones no se aplican
  • Optimizaciones no aplicadas
  • Tamaño inadecuado del servidor para la carga del usuario

Analizar los problemas de rendimiento de Assets

Soluciones a problemas comunes de rendimiento de Assets

Problemas de memoria

Síntomas de un problema de memoria

  • AEM se bloquea de forma aleatoria y se observa en los registros OutOfMemoryError
  • AEM se ralentiza con el tiempo y al final se bloquea
  • AEM no responde

Diagnóstico de un problema de memoria

  • Busque OutOfMemoryError en los archivos de registro, si encuentra alguna coincidencia, entonces tiene un problema de memoria
  • Consulte la pantalla http://aem-host:port/system/console/memoryusage
    Si el uso de Old Generation (JDK 7 y versiones anteriores) o Tenured Generation (JDK8 o posteriores) es alto, esto podría ser una señal de un problema de utilización de memoria.  Haga clic en Ejecutar colector de residuos para solicitar a JVM que realice una colección de residuos de memoria completa.  Si la utilización de memoria se mantiene alta después de solicitar GC, entonces es probable que haya un problema.  En una instancia de AEM con almacenamiento de Oak Tar, si el uso permanente es superior a 3 GB, es posible que haya un problema.  La utilización alta de memoria en un sistema con almacenamiento Mongo podría deberse a la configuración de la caché en la memoria.
  • Adopte los volcados de subprocesos y el resultado superior, y realice un análisis de subprocesos.  Compruebe si los subprocesos que causan una alta utilización de la CPU son nativos de la colección de residuos de JVM.  Si el subproceso que usa más tiempo de CPU es VM Thread o cualquier otro subproceso de colección de residuos, es probable que haya un problema de memoria.

Causas de los problemas de memoria

  • Fuga de memoria de la aplicación Java
  • Java Finalizer se apila debido al uso incorrecto de finalizado en código personalizado
  • Configuración insuficiente de la memoria máxima

Cómo analizar la causa de su problema de memoria

Consulte este artículo para saber más sobre cómo obtener un volcado de memoria.

La mejor manera de identificar la causa de un problema de memoria es analizar un volcado de memoria.  

Una vez que haya capturado un archivo de volcado de memoria, ábralo en la herramienta Eclipse MAT o IBM Memory Analyzer.  En Eclipse MAT, ejecute el informe de posibles causas de fuga y abra la vista Detalles del subproceso para ver las causas potenciales del problema de memoria.

Soluciones a problemas comunes de memoria

  • Optimice su código de aplicación para utilizar menos memoria si nota pausas largas en la colección de residuos.  La mayoría de los problemas de colección de residuos se pueden resolver optimizando la aplicación en lugar de sintonizar JVM.
  • Si ya ha optimizado su aplicación y todavía experimenta largas pausas de GC, céntrese en el ajuste de JVM.

Problemas de indexación de AEM

Síntomas de los problemas de indexación

Los siguientes son signos de un problema con la indexación AEM/Oak:

  • Los resultados de la búsqueda están desactualizados durante más de 10 minutos
  • Faltan resultados de búsqueda
  • Los errores se devuelven en la interfaz de usuario o en los registros durante la búsqueda a través de la interfaz de usuario del sitio, la búsqueda de Query Builder o la ejecución de la consulta JCR
Diagnóstico de un problema de indexación
  • Para ver si la indexación asíncrona es lenta o falla, haga lo siguiente:

1. Abra estas URL en su instancia de AEM para ver estadísticas sobre el indexador Async.

http://aemhost:port/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dasync%2Ctype%3DIndexStats

http://aemhost:port/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dfulltext-async%2Ctype%3DIndexStats Esta URL solo se aplica a AEM 6.2 y posteriores

2. En cada una de estas páginas, verifique estos campos:

FailingSince: indica cuándo comenzó a fallar la indexación.

LastError: es la traza de pila que muestra lo que está causando que la indexación falle.  Si está vacío, la indexación no está fallando.

LastErrorTime: indica la última vez que la indexación acabó en error.

Último tiempo indexado: si la fecha y la hora de este campo tienen más de 5 minutos, la indexación es demasiado lenta.

Qué causa problemas con la indexación

  • Mantenimiento inapropiado o falta de mantenimiento, como por ejemplo: colección de residuos de revisión, purga de flujo de trabajo, purga de auditoría, purga de versión, etc.
  • Segmentos dañados o que no se encuentran en el almacenamiento de Tar
  • Daños en la revisión en un entorno agrupado (DocumentNodeStore: Mongo o Database)
  • Un problema con la topología de clústeres en un entorno de clústeres

Cómo analizar las causas de los problemas de indexación

  • Consulte este artículo para analizar y corregir problemas de indexación

Problemas de replicación

Síntomas de problemas de replicación

  • Las solicitudes de publicación están en espera en la cola del agente de replicación
  • Los contenidos publicados no aparecen en el servidor de publicación
  • Impacto en el rendimiento del sistema

Causas de los problemas de réplica:

  • El agente de réplica está mal configurado y no puede conectarse con el agente de publicación
  • Hay un error en la hora de la réplica que hace que la cola de réplica se atasque
  • El sistema es lento y las réplicas se procesan lentamente
  • La réplica está ocurriendo como parte de un flujo de trabajo personalizado y el problema está en el procesamiento del flujo de trabajo.

Cómo analizar los problemas de Réplica:

1. Verifique el estado de la cola de réplica:

        Activo: los elementos se están procesando.
        Inactivo: la cola está vacía.
        Bloqueado: los elementos están en la cola, pero no pueden procesarse, por ejemplo, cuando el agente está dirigido a un servidor inactivo o que no existe.

2. Revise las configuraciones de réplica si su servidor está clonado o si el agente se ha configurado recientemente. Para obtener más información, consulte aquí
     
3. Revise los registros del agente de réplica en http://host:port/etc/replication/agents.author/AgentName.log.html#end.  Si no puede identificar ningún elemento, recopile este registro y preséntelo al servicio de asistencia técnica de AEM.

4. Revise el archivo error.log del servidor desde AEMinstall/crx-quickstart/logs; si no puede identificar ningún elemento, recopile este registro y preséntelo al servicio de asistencia técnica de AEM.

5. Si la cola de réplica está en estado inactivo y no se aplica ninguna de las condiciones anteriores, en estecasolo más probable es que el problema sea causado por los flujos de trabajo. Si los flujos de trabajo no se están procesando, el elemento de réplica nunca llega a la cola de réplica. Para supervisar el estado de sus flujos de trabajo, puede consultar el panel de control de flujos de trabajo para comprobar el número de instancias de flujo de trabajo en ejecución. Puede obtener más información sobre la administración de flujos de trabajo aquí.

6. Las réplicas se ralentizan cuando el sistema está sometido a una carga elevada o experimenta otros problemas de rendimiento.

Solución a problemas comunes de réplica:

1) Revise los problemas de la cola de réplica
2) Si el problema se debe a que los flujos de trabajo no se ejecutan de forma eficiente, puede revisar los consejos de procesamiento del flujo de trabajo simultáneo
3) Para problemas relacionados con el rendimiento lento de AEM general yréplicaspuede consultar los Problemas de rendimiento de AEM  

Problemas de daños en TarMK

Síntomas de daños en TarMK

  • La instanciaes inoperable después de la compactación sin conexión.
  • Instancia atascada en estado de Activación en progreso.
  • Archivos de registro o informe de resultados de comandos de compactación SegmentNotFoundException.

Causas de los problemas de daños

  • El segmento se ha eliminado mediante una intervención manual (por ejemplo, rm -rf).   
  • El segmento se ha eliminado durante la colección de residuos de revisión o el segmento no se puede encontrar debido a algún error en el código.   
  • El segmento no se puede encontrar debido a algún error en el código.
  • Varias tareas de mantenimiento no se realizan a tiempo, lo que lleva al crecimiento del repositorio y a la reducción del espacio en disco.
  • Forzar la detención de AEM interrumpiendo el proceso java.

Diagnóstico de problemas de repositorios dañados:

  • Revise el archivo error.log y compruebe si se encuentra SegmentNotFoundException o IllegalArgumentException.
  • Para determinar si un segmento se ha eliminado mediante la colección de residuos de revisión, compruebe la salida del archivo org.apache.jackrabbit.oak.plugins.segment.file.TarReaderRegistrador GC (habilitar registro de depuración). Ese registrador documenta los identificadores de segmento de todos los segmentos eliminados en la fase de limpieza. La colección de residuos de revisión es la causa de esta excepción solo cuando el identificador del segmento infractor aparece en la salida de ese registrador.    
  • En caso de daños en el almacén de datos externo, busque el archivo de registro para todos los errores Ha ocurrido un error mientras se obtenía InputStream para blobId. Este error significa que faltan archivos de su directorio de almacenamiento de datos de AEM.

Solución para reparar los problemas de daños:

  • Determine la última corrección correcta conocida del almacén de segmentos utilizando el modo de verificación de ejecución de oak-run.  Revierta manualmente el almacén de segmentos dañados a su última corrección correcta. Esta operación revertirá el repositorio Oak a un estado anterior en el tiempo.  Debería hacer una copia de seguridad completa del repositorio antes de realizar esta operación.
    • Para realizarcompruebey restauración, siga los pasos mencionados en este artículo.
    • Si la comprobación falla con el mensaje ConsistencyChecker: No se han encontrado revisiones correctas, implemente los pasos de la parte B de este artículo.
  • Si ya está utilizando un almacén de datos y encuentra el error “Error ocurrido al obtener InputStream para blobId”, es probable que falten archivos del almacén de datos. Consulte este artículo para resolver el problema.
  • Si no está utilizando un almacén de datos, utilice un archivo externo, S3 o Azure en lugar del predeterminadosegmentstore.
    • El uso de un almacén de datos proporciona un mejor rendimiento.
    • Migrar la instancia a una con un almacén de datos usando crx2oak.
  • Instale los últimos Service Pack, Cumulative Fix Pack y Oak Cumulative Fix Pack.

Esta obra está autorizada con arreglo a la licencia de Reconocimiento-NoComercial-CompartirIgual 3.0 Unported de Creative Commons.  Los términos de Creative Commons no cubren las publicaciones en Twitter™ y Facebook.

Avisos legales   |   Política de privacidad en línea