目标

本文介绍最常见的重要 AEM 问题及其分析方式。

AEM Sites 性能问题

性能问题症状

  1. 页面加载缓慢
  2. 页面创建或编辑缓慢
  3. AEM 响应时间缓慢
  4. AEM 不响应某些请求
  5. AEM 上的 request.log 响应时间缓慢

导致性能问题的原因

  1. 线程争用 - 长期运行的请求,如缓慢搜索、写操作频繁的后续作业、移动整个分枝的网站内容,等等
  2. 高 CPU 利用率
  3. 过于耗时的请求,如过于耗时的搜索或者应用程序代码或组件不足,等等
  4. 缺乏适当的维护
  5. 调度程序缓存不足
  6. 缺乏 CDN
  7. 浏览器缓存不足
  8. 页面和页面顶部加载的脚本过多
  9. 在整个页面中加载 CSS,而不是在 HTML 标题中加载
  10. 服务器大小不足或架构错误
  11. 内存问题(请参阅下文

如何分析性能问题

1. 捕捉一系列线程转储进行分析

2. 在操作系统级别检查 AEM java 进程是否会导致较高的 CPU 利用率

    Linux:使用 top 命令检查 CPU 利用率。

    Window:使用 Windows 任务管理器

    如果 AEM 是导致高 CPU 利用率的原因,则运行现成可用的分析工具几分钟并分析所得结果。

3. 分析 request.log 文件以确定任何缓慢的请求

4. 查看您的系统维护过程,确保在 AEM 上进行适当的维护,包括以下操作:

  • 修订版整理(仅限 MongoMK 和数据库 DocumentNodeStore)- 每天或更频繁
  • 脱机 Tar 压缩(仅限 TarMK)- 每两周
  • 数据存储垃圾收集(仅限具有 FileDataStore 或 S3 DataStore 的系统)- 每周
  • 工作流清除 - 每周
  • 版本清除 - 每周
  • AuditLog 清除 - 每周

有关 AEM 维护的更多详细信息,请参阅本文

5. 查看在 AEM 调度程序级别实施的缓存策略。最佳的切入点是了解调度程序何时以及如何缓存文件和使缓存文件失效

6. 查看站点的缓存

7. 使用客户端站点分析工具,如 Google Chrome 浏览器开发者工具面板中的 Audits 功能。这些工具将会提供有关客户端性能改进的建议。

常见性能问题的解决方案

AEM Assets 性能问题

Assets 性能问题症状

  • 到 /assets.html 或 /damadmin UI 的文件上传缓慢
  • 缩略图生成时间太长
  • 移动、删除、编辑和元数据更新等资产操作耗时太长

导致 Assets 性能问题的原因

  • 缺乏适当的维护
  • 未应用最新的修复包
  • 未应用优化
  • 用于用户负载的服务器大小不足

如何分析 Assets 性能问题

常见 Assets 性能问题解决方案

内存问题

内存问题症状

  • AEM 随机发生崩溃,并在日志中发现 OutOfMemoryError
  • AEM 随时间逐渐变得缓慢,并最终崩溃
  • AEM 无响应

诊断内存问题

  • 搜索日志文件以查找 OutOfMemoryError,如果找到任何匹配项,则表示存在内存问题
  • 查看 http://aem-host:port/system/console/memoryusage 屏幕
    如果“Old Generation”(老年代)(JDK 7 和更早版本)或“Tenured Generation”(年老代)(JDK8 或更高版本)使用率较高,则可能表示存在堆内存利用率问题。单击“Run Garbage Collector”(运行垃圾收集器)以请求 JVM 运行完整的堆垃圾收集。如果请求 GC 后堆利用率仍保持较高,则表示可能存在问题。在具有 Oak Tar 存储器的 AEM 实例上,如果年老代使用高于 3GB,则表示可能存在问题。具有 Mongo 存储器的系统上的高堆利用率可能是由内存中的缓存配置导致的。
  • 获取线程转储和 top 输出并执行线程分析。检查导致高 CPU 利用率的线程是否为本机 JVM 垃圾收集线程。如果使用最多 CPU 时间的线程是“VM 线程”或任何垃圾收集线程,则表示可能存在内存问题。

导致内存问题的原因

  • Java 应用程序内存泄露
  • 由于在自定义代码中错误地使用了 finalize,Java Finalizer 堆积起来
  • 最大堆配置不足

如何分析内存问题原因

请参阅本文以了解有关如何捕捉堆转储的详细信息。

确定内存问题原因的最佳方式是分析堆转储。 

捕捉堆转储文件后,在 Eclipse MATIBM Memory Analyzer 工具中打开该文件。在 Eclipse MAT 中,运行“Leak Suspects”(内存泄露)报告,并打开“Thread Details”(线程详细信息)视图以查看内存问题的可能原因。

常见内存问题解决方案

  • 如果发现长期运行的垃圾收集暂停,请优化您的应用程序代码以使用更少的内存。与调整 JVM 相比,优化应用程序可以更好地解决大部分垃圾收集问题。
  • 如果已优化应用程序,但仍遇到长期运行的 GC 暂停问题,则请着重调整 JVM

AEM 索引问题

索引问题症状

以下迹象表明 AEM/Oak 索引存在问题:

  • 搜索结果滞后 10 分钟以上
  • 缺少搜索结果
  • 通过网站 UI 进行搜索、查询生成器搜索或执行 JCR 查询期间在 UI 或日志中返回错误
诊断索引问题
  • 要确定异步索引是否缓慢或失败,请执行以下操作:

1. 在您的 AEM 实例上打开这些 URL 以查看有关异步索引器的统计信息

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  - 此 URL 仅适用于 AEM 6.2 和更高版本

2. 在其中每个页面上,检查以下字段:

FailingSince - 此字段指示索引首次开始失败的时间。

LastError - 此字段是堆栈跟踪信息,显示导致索引失败的原因。如果此字段为空,则表示索引未曾失败。

LastErrorTime - 此字段指示索引最后一次引发错误的时间。

LastIndexedTime - 如果此字段的日期和时间超过 5 分钟,则说明索引运行过于缓慢。

导致索引问题的原因

  • 不正确的维护或无法执行维护,如修订版本垃圾收集、工作流清除、审核清除、版本清除,等等
  • Tar 存储器中的区段损坏或缺失
  • 群集环境中的修订版损坏(DocumentNodeStore - Mongo 或数据库)
  • 群集环境中的群集拓扑存在问题

如何分析导致索引问题的原因

  • 有关分析和修复索引问题的信息,请参阅本文

复制问题

复制问题症状

  • Publish 请求在复制代理队列中排队
  • 发布的内容并未显示在 Publish 服务器上
  • 影响系统性能

导致复制问题的原因:

  • 复制代理配置错误,并且无法连接到 Publish 代理
  • 复制时发生导致复制队列卡滞的错误
  • 系统运行缓慢,复制处理速度慢
  • 复制过程在自定义工作流中进行,因此问题出自工作流处理。

如何分析复制问题:

1. 检查复制队列状态

        活动:项目正在进行处理时。
        空闲:队列为空时。
        已阻止:项目处于队列中,但无法得到处理时;例如,当代理指向关闭或不存在的主机时。

2. 如果已克隆服务器或者最近已配置了代理,请查看复制配置。有关详细信息,请参阅此处。 
     
3. 查看位于 http://host:port/etc/replication/agents.author/AgentName.log.html#end 的复制代理日志记录。如果无法识别任何项目,请收集此日志记录并将其提交给 AEM 支持。

4. 查看 AEMinstall/crx-quickstart/logs 中的服务器 error.log;如果无法识别任何项目,请收集此日志记录并将其提交给 AEM 支持。

5. 如果复制队列处于“空闲”状态并且上述情况均不适用,则在这种情况下,该问题很可能是由工作流所致。如果未处理工作流,那么复制项将永远不会列入复制队列中。要监测工作流的状态,可以检查工作流功能板以查看正在运行的工作流实例的数量。您可以在此处阅读有关管理工作流的内容。

6. 当系统处于高负载状态或遇到其他性能问题时,复制速度会减慢。

常见复制问题的解决方案:

1) 查看复制队列问题
2) 如果问题由工作流未能高效运行所致,可以查看并发工作流处理提示
3) 对于与 AEM 整体性能降低和复制有关的问题,可以查看 AEM 性能问题

TarMK 损坏问题

TarMK 损坏问题症状

  • 实例在脱机压缩后不可操作。
  • 实例停留在正在启动状态。
  • 日志文件或压缩命令输出报告 SegmentNotFoundException

导致损坏问题的原因

  • 通过手动操作(例如 rm -rf)删除了该区段。   
  • 通过修订版本垃圾收集删除了区段,或者由于代码中存在某些错误而无法找到区段。   
  • 由于代码中存在某些错误而无法找到区段。
  • 各种维护任务没有按时执行,导致存储库数据增加和磁盘空间不足。
  • 通过终止 java 进程来强制停止 AEM。

诊断存储库损坏问题:

  • 查看 error.log 文件,检查是否存在 SegmentNotFoundExceptionIllegalArgument Exception
  • 要确定是否通过修订版本垃圾收集删除了区段,请检查 org.apache.jackrabbit.oak.plugins.segment.file.TarReader-GC(启用调试日志)日志记录器的输出。该记录器记录了在清除阶段删除的所有区段的区段 ID。只有当违规区段 ID 出现在该记录器的输出中时,修订版本垃圾收集才会导致异常。
  • 如果外部数据存储损坏,请搜索日志文件,查找错误“获取 blobId 的 InputStream 时发生错误”的所有匹配项。此错误表示 AEM 数据存储目录中缺少文件。

修复损坏问题的解决方案:

  • 使用 Oak-Run 的 check 运行模式来确定区段存储的最后一个已知良好的版本。手动将损坏的区段存储还原到其最新的良好版本。此操作会将 Oak 存储库及时还原到之前的状态。在执行此操作前,应该完全备份存储库。
    • 要执行检查和恢复,请按照本文中描述的步骤操作。
    • 如果检查失败并显示 ConsistencyChecker - 未发现良好的修订版本,则执行本文 B 部分中的步骤。
  • 如果您已经在使用数据存储,并且遇到错误“获取 blobId 的 InputStream 时发生错误”,则表示数据存储中可能缺失文件。请按照本文解决问题。
  • 如果没在使用数据存储,则使用外部文件、S3 或 Azure 数据存储,而不是默认的区段存储
    • 使用数据存储可提高性能。
    • 使用 crx2oak 将实例迁移到具有数据存储的实例。
  • 应用最新的 Service Pack 和累积修复包以及 Oak 累积修复包。

本产品经 Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License 许可  Twitter™ 与 Facebook 中的内容不在 Creative Commons 的条款约束之下。

法律声明   |   在线隐私策略