설명서

일반적인 중요한 AEM 문제를 분석하는 방법

Last update: Fri Sep 12 2025 00:00:00 GMT+0000 (Coordinated Universal Time)

가장 일반적인 중요한 AEM 문제와 이를 분석하는 방법에 대해 알아봅니다.

설명 description

환경

AEM (Adobe Experience Manager)

문제/증상

이 문서에서는 가장 일반적인 중요한 AEM 문제 및 이를 분석하는 방법에 대해 설명합니다.

  • AEM Sites 성능
  • AEM Assets 성능
  • 메모리 문제
  • 색인 지정 문제
  • 복제 문제
  • TarMK 손상 문제

해결 방법 resolution

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 사용률이 높은지 OS 수준에서 확인합니다. AEM으로 인해 CPU 사용률이 높은 경우 몇 분 동안 기본 제공 프로파일링 도구를 실행하고 결과를 분석합니다.

    • Linux: top 명령을 사용하여 CPU 사용률을 확인합니다.
    • 창: Windows 작업 관리자 사용

  3. 느린 요청에 대해 request.log 파일을 분석합니다.

  4. 시스템 유지 관리 절차를 검토합니다. AEM 유지 관리에 대한 자세한 내용은 이 article을(를) 참조하여 AEM에서 다음을 포함한 유지 관리를 제대로 수행하고 있는지 확인하십시오.

    • 개정 정리(MongoMK 및 데이터베이스 DocumentNodeStore만 해당) - 매일 또는 더 자주
    • 오프라인 Tar 압축(TarMK만 해당) - 격주
    • 데이터 저장소 가비지 수집(FileDataStore 또는 S3 DataStore만 있는 시스템) - 주별
    • 워크플로우 삭제 - 주별
    • 버전 삭제 - 주별
    • AuditLog 제거 - 주별

  5. AEM 디스패처 수준에서 구현된 캐싱 전략을 검토하십시오.

  6. 사이트의 캐싱을 검토합니다.

  7. Google Chrome 브라우저 개발자 도구 패널의 감사 기능과 같은 클라이언트측 사이트 분석 도구를 사용합니다. 이러한 도구는 클라이언트측 성능 향상에 대한 권장 사항을 제공합니다.

일반적인 성능 문제에 대한 해결 방법

Assets 성능 문제

Assets 성능 문제의 증상

  • /assets.html 또는 /damadmin UI로 파일 업로드가 느림
  • 썸네일을 생성하는 데 시간이 너무 오래 걸립니다.
  • 이동, 삭제, 편집 및 메타데이터 업데이트와 같은 Assets 작업에 너무 오래 걸림

Assets 성능에 문제가 발생하는 이유

  • 적절한 유지 보수 부족
  • 최신 수정 팩이 적용되지 않음
  • 최적화가 적용되지 않음
  • 사용자 로드에 적합하지 않은 서버 크기 조정

Assets 성능 문제를 분석하는 방법

일반적인 Assets 성능 문제에 대한 솔루션

메모리 문제

메모리 문제의 증상

  • AEM이 임의로 충돌하며 OutOfMemoryError 로그가 관찰됩니다
  • AEM은 시간이 지남에 따라 속도가 느려지고 결국 충돌합니다
  • AEM이 응답하지 않음

메모리 문제 진단

  • 로그 파일에서 OutOfMemoryError를 검색합니다. 일치하는 항목이 있으면 메모리에 문제가 발생합니다

  • http://aem-host:port/system/console/memoryusage 화면 검토

    "이전 세대"(JDK 7 및 이전) 또는 "확장 세대"(JDK8 이상) 사용량이 많은 경우 힙 메모리 사용 문제의 징후일 수 있습니다. JVM에서 전체 힙 가비지 수집을 실행하도록 요청하려면 "가비지 수집기 실행"을 클릭합니다. GC를 요청한 후 높은 힙 사용률이 계속 높은 경우 문제가 발생할 수 있습니다. Oak Tar 스토리지가 있는 AEM 인스턴스의 경우 지속되는 사용량이 3GB보다 크면 문제가 발생할 수 있습니다. Mongo 스토리지가 있는 시스템의 높은 힙 사용률은 인메모리 캐시 구성 때문일 수 있습니다.

  • 스레드 덤프와 상위 출력을 가져오고 스레드 분석을 수행합니다. CPU 사용률이 높은 스레드가 기본 JVM 가비지 수집 스레드인지 확인합니다. 가장 많은 CPU 시간을 사용하는 스레드가 "VM 스레드" 또는 가비지 수집 스레드인 경우 메모리 문제가 발생할 수 있습니다.

메모리 문제 원인

  • Java 응용 프로그램 메모리 누수
  • 사용자 지정 코드에서 최종 작업을 잘못 사용했기 때문에 Java 최종 종료자가 쌓입니다.
  • 최대 힙 구성 부족

메모리 문제의 원인을 분석하는 방법

힙 덤프를 캡처하는 방법에 대한 자세한 내용은 이 문서를 참조하십시오.

메모리 문제의 원인을 식별하는 가장 좋은 방법은 힙 덤프를 분석하는 것입니다.

힙 덤프 파일을 캡처한 후 Eclipse MAT 또는 IBM 메모리 분석기 도구에서 엽니다. Eclipse MAT에서 Leak Suspect 보고서를 실행하고 "스레드 세부 정보" 보기를 열어 메모리 문제에 대한 잠재적 원인을 확인합니다.

일반적인 메모리 문제에 대한 해결 방법

  • 긴 가비지 수집 일시 중지가 표시되면 메모리를 적게 사용하도록 애플리케이션 코드를 최적화합니다. 대부분의 가비지 수집 문제는 JVM을 조정하는 것과 비교하여 애플리케이션을 최적화하여 가장 잘 해결할 수 있습니다.
  • 이미 응용 프로그램을 최적화하고 긴 GC 일시 중지가 발생하는 경우 JVM 조정에 집중하십시오.

AEM 색인화 문제

인덱싱 문제의 증상

다음은 AEM/Oak 색인화와 관련된 문제의 징후입니다.

  • 검색 결과가 10분 이상 오래된 경우
  • 검색 결과가 없습니다.
  • 사이트 UI, Query Builder 검색 또는 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 또는 데이터베이스)
  • 클러스터된 환경의 클러스터 토폴로지 문제

인덱싱 문제를 일으키는 원인을 분석하는 방법

  • 인덱싱 문제 분석 및 수정은 이 문서을(를) 참조하십시오

복제 문제

복제 문제의 증상

  • 게시 요청이 복제 에이전트 큐에 대기 중입니다.
  • 게시된 콘텐츠가 게시 서버에 표시되지 않습니다.
  • 시스템 성능에 미치는 영향

복제 문제의 원인:

  • 복제 에이전트가 잘못 구성되어 게시 에이전트에 연결할 수 없습니다.
  • 복제 시 오류가 발생하여 복제 큐가 중단됩니다
  • 시스템이 느려지고 복제가 느리게 처리되고 있습니다
  • 복제는 사용자 지정 워크플로의 일부로 발생하고 있으며 문제는 워크플로 처리와 관련이 있습니다.

복제 문제를 분석하는 방법:

  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. 워크플로우가 효율적으로 실행되지 않아 문제가 발생한 경우 동시 워크플로우 처리 팁을 검토할 수 있습니다.

TarMK 손상 문제

TarMK 손상의 증상

  • 오프라인 압축 후에는 인스턴스를 사용할 수 없습니다.
  • 인스턴스가 시작 진행 중 상태에서 중단되었습니다.
  • 로그 파일 또는 압축 명령 출력 보고서 SegmentNotFoundException.

손상 문제의 원인

  • 수동 개입으로 세그먼트가 제거됩니다(예: rm -rf ).
  • 수정 가비지 수집에 의해 세그먼트가 제거되거나 코드의 일부 버그로 인해 세그먼트를 찾을 수 없습니다.
  • 코드의 일부 버그로 인해 세그먼트를 찾을 수 없습니다.
  • 다양한 유지 관리 작업이 제시간에 수행되지 않아 저장소 증가 및 디스크 공간 부족으로 이어집니다.
  • Java 프로세스를 중단하여 AEM을 강제로 중지합니다.

리포지토리 손상 문제 진단:

  • error.log 파일을 검토하고 SegmentNotFoundException 또는 IllegalArgument Exception 이 있는지 확인하십시오.
  • 수정 가비지 수집으로 세그먼트가 제거되었는지 확인하려면 org.apache.jackrabbit.oak.plugins.segment.file.TarReader-GC(디버그 로그 사용) 로거의 출력을 확인합니다. 이 로거는 정리 단계에서 제거된 모든 세그먼트의 세그먼트 ID를 기록합니다. 문제가 되는 세그먼트 ID가 해당 로거의 출력에 표시되는 경우에만 수정 가비지 수집이 예외의 원인입니다.
  • 외부 데이터 저장소에서 손상된 경우 blobId 에 대한 InputStream을 가져오는 동안 모든 오류 발생 항목에 대한 검색 로그 파일이 발생했습니다. 이 오류는 AEM 데이터 저장소 디렉토리에서 파일이 누락되었음을 의미합니다.

손상 문제를 복구하는 솔루션:

  • oak-run의 check 실행 모드를 사용하여 마지막으로 알려진 세그먼트 저장소 수정 버전을 확인합니다. 수동으로 손상된 세그먼트 스토어를 최신 수정 버전으로 되돌립니다. 이 작업을 수행하면 Oak 저장소가 이전 상태로 되돌아갑니다. 이 작업을 수행하기 전에 저장소를 완전히 백업해야 합니다.

    • 확인 및 복원을 수행하려면 이 문서에 언급된 단계를 따르십시오.
    • ConsistencyChecker - 올바른 수정 내용을 찾을 수 없음 을 사용하여 검사에 실패한 경우 이 문서의 B 부분에 있는 단계를 구현합니다.

  • 데이터 저장소를 사용하지 않는 경우 기본 segmentstore 대신 외부 파일 S3 또는 Azure 데이터 저장소를 사용합니다.

    • 데이터 저장소를 사용하면 성능이 향상됩니다.
    • crx2oak을(를) 사용하여 인스턴스를 데이터 저장소가 있는 인스턴스로 마이그레이션합니다.

  • 최신 서비스 팩, 누적 수정 팩 및 Oak 누적 수정 팩을 적용합니다.

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f