목표

이 문서에서는 가장 일반적인 중요한 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. OS 수준에서 높은 CPU 사용률의 원인이 AEM java 프로세스인지 확인

    Linux: top 명령을 사용하여 CPU 사용률을 확인합니다.

    Window: Windows 작업 관리자를 사용합니다.

    높은 CPU 사용률의 원인이 AEM이면 몇 분 동안 즉시 사용할 수 있는 프로파일링 도구를 실행하고 결과를 분석합니다.

3. 느린 요청에 대해 request.log 파일 분석

4. 시스템 유지 관리 절차를 검토하고, 다음을 포함하여 AEM에서 적절한 유지 관리를 수행하고 있는지 확인

  • 수정 버전 정리(MongoMK 및 데이터베이스 DocumentNodeStore 전용) - 매일 또는 더 자주
  • 오프라인 Tar 압축(TarMK만 해당) - 격주
  • 데이터 저장소 가비지 컬렉션(FileDataStore 또는 S3 데이터 저장소가 있는 시스템만 해당) - 매주
  • 작업 과정 제거 - 매주
  • 버전 제거 - 매주
  • 감사 로그 제거 - 매주

이에 대한 자세한 내용은 이 문서를 참조하십시오.

5. AEM 디스패처 수준에서 구현된 캐싱 전략 검토  우선 디스패처가 파일을 캐시하고 캐시된 파일을 무효화하는 시기와 방법을 이해하는 것이 좋습니다.

6. 사이트의 캐싱 검토

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

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

  • 성능을 최적화하는 방법에 대한 자세한 절차에 대해서는 이 문서를 참조하십시오.
  • 성능 조정 팁 검토

AEM Assets 성능 문제

자산 성능 문제의 증상

  • /assets.html 또는 /damadmin UI에 파일 업로드 속도가 느림
  • 축소판이 너무 길어서 생성되지 않음
  • 이동, 삭제, 편집 및 메타데이터 업데이트와 같은 자산 작업이 너무 오래 걸림

자산 성능 문제의 원인

  • 적절한 유지 관리 부족
  • 최신 수정 팩이 적용되지 않음
  • 최적화가 적용되지 않음
  • 사용자 로드에 대한 서버 크기 조정이 부적절함

자산 성능 문제 분석 방법

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

메모리 문제

메모리 문제의 증상

  • AEM이 임의로 충돌하고 로그에서 OutOfMemoryError가 발견됨
  • AEM이 시간이 지남에 따라 느려지고 결국 충돌함
  • AEM이 응답하지 않음

메모리 문제 진단

  • 로그 파일에서 OutOfMemoryError를 검색하여 일치하는 항목이 있으면 메모리 문제가 있는 것입니다.
  • http://aem-host:port/system/console/memoryusage 화면 검토
    "Old Generation"(JDK 7 및 이전 버전) 또는 "Tenured Generation"(JDK8 이상) 사용량이 많은 경우 힙 메모리 사용의 문제를 의미할 수 있습니다.  "가비지 컬렉터 실행"을 클릭하여 JVM에 전체 힙 가비지 컬렉션을 실행하도록 요청합니다.  GC를 요청한 후 힙 사용률이 높게 유지되면 문제가 있는 것입니다.  Oak Tar 스토리지가 있는 AEM 인스턴스에서 Tenured 사용량이 3GB를 초과하면 문제가 있는 것입니다.  Mongo 스토리지가 있는 시스템에서 힙 사용률이 높은 것은 메모리 내 캐시 구성 때문일 수 있습니다.
  • 스레드 덤프와 맨 위 출력을 가져와서 스레드 분석을 수행합니다.  CPU 사용률이 높은 스레드가 기본 JVM 가비지 컬렉션 스레드인지 확인합니다.  대부분의 CPU 시간을 사용하는 스레드가 "VM 스레드" 또는 가비지 컬렉션 스레드인 경우 메모리 문제가 있을 수 있습니다.

메모리 문제의 원인

  • Java 응용 프로그램 메모리 누수
  • 사용자 정의 코드에서 finalize를 잘못 사용하여 Java Finalizer가 쌓임
  • 최대 힙 구성 부족

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

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

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

힙 덤프 파일을 캡처한 후 Eclipse MAT 또는 IBM Memory Analyzer 도구에서 엽니다.  Eclipse MAT에서 Leak Suspects 보고서를 실행하고 "Thread Details" 보기를 열어 잠재적 메모리 문제의 원인을 확인합니다.

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

  • 오래 동안 가비지 컬렉션이 일시 정지된 경우 메모리를 적게 사용하도록 응용 프로그램 코드를 최적화합니다.  대부분의 가비지 컬렉션 문제는 응용 프로그램을 최적화와 JVM 조정을 통해 가장 잘 해결할 수 있습니다.
  • 응용 프로그램을 이미 최적화했지만 여전히 GC가 오래 동안 일시 정지되면 JVM 조정에 중점을 둡니다.

AEM 색인화 문제

색인화 문제의 증상

다음은 AEM/Oak 색인화에 문제가 있음을 나타냅니다.

  • 검색 결과가 10분 이상 오래됨
  • 검색 결과가 누락됨
  • 사이트 UI, QueryBuilder 검색 또는 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은 AEM6.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에서 server error.log를 검토합니다. 항목을 식별할 수 없을 경우에는 이 로그를 수집하고 AEM 지원 부서에 제공하십시오.

5. 복제 대기열이 "유휴" 상태이고 위의 내용 중 어느 것도 적용되지 않는다면, 이경우문제는 대개 작업 과정으로 인해 초래될 수 있습니다. 작업 과정이 처리되고 있지 않으면 복제 항목이 복제 대기열에 도착하지 않습니다. 작업 과정의 상태를 모니터하기 위해 작업 과정 대시보드를 확인하여 실행 중인 작업 과정 인스턴스 수를 확인할 수 있습니다. 여기에서 작업 과정 관리에 대해 읽을 수 있습니다.

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

일반적인 복제 문제에 대한 해결 방법:

1) 복제 대기열 문제 검토
2) 효율적으로 실행되지 않는 작업 과정으로 인해 문제가 있는 경우 동시 작업 과정 처리 팁 검토
3) 전체 AEM의 느린 성능 및복제와관련된 문제의 경우 AEM 성능 문제를 검토할 수 있습니다.

TarMK 손상 문제

TarMK 손상의 증상

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

손상 문제의 원인

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

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

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

손상 문제를 복구하는 해결 방법:

  • oak-run의 검사 실행 모드를 사용하여 세그먼트 저장소의 마지막으로 알려진 수정 버전을 판별하십시오.  손상된 세그먼트 저장소를 수동으로 최근의 양호한 수정 버전으로 되돌리십시오. 이 작업은 Oak 리포지토리를 늦지 않게 이전 상태로 되돌립니다.  이 작업을 수행하려면 먼저 리포지토리를 완전히 백업해야 합니다.
    • 확인 및복원을수행하려면 이 문서에 언급된 절차를 수행하십시오.
    • 확인이 실패하고 ConsistencyChecker - 양호한 수정 버전이 없음이 표시되면 이 문서의 B 부분에 있는 절차를 구현합니다.
  • 데이터 저장소를 이미 사용 중이고 "blobId용 InputStream을 가져오는 동안 오류가 발생했습니다"라는 오류가 발생하면 데이터 저장소에 누락된 파일이 있을 수 있습니다. 이 문제를 해결하려면 이 문서를 따르십시오.
  • 데이터 저장소를 사용하지 않는다면 기본 segmentstore 대신 외부 파일, S3 또는 Azure 데이터 저장소를사용하십시오.
    • 데이터 저장소를 사용하면 성능이 향상됩니다.
    • crx2oak를 사용하여 인스턴스를 데이터 스토어로 마이그레이션하십시오.
  • 최신 서비스 팩 및 누적 수정 팩 및 Oak 누적 수정 팩을 적용합니다.

이 작업에는 Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License의 라이센스가 부여되었습니다.  Twitter™ 및 Facebook 게시물은 Creative Commons 약관을 적용받지 않습니다.

법적 고지 사항   |   온라인 개인 정보 보호 정책