AEM 6.x | 성능 조정 팁

작성자 및 게시 인스턴스 모두에서 사실적인 시나리오를 시뮬레이션하는 로드 테스트를 구현하고 실행합니다. 예상되는 부하를 조사하고 정의하는 것은 이 과정에서 중요한 단계이다. 이 단계는 프로덕션 환경에서 AEM 애플리케이션, 아키텍처 및 AEM 설치가 제대로 수행되는지 여부를 보여 주는 데 도움이 됩니다.
이 연습 결과를 통해 구성 오류, 애플리케이션 문제, 크기 조정, 하드웨어 문제 또는 시스템 성능에 영향을 미치는 기타 문제가 있는지 확인할 수 있습니다. 성능 지침 및 모니터링 지침도 참조하세요.

부하 테스트 외에도 부하 테스트는 시스템이 처리할 수 있는 최대 부하를 정의하는 데 도움이 됩니다. 이 테스트는 트래픽 스파이크에 대비하는 데 도움이 될 수 있습니다. 성능 테스트에 대한 자세한 내용은 여기를 참조하십시오.

권장 AEM 서비스 팩, 누적 수정 팩 및 핫픽스를 설치합니다. Adobe Experience Manager 릴리스 업데이트.

Windows 서버를 사용하는 경우 이 문서를 검토하십시오.

대량의 에셋(이미지, 비디오 등)을 AEM에 로드하려는 경우 Assets 모범 사례를 적용하십시오.

충분한 RAM을 프로비저닝하고 IO 포화 방지
어떤 규모에서든 프로덕션을 실행하려는 경우 Linux 환경은 세그먼트 tar 파일이 오프라인 압축(또는 온라인 압축 최고점) 사이까지 증가하는 만큼의 RAM으로 프로비저닝되어야 합니다. 또한 다음은 IO 포화를 방지합니다.

• 별도의 OS, 데이터 및 로깅 디스크
• Noatime으로 데이터 디스크를 마운트합니다.
• 데이터 디스크에서 미리 읽기 버퍼를 32로 설정합니다.
• 데이터 디스크에서 ext4를 통해 XFS를 사용하는 것이 좋습니다.
• RedHat이 VM에서 실행 중인 경우 엔트로피 풀이 항상 > 1K 비트인지 확인하십시오(필요한 경우 rngtools 사용).

Linux에서 투명한 대용량 페이지 비활성화
AEM은 세분화된 읽기/쓰기를 수행하지만 Linux 투명 대용량 페이지는 대규모 작업에 최적화되어 있으므로 Mongo 또는 Tar 저장소를 사용할 때는 투명 대용량 페이지를 비활성화하는 것이 좋습니다.

임시 워크플로우 활성화
임시 워크플로우는 다음과 같은 모든 워크플로에 사용할 수 있습니다.

• 를 자주 실행합니다.
• 워크플로우 내역은 필요하지 않습니다.

이러한 상황에서는 성능이 향상됩니다.
이 사용 사례는 일반적으로 자산 수집이 많을 때 충족됩니다.
성능 조정 Assets에 설명된 절차를 따르십시오.

Sling 작업 큐 조정
대용량 에셋의 일괄 업로드는 일반적으로 리소스를 많이 사용하는 프로세스입니다. 기본적으로 작업 큐당 동시 스레드 수는 CPU 코어 수와 같습니다. 따라서 이 값 설정은 전체 성능에 영향을 주고 높은 Java 힙 소비를 초래할 수 있습니다.
Adobe은 CPU 코어의 50%를 초과하지 않도록 권장합니다. 이 값을 조정하려면 https:/host:port/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration으로 이동하십시오.
AEM 인스턴스를 호스팅하는 서버의 CPU 코어의 50%를 나타내는 값으로 queue.maxparallel을(를) 설정합니다. 예를 들어 8개의 CPU 코어에 대해 값을 4로 설정합니다.

Oak 저장소 조정
먼저 AEM 6 인스턴스에 대해 최신 Oak 버전이 설치되어 있는지 확인하십시오. 위에서 언급한 권장 핫픽스 페이지를 확인하십시오.

Oak 쿼리 엔진/인덱스 최적화

• 자주 사용하는 모든 검색 쿼리에 대해 사용자 지정 oak 색인을 만듭니다.

  • 느린 쿼리를 분석하는 방법에 대한 자세한 내용은 이 article을(를) 참조하십시오.
  • 이 article을(를) 따라 검색할 모든 검색 속성에 대한 사용자 지정 색인을 oak:index 노드 아래에 만듭니다.
  • 각 사용자 정의 Lucene 기반 인덱스에 대해 includedPaths(문자열) 설정을 설정하여 특정 콘텐츠 경로에만 적용되도록 인덱스를 제한해 보십시오. 그런 다음 적용 가능한 검색을 색인에 포함된 경로로 제한합니다.

• JVM 매개 변수
  AEM 시작 스크립트에서 이러한 JVM 매개변수를 추가하여 확장 쿼리가 시스템을 오버로드할 수 없도록 합니다. AEM 6.3부터 기본값이 됩니다.

  • Doak.queryLimitInMemory=500000(Oak 설명서 참조)
  • Doak.queryLimitReads=100000(Oak 설명서 참조)
  • Dupdate.limit=250000 (예: DocumentNodeStore에만 해당). MongoMK, RDBMK)

  다음 옵션을 사용하면 성능이 향상될 수도 있지만 결과 크기 호출의 의미가 변경됩니다. 특히, 크기를 계산할 때는 사용된 색인에 속하는 쿼리 제한만 고려합니다.
  또한 ACL은 결과에 적용되지 않으므로 현재 세션에 표시되지 않는 노드는 반환된 카운트에 포함됩니다. 따라서 반환되는 카운트는 실제 결과 수보다 높을 수 있으며 정확한 카운트는 다음 결과를 반복해야만 확인할 수 있습니다.

  • Doak.fastQuerySize=true(Oak 설명서의 결과 크기 참조)

  주의: fastQuerySize ​을(를) 사용하면 쿼리 응답 속도가 빨라집니다. 그러나 AEM은 일부 쿼리에 대해 부정확한 결과 수를 반환합니다. 응용 프로그램에서 정확한 결과 수를 사용하는 경우 fastQuerySize ​을(를) 사용하지 마십시오.

• Lucene 인덱스 구성
  /system/console/configMgr/org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService 를 열고

  • CopyOnRead 사용(AEM 6.2 이후 기본적으로 활성화됨)
  • CopyOnWrite 사용(AEM 6.2 이후 기본적으로 활성화됨)
  • 인덱스 파일 미리 가져오기 사용(AEM 6.2 이후 기본적으로 활성화됨)

  사용 가능한 매개 변수에 대한 자세한 내용은 https://jackrabbit.apache.org/oak/docs/query/lucene.html을(를) 참조하십시오
  일부 경로는 색인화할 필요가 없으므로 다음과 같이 할 수 있습니다.
  CRXDE Lite에서 /oak:index/lucene로 이동하여 excludedPaths라는 다중 값 문자열 속성(문자열)을 /var, /etc/workflow/instances, /etc/replication 값으로 설정합니다.

• 데이터 저장소
  AEM Assets을 사용하거나 이진 파일을 광범위하게 사용하는 AEM Adobe 애플리케이션이 있는 경우 외부 데이터 저장소를 사용하는 것이 좋습니다. 외부 데이터 저장소를 사용하면 최대 성능을 보장할 수 있습니다. 자세한 지침은 설명서를 참조하세요.
  FileDataStore를 사용하는 경우 cacheSizeInMB를 사용 가능한 힙의 백분율로 튜닝합니다. 보존적 값은 최대 힙의 2%입니다. 예를 들어 8GB 힙의 경우:

  • maxCachedBinarySize=1048576
  • cacheSizeInMB=164

  maxCachedBinarySize 이(가) 1MB(1048576)로 설정되어 있습니다. 따라서 최대 1MB의 파일만 캐시합니다. 이 설정을 더 작은 값으로 조정하는 것도 적절할 수 있습니다.
  많은 수의 바이너리를 처리할 때는 성능을 최대화해야 합니다. 따라서 Adobe은 기본 노드 저장소 대신 외부 데이터 저장소를 사용할 것을 권장합니다. Adobe 또한 다음 매개 변수를 조정하는 것이 좋습니다.

  • maxCachedBinarySize=10485760
  • cacheSizeInMB=4096

  참고: cacheSizeInMB 설정으로 인해 Java 프로세스가 너무 높게 설정된 경우 메모리가 부족할 수 있습니다. 예를 들어 최대 힙 크기를 8GB(-Xmx8g)로 설정하고 AEM과 애플리케이션이 총 4GB의 힙을 활용할 것으로 예상하는 경우 cacheSizeInMB를 164가 아닌 82로 설정하는 것이 적절합니다. 최대 힙의 2~10% 범위에는 안전한 구성이 있습니다. 그러나 Adobe은 메모리 사용률을 모니터링하면서 로드 테스트를 통해 설정 변경 사항의 유효성을 검사하는 것을 권장합니다.

Mongo 스토리지 튜닝

• MongoBlobStore 캐시 크기: Blobstore는 큰 이진 개체를 저장하고 읽는 데 사용됩니다. 내부적으로 캐시가 있는 저장소는 각 블록이 메모리에 맞도록 비교적 작은 블록(데이터 또는 해시 코드 또는 간접 해시)으로 바이너리를 분할하는 기능을 구현합니다. 기본 설정에서 MongoBlobStore는 16MB의 고정 캐시 크기를 사용합니다. 더 많은 RAM을 사용할 수 있고 Blob 저장소에 자주 액세스하는 배포의 경우(예: Lucene 인덱스가 큰 경우) 캐시 크기를 늘리십시오. 이 캐시 크기는 외부 blob 저장소를 사용할 때가 아니라 MongoBlobStore(기본값)를 사용할 때만 적용됩니다.

  • DocumentNodeStoreService의 blobCacheSize 설정을 통해 캐시 크기(MB)를 구성할 수 있습니다.
    예: blobCacheSize=1024
  • AEM-MongoDB 검사 목록도 검토하십시오.

• 문서 캐시 크기: MongoDB에서 노드 읽기 성능을 최적화하려면 DocumentNodeStore의 캐시 크기를 조정해야 합니다. 캐시의 기본 크기는 256MB로 설정되며, 이 크기는 DocumentNodeStore에서 사용되는 다양한 캐시에 분산됩니다. http://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html#cache 보기

  • DocumentNodeStoreService의 캐시 설정을 통해 캐시 크기(MB)를 구성할 수 있습니다. 예를 들어 cache=2048입니다.

  • crx-quickstart/install/org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.configure에서 다음 캐시 구성을 모두 설정한 다음 다양한 값으로 테스트를 로드하여 환경에 가장 적합한 구성이 무엇인지 확인하십시오. 나머지 캐시 퍼센트는 문서 캐시에 제공됩니다.

    • cache=2048
    • nodeCachePercentage=35
    • childrenCachePercentage=20
    • diffCachePercentage=30
    • docChildrenCachePercentage=10

  • 위의 구성에서 백분율은 총 95%입니다. 나머지 5%의 캐시는 documentCache에 제공됩니다. documentCache = cache - nodeCache - childrenCache - diffCache - docChildrenCache

  • 캐시 백분율을 배포하는 동안 documentCache에 대한 캐시가 그리 크지 않은지 확인하십시오. 즉, 최대 500MB 이하로 유지합니다. 문서가 크면 캐시 무효화를 수행하는 데 걸리는 시간이 늘어날 수 있습니다.

• AEM 6.2의 캐시 설정(Oak 1.4.x 포함):

  • AEM 6.2에서는 이러한 캐시 설정이 작동하는 방식이 변경되었습니다. AEM 6.2(Oak 1.4 포함)에는 새 캐시 prevDocCache가 있습니다. prevDocCachePercentage 설정을 사용하여 이 캐시를 구성할 수 있습니다. 기본값은 4입니다.
  • documentCache는 나머지 캐시 MB(캐시 설정에서 다른 모든 캐시의 크기를 뺀 값)를 사용합니다. documentCache = cache - nodeCache - childrenCache - diffCache - docChildrenCache - prevDocCache

• MongoDB 프로덕션 검사 목록 구현:
  https://docs.mongodb.org/manual/administration/production-checklist/ - Mongo DB 지원에 따르면 많은 항목이 성능에 큰 영향을 줍니다. 문의 사항은 MongoDB 지원 센터에 직접 문의하십시오.

• 성능 읽기: 이 쿼리 문자열 매개 변수를 각 AEM 노드의 Mongo DB URL에 추가하십시오. ?readPreference=secondaryPreferred
  이 매개 변수는 시스템에서 보조 시스템에서 읽기를 수행하도록 지시하여 읽기 성능을 어느 정도 추가합니다.

• oak 관찰에 대한 스레드 풀 늘리기: /system/console/configMgr/org.apache.sling.commons.threads.impl.DefaultThreadPool.factory 열기 이름을 oak-observation으로 설정하고 최소 및 최대 풀 크기를 20으로 설정합니다.

• 관찰 큐 길이 늘이기: 매개 변수 oak.observation.queue-length=50000 ​을(를) 포함하는 com.adobe.granite.repository.impl.SlingRepositoryManager.cfg ​라는 파일을 만듭니다. /crx—quickstart/install 폴더 아래에 놓습니다.

• 오래 실행되는 쿼리 방지: 1분 이상 실행되는 쿼리를 방지하려면 JVM 매개 변수 -Doak.mongo.maxQueryTimeMS=60000 ​에서 시스템 속성을 설정하십시오.

Tar 스토리지 조정
마이크로커널은 메모리 매핑 파일을 직접 호출하지 않습니다. 그러나 JDK는 효율적인 읽기를 위해 내부적으로 메모리 매핑 파일을 사용합니다. 특정 Windows 64비트 운영 체제에서 메모리 매핑 파일을 정리하지 못하고 모든 기본 OS 메모리를 사용할 수 있습니다. Microsoft의 성능 관련 패치/핫픽스(KB 2731284 참조) 및 Oracle을 설치하십시오.

다른 방법은 운영 체제 문제가 해결될 때까지 SegmentNodeStoreService.config에서 tarmk.mode=32 ​을(를) 추가하여 메모리 맵 모드를 비활성화하는 것입니다. 비활성화의 단점은 I/O를 집중적으로 만듭니다. I/O 페이지 잠금 제한을 높여야 합니다.

TarMK 수정 정리(압축)
AEM 6.3부터 온라인 압축(온라인 개정 정리라고도 함)이 기본적으로 활성화됩니다. 자세한 내용은 이 페이지를 참조하세요.

Adobe Managed Services(AMS) 사용자용 Cloud Manager
Cloud Manager(AMS 사용자만 해당)에서는 안내가 있는 성능 테스트 및 자동 크기 조정을 통해 AEM 배포를 성공적으로 수행할 수 있습니다.