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

가장 일반적인 중요한 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 유지 관리에 대한 자세한 내용 및 AEM에서 다음을 포함한 유지 관리를 제대로 수행하고 있는지 확인하십시오.

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

  6. 사이트 검토 캐싱.

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

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

  • 을(를) 참조하십시오 이 문서 성능을 최적화하는 방법에 대한 자세한 단계입니다.
  • 리뷰 성능 조정 팁

자산 성능 문제

자산 성능 문제의 증상

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

자산 성능에 문제가 발생하는 원인

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

자산 성능 문제를 분석하는 방법

일반적인 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 최종 종료자가 쌓입니다.
  • 최대 힙 구성 부족

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

다음을 참조하십시오 이 문서 힙 덤프를 캡처하는 방법에 대한 자세한 정보.

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

힙 덤프 파일을 캡처한 다음에서 엽니다. 이클립스 매트 또는 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  - This URL은 AEM6.2 이상에만 적용됩니다.

  2. 이러한 각 페이지에서 다음 필드를 선택합니다.

    다음 이후 실패  - 인덱싱이 처음 실패한 시점을 나타냅니다.

    마지막 오류  - 인덱싱의 실패를 초래하는 원인을 보여주는 스택 추적입니다.  비어 있는 경우 인덱싱이 실패하지 않습니다.

    마지막 오류 시간  - 인덱싱에서 오류가 마지막으로 발생한 시간을 나타냅니다.

    LastIndexedTime  - 이 필드의 날짜 및 시간이 5분 이상 지난 경우 인덱싱이 너무 느리게 실행됩니다.

색인화와 관련된 문제의 원인

  • 잘못된 유지 관리 또는 개정 가비지 수집, 워크플로우 삭제, 감사 삭제, 버전 삭제 등의 유지 관리 수행 실패
  • Tar 저장소에서 세그먼트가 손상되거나 누락됨
  • 클러스터된 환경에서 수정 버전 손상(DocumentNodeStore - Mongo 또는 데이터베이스)
  • 클러스터된 환경의 클러스터 토폴로지 문제

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

  • 다음을 참조하십시오 이 문서 색인 지정 문제 분석 및 해결

복제 문제


복제 문제의 증상

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

복제 문제의 원인:

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

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

  1. 복제 큐 확인 상태:

    활성:  항목이 처리되는 경우입니다.

    유휴 상태:  큐가 비어 있는 경우.

    차단됨:  항목이 큐에 있지만 처리할 수 없는 경우(예: 에이전트가 작동 중지 또는 존재하지 않는 호스트를 가리킬 때).

  2. 서버가 복제되었거나 에이전트가 최근에 구성된 경우 복제 구성을 검토하십시오. 자세한 내용은 여기.

  3. 다음 위치에서 복제 에이전트 로그를 검토합니다.  http://host:port/etc/replication/agents.author/AgentName.log.html#end.  항목을 식별할 수 없는 경우 이 로그를 수집하여 AEM 지원에 표시합니다.

  4. 다음에서 서버 error.log 검토:  AEMinstall/crx-quickstart/logs: 항목을 식별할 수 없는 경우 이 로그를 수집하여 AEM 지원에 표시합니다.

  5. 복제 큐가 "유휴" 상태이고 위의 어느 것도 적용되지 않는 경우, 이 경우 워크플로가 문제를 일으킬 가능성이 높습니다. 워크플로우가 처리되지 않는 경우 복제 항목이 복제 큐에 도달하지 않습니다. 워크플로우의 상태를 모니터링하려면 워크플로우 대시보드를 확인하여 실행 중인 워크플로우 인스턴스의 수를 확인할 수 있습니다. 워크플로우 관리에 대해 읽어볼 수 있습니다 여기.

  6. 시스템 로드가 높거나 다른 성능 문제가 발생하면 복제 속도가 느려집니다.

일반적인 복제 문제에 대한 솔루션:

  1. 복제 큐 문제 검토.
  2. 워크플로우가 효율적으로 실행되지 않아 문제가 발생한 경우 동시 실행을 검토할 수 있습니다 워크플로우 처리 팁.

TarMK 손상 문제


TarMK 손상의 증상

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

손상 문제의 원인

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

저장소 손상 문제 진단:

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

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

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

    • 확인 및 복원을 수행하려면 다음 단계를 따르십시오. 이 문서.
    • 검사가 실패하고  ConsistencyChecker - 양호한 수정 버전 없음  그런 다음 의 파트 B에 있는 단계를 구현합니다. 이 문서.
  • 데이터 저장소를 사용하지 않는 경우 기본 segmentstore 대신 외부 파일 S3 또는 Azure 데이터 저장소를 사용합니다.

    • 데이터 저장소를 사용하면 성능이 향상됩니다.
    • 다음을 사용하여 인스턴스를 데이터 저장소가 있는 인스턴스로 마이그레이션 crx2oak.
  • 최신 서비스 팩 및 누적 수정 팩 과 Oak 누적 수정 팩 을 적용합니다.

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