Este artículo describe los problemas críticos de AEM más comunes y cómo analizarlos.
Rendimiento de AEM Sites
Rendimiento de AEM Assets
Problemas de memoria
Problemas de indexación
Problemas de replicación
Problemas de daños en TarMK
Resolución
Problemas de rendimiento de AEM Sites
Síntomas de un problema de rendimiento
Carga lenta de páginas
Creación o edición lentas de páginas
AEM tiempos de respuesta son lentos
AEM no responde a algunas solicitudes
El AEM request.log on muestra tiempos de respuesta lentos
Causas de los problemas de rendimiento
Contención de subprocesos: solicitudes de larga duración, como búsquedas lentas, trabajos de fondo con escritura pesada, movimiento de ramas enteras del contenido del sitio, etc.
Alta utilización de la CPU
Solicitudes costosas como búsquedas costosas o código de aplicación, componentes, etc. ineficientes.
Falta de mantenimiento adecuado
Almacenamiento en caché de Dispatcher insuficiente
Falta de CDN
Falta de almacenamiento en caché del explorador
Demasiados scripts cargados en la página y en la parte superior de la página
CSS cargado en toda la página en lugar de en el encabezado del HTML
Tamaño insuficiente del servidor o arquitectura incorrecta
Compruebe a nivel del sistema operativo si el proceso java de AEM está causando una alta utilización de la CPU: 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.
Linux: utilice el comando superior para comprobar la utilización de la CPU.
Ventana: usar el Administrador de tareas de Windows
Revise los procedimientos de mantenimiento del sistema. Consulte esta article para obtener más información sobre AEM mantenimiento y asegúrese de que está realizando el mantenimiento adecuado en AEM, incluidos:
Limpieza de revisión (solo MongoMK y DocumentNodeStore de base de datos) - diaria o más frecuente
Compactación Tar sin conexión (solo TarMK): quincenal
Colección de residuos del almacén de datos (solo sistemas con FileDataStore o S3 DataStore): semanal
Purga del flujo de trabajo: semanal
Purga de la versión: semanal
Purga de AuditLog: frecuencia semanal
Revise las estrategias de almacenamiento en caché implementadas en la AEM nivel de Dispatcher.
Utilice herramientas de análisis del sitio del lado del cliente como el Auditorías función en el navegador Google Chrome Herramientas para desarrolladores panel. Estas herramientas le darán recomendaciones sobre las mejoras de rendimiento del lado del cliente.
Soluciones a problemas comunes de rendimiento
Consulte este artículo para ver los pasos detallados sobre las formas de optimizar el rendimiento.
Si el uso de "Old Generation" (JDK 7 y versiones anteriores) o "Tenured Generation" (JDK 8 o versiones posteriores) es alto, esto podría ser una señal de un problema de utilización de memoria en pilas. Haga clic en Ejecutar recolector de residuos para solicitar a la JVM que ejecute una colección de residuos completa. Si la alta utilización de memoria se mantiene alta después de solicitar GC, entonces es probable que haya un problema. En una instancia AEM con almacenamiento Oak Tar, si el uso tendido es superior a 3 GB, puede haber un problema. La alta utilización de memoria en un sistema con almacenamiento Mongo podría deberse a la configuración de caché en memoria.
Realizar volcados de subprocesos y salida superior y realizar análisis de subprocesos. Compruebe si los subprocesos que causan una alta utilización de la CPU son subprocesos nativos de colección de residuos de JVM. Si el subproceso que utiliza la mayor cantidad de tiempo de CPU es el "subproceso VM" o cualquier 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 acumula debido al uso incorrecto de la finalización en el código personalizado
Configuración de montículos máx. insuficiente
Cómo analizar la causa de su problema de memoria
Consulte este artículo para obtener más información sobre cómo capturar un volcado de montículos.
La mejor manera de identificar la causa de un problema de memoria es analizar un volcado de montículos.
Una vez que haya capturado un archivo de volcado de montículos, ábralo en Eclipse MAT o Analizador de memoria de IBM herramienta. En Eclipse MAT, ejecute el informe Fuga de sospechosos y abra la vista "Detalles del subproceso" para ver las causas potenciales del problema de memoria.
Soluciones a problemas comunes de memoria
Optimice el código de la aplicación para utilizar menos memoria si observa pausas largas en la recolección de basura. La mayoría de los problemas de la colección de residuos se pueden resolver optimizando la aplicación en lugar de sintonizar la JVM.
Si ya ha optimizado la aplicación y sigue experimentando largas pausas de GC, entonces enfoque en el ajuste de JVM.
Problema de indexación de AEM
Síntomas de problemas de indexación
Los siguientes son signos de un problema con la indexación de AEM/Oak:
Los resultados de búsqueda están obsoletos en 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:
Abra estas direcciones URL en la 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 - This La URL solo se aplica a AEM6.2 y posterior
En cada una de esas páginas, compruebe estos campos:
FailingSince : esto indica cuándo comenzó a fallar la indexación.
LastError - Este es el seguimiento de pila que muestra lo que está causando que la indexación falle. Si está vacío, la indexación no está fallando.
LastErrorTime : esto indica la última vez que la indexación lanzó el error.
LastIndexedTime - 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 incorrecto o fallo en la realización del mantenimiento, como la colección de residuos de revisión, la purga del flujo de trabajo, la purga de auditoría, la purga de la versión, etc.
Segmentos dañados o que faltan en el almacenamiento de Tar
Corrupción en la revisión en un entorno agrupado (DocumentNodeStore - Mongo o Database)
Problema con la topología del clúster en un entorno agrupado
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 se ponen en cola en la cola del agente de replicación
El contenido publicado no se muestra en el servidor de publicación
Impacto en el rendimiento del sistema
Causas de los problemas de replicación:
El agente de replicación está mal configurado y no puede conectarse al agente de publicación
Hay un error en el momento de la replicación que hace que la cola de replicación se atasque
El sistema es lento y las réplicas se procesan lentamente
La replicación se está realizando como parte de un flujo de trabajo personalizado y el problema está en el procesamiento del flujo de trabajo.
Bloqueado: cuando los elementos están en cola, pero no se pueden procesar; por ejemplo, cuando el agente señala a un host que está inactivo o que no existe.
Revise las configuraciones de replicación si su servidor está clonado o el agente se ha configurado recientemente. Para obtener más información, consulte here.
Revise los registros del agente de replicación 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 a AEM asistencia técnica.
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 a AEM asistencia técnica.
Si la cola de replicación está en estado "inactivo" y no se aplica ninguna de las anteriores, en este caso el problema es probablemente causado por los flujos de trabajo. Si los flujos de trabajo no se están procesando, el elemento de replicación nunca llega a la cola de replicación. Para monitorizar el estado de los flujos de trabajo, puede comprobar el panel de flujo de trabajo para comprobar el número de instancias de flujo de trabajo en ejecución. Puede obtener información sobre la administración de flujos de trabajo here.
Las réplicas se ralentizan cuando el sistema está bajo una carga alta o experimenta otros problemas de rendimiento.
La instancia no se puede utilizar después de la compactación sin conexión.
Instancia atascada Inicio en curso estado.
Informes de salida de archivos de registro o comandos de compactación SegmentNotFoundException.
Causas de los problemas de corrupción
El segmento se elimina mediante una intervención manual (por ejemplo, rm -rf ).
El segmento se elimina mediante 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 un espacio en disco reducido.
Forzosamente, deteniendo AEM matando el proceso java.
Diagnóstico de problemas de corrupción del repositorio:
Revise el archivo error.log y compruebe si hay SegmentNotFoundException o Excepción IllegalArgument.
Para determinar si un segmento ha sido eliminado por la colección de residuos de revisión, compruebe el resultado del registrador org.apache.jackrabbit.oak.plugins.segment.file.TarReader-GC (habilitar registro de depuración). Ese registrador registra los identificadores de segmento de todos los segmentos eliminados por la fase de limpieza. La colección de residuos de revisión es la causa de la excepción sólo cuando el identificador del segmento infractor aparece en la salida de ese registrador.
En caso de corrupción en el almacén de datos externo, busque en el archivo de registro todas las ocurrencias de error Error al obtener InputStream para blobId. Este error significa que faltan archivos del directorio del almacén de datos AEM.
Solución para reparar problemas de daños:
Determine la última corrección correcta conocida del almacén de segmentos utilizando la variable check modo de ejecución de oak-run. Revierta manualmente el almacén de segmentos dañado a su última corrección correcta. Esta operación revertirá el repositorio Oak a un estado anterior a tiempo. Debe realizar una copia de seguridad completa del repositorio antes de realizar esta operación.
Para realizar la comprobación y restauración, siga los pasos mencionados en este artículo.
Si la comprobación falla con ConsistencyChecker - No se encontraron revisiones correctas a continuación, aplique los pasos de la parte B de este artículo.
Si no utiliza un almacén de datos, utilice un archivo externo, S3 o Azure datastore, en lugar del almacén de segmentos predeterminado.
El uso de un almacén de datos ofrece un mejor rendimiento.
Migración de la instancia a una con un almacén de datos mediante crx2oak.
Aplique el último Service Pack y Cumulative Fix Pack y Oak Cumulative Fix Pack.