AEM 인스턴스 모니터링 및 유지 관리 monitoring-and-maintaining-your-aem-instance

AEM 인스턴스가 배포되면 작업, 성능 및 무결성을 모니터링하고 유지 관리하는 데 특정 작업이 필요합니다.

여기서 중요한 요소는 잠재적인 문제를 인식하기 위해 시스템이 정상적인 조건에서 어떻게 표시되고 동작하는지 알아야 합니다. 이 작업은 시스템을 모니터링하고 일정 기간 정보를 수집하여 수행하는 것이 가장 좋습니다.

백업 backups

다음을 백업하는 것이 좋습니다.

백업 정책을 따라야 할 것이며 백업 대상 및 백업 시기에 대한 추가 고려 사항이 있을 것입니다.

전체 백업은 정기적인 간격(예: 매일, 주별 또는 월별)으로 수행되며, 시간별, 일별 또는 주별 간에 증분 백업을 수행합니다.

소프트웨어 설치 백업 backing-up-your-software-installation

설치 후 또는 구성의 중요한 변경 사항이 발생하면 소프트웨어 설치를 백업하십시오.

이를 위해서는 다음을 수행해야 합니다 전체 저장소 백업 다음을 수행합니다.

리포지토리 백업 backing-up-your-repository

다음 백업 및 복원 crx 설명서의 섹션에서 CRX 저장소 백업과 관련된 모든 문제를 다룹니다.

온라인 "핫" 백업 작업에 대한 자세한 내용은 온라인 백업 만들기.

버전 삭제 version-purging

다음 버전 삭제 도구는 저장소의 노드 버전 또는 노드 계층 구조를 삭제하기 위한 것입니다. 기본 목적은 이전 버전의 노드를 제거하여 저장소 크기를 줄이는 데 도움이 됩니다.

이 섹션에서는 AEM의 버전 관리 기능과 관련된 유지 관리 작업을 다룹니다. 다음 버전 제거 도구는 저장소의 노드 버전 또는 노드 계층 구조를 삭제하기 위한 것입니다. 기본 목적은 이전 버전의 노드를 제거하여 저장소 크기를 줄이는 데 도움이 됩니다.

개요 overview

다음 버전 삭제 도구는에서 사용할 수 있습니다. 도구 콘솔 아래에 버전 관리 또는 다음 위치에서 바로 사용할 수 있습니다.

https://<server>:<port>/etc/versioning/purge.html

시작 경로 삭제를 수행해야 하는 절대 경로입니다. 저장소 트리 탐색기를 눌러 시작 경로를 선택할 수 있습니다.

재귀 데이터를 삭제할 때 재귀를 선택하여 한 노드에서 작업을 수행하거나 전체 계층 구조에서 작업을 수행할 것인지 선택할 수 있습니다. 마지막 경우 지정된 경로가 계층의 루트 노드를 정의합니다.

유지할 최대 버전 노드에 유지할 최대 버전 수입니다. 이 숫자가 이 값을 초과하면 가장 오래된 버전이 삭제됩니다.

최대 버전 페이지 노드 버전의 최대 연령 버전의 페이지가 이 값을 초과하면 삭제됩니다.

연습 실행 컨텐츠의 버전을 제거하는 것은 확실하고 백업을 복원하지 않으면 되돌릴 수 없으므로 제거 버전 도구에서는 삭제된 버전을 미리 볼 수 있는 연습 실행 모드를 제공합니다. 제거 프로세스의 연습 실행을 시작하려면 연습 실행을 누릅니다.

제거 시작 경로에 정의된 노드에서 버전 삭제를 시작합니다.

웹 사이트 버전 삭제 purging-versions-of-a-web-site

웹 사이트의 버전을 삭제하려면 다음과 같이 하십시오.

콘솔 분석 analyzing-the-console

다음 연습 실행 및 제거 프로세스에는 처리된 모든 노드가 나열됩니다. 프로세스 중에 노드는 다음 상태 중 하나를 가질 수 있습니다.

또한 이 콘솔에서는 버전에 대한 유용한 정보를 제공합니다.

다음 예에서

감사 레코드 및 로그 파일 작업 working-with-audit-records-and-log-files

AEM(Adobe Experience Manager)과 관련된 레코드 및 로그 파일을 감사하는 방법은 다양한 위치에서 찾을 수 있습니다. 찾을 수 있는 위치에 대한 개요를 제공하기 위해 다음 항목이 제공됩니다.

로그 작업 working-with-logs

AEM WCM은 세부 로그를 기록합니다. 압축을 풀고 빠른 시작을 시작하면 로그를 찾을 수 있습니다.

로그 파일 순환 log-file-rotation

로그 파일 순환은 새 파일을 주기적으로 작성하여 파일 증가를 제한하는 프로세스를 말합니다. AEM에서 error.log 은 지정된 규칙에 따라 하루에 한 번 회전합니다.

로그 파일 찾기 finding-the-log-files

다양한 로그 파일은 AEM을 설치한 파일 서버에 저장됩니다.

디버그 로그 수준 활성화 activating-the-debug-log-level

기본 로그 수준입니다 Apache Sling 로깅 구성 는 정보이므로 디버그 메시지가 기록되지 않습니다.

로거에 대한 디버그 로그 레벨을 활성화하려면 속성을 설정합니다 org.apache.sling.commons.log.level 를 눌러 저장소에 디버깅됩니다. 예, /libs/sling/config/org.apache.sling.commons.log.LogManager 를 글로벌 Apache Sling 로깅.

디버그 파일의 한 줄은 일반적으로 DEBUG로 시작하며 로그 수준, 설치 관리자 작업 및 로그 메시지를 제공합니다. 예:

DEBUG 3 WebApp Panel: WebApp successfully deployed

로그 수준은 다음과 같습니다.

사용자 지정 로그 파일 만들기 create-a-custom-log-file

특정 상황에서 다른 로그 수준으로 사용자 지정 로그 파일을 만들 수 있습니다. 다음 방법으로 저장소에서 이 작업을 수행할 수 있습니다.

Felix 콘솔에서는 Sling 로그 지원 정보도 제공합니다 ../system/console/slinglog; 예 http://localhost:4502/system/console/slinglog.

감사 레코드 찾기 finding-the-audit-records

감사 기록은 누가 언제 무엇을 했는지 기록하기 위해 보관된다. AEM WCM 및 OSGi 이벤트 모두에 대해 다양한 감사 레코드가 생성됩니다.

페이지 작성 시 표시되는 AEM WCM 감사 레코드 aem-wcm-audit-records-shown-when-page-authoring

리포지토리 내의 AEM WCM 감사 레코드 aem-wcm-auditing-records-within-the-repository

내 /var/audit 폴더, 감사 레코드는 리소스에 따라 유지됩니다. 개별 레코드 및 개별 레코드가 포함된 정보를 볼 수 있을 때까지 드릴다운할 수 있습니다.

이러한 항목에는 페이지를 편집할 때 표시된 것과 동일한 정보가 있습니다.

웹 콘솔에서 OSGi 감사 레코드 osgi-audit-records-from-the-web-console

또한 OSGi 이벤트는 구성 상태 탭 -> 로그 파일 AEM 웹 콘솔 탭:

복제 에이전트 모니터링 monitoring-your-replication-agents

다음을 모니터링할 수 있습니다 복제 큐 큐가 다운되거나 차단되는 시점을 감지하려면 게시 인스턴스 또는 외부 시스템에 문제가 있을 수 있습니다.

복제 에이전트를 모니터하려면

다시 다음을 통해 모든 복제 에이전트를 검색하는 솔루션을 개발할 수 있습니다 /etc/replication/author 또는 /etc/replication/publish)를 클릭한 다음 에이전트의 상태( enabled, disabled) 및 기본 큐( active, idle, blocked).

성능 모니터링 monitoring-performance

성능 최적화 는 개발 중에 포커스를 받는 대화형 프로세스입니다. 배포 후에는 일반적으로 특정 간격이나 이벤트 후에 검토합니다.

최적화를 위해 정보를 수집하는 동안 사용되는 방법도 지속적인 모니터링에 사용할 수 있습니다.

다음은 일반적인 성능 문제를 찾아 해결하는 방법과 함께 설명합니다.

성능 문제는 연결 속도, CPU 로드 등 웹 사이트와 관련이 없는 여러 원인에서 발생할 수 있습니다.

또한 모든 방문자나 방문자의 하위 세트에만 영향을 줄 수 있습니다.

일반 성능을 최적화하거나 특정 문제를 해결하기 전에 이러한 모든 정보를 획득, 정렬 및 분석해야 합니다.

성능 모니터링 및 분석 도구 tools-for-monitoring-and-analyzing-performance

다음은 성능 모니터링 및 분석에 사용할 수 있는 몇 가지 도구에 대한 간략한 개요를 제공합니다.

이러한 항목 중 일부는 운영 체제에 따라 다릅니다.

request.log 해석 interpreting-the-request-log

이 파일은 AEM에 수행된 모든 요청에 대한 기본 정보를 등록합니다. 이 귀중한 결론에서 추출할 수 있습니다.

다음 request.log 는 요청이 얼마나 오래 걸리는지 확인할 수 있는 기본 방법을 제공합니다. 개발 목적으로 다음과 같은 경우에 유용합니다 tail -f a request.log 그리고 느린 응답 시간을 확인하십시오. 더 크게 분석하려면 request.log 추천합니다 사용 rlog.jar 응답 시간에 대해 정렬 및 필터링할 수 있습니다..

페이지에서 "느린" 페이지를 분리하는 것이 좋습니다 request.log를 조정할 때 개별적으로 조정할 수 있습니다. 일반적으로 구성 요소당 성능 지표를 포함하거나 성능 프로파일링 도구(예: [yourkit](https://www.yourkit.com/).

웹 사이트에서 트래픽 모니터링 monitoring-traffic-on-your-website

요청 로그는 수행된 각 요청과 수행된 응답을 등록합니다.

09:43:41 [66] -> GET /author/y.html HTTP/1.1
09:43:41 [66] <- 200 text/html 797ms

특정 기간(예: 다양한 24시간 기간 이상) 내의 모든 GET 항목을 합하면 웹 사이트의 평균 트래픽에 대한 설명을 만들 수 있습니다.

request.log를 사용하여 응답 시간 모니터링 monitoring-response-times-with-the-request-log

성능 분석을 위한 좋은 시작점은 요청 로그입니다.

<cq-installation-dir>/crx-quickstart/logs/request.log

로그는 다음과 같습니다(간단히 하기 위해 줄이 짧아짐).

31/Mar/2009:11:32:57 +0200 [379] -> GET /path/x HTTP/1.1
31/Mar/2009:11:32:57 +0200 [379] <- 200 text/html 33ms
31/Mar/2009:11:33:17 +0200 [380] -> GET /path/y HTTP/1.1
31/Mar/2009:11:33:17 +0200 [380] <- 200 application/json 39ms

이 로그에는 요청 또는 응답당 한 줄이 있습니다.

작은 스크립트를 사용하여 로그 파일에서 필요한 정보를 추출하고 원하는 통계를 취합할 수 있습니다. 여기에서 어떤 페이지 또는 페이지 유형이 느리는지, 그리고 전체 성능이 만족스러운지 확인할 수 있습니다.

request.log를 사용하여 검색 응답 시간 모니터링 monitoring-search-response-times-with-the-request-log

검색 요청은 로그 파일에도 등록됩니다.

31/Mar/2009:11:35:34 +0200 [338] -> GET /author/playground/en/tools/search.html?query=dilbert&size=5&dispenc=utf-8 HTTP/1.1
31/Mar/2009:11:35:34 +0200 [338] <- 200 text/html 1562ms

따라서 위와 같이 스크립트를 사용하여 관련 정보를 추출하고 통계를 작성할 수 있습니다.

그러나 응답 시간을 결정한 후에는 요청에 시간이 걸리는 이유와 응답을 개선하기 위해 수행할 수 있는 작업을 분석해야 할 수 있습니다.

동시 사용자 수 및 영향 모니터링 monitoring-the-number-and-impact-of-concurrent-users

다시 request.log 동시성 및 이에 대한 시스템의 반응을 모니터링하는 데 사용할 수 있습니다.

부정적인 영향을 보기 전에 시스템에서 처리할 수 있는 동시 사용자 수를 판별하려면 테스트를 수행해야 합니다. 다시 스크립트를 사용하여 로그 파일에서 결과를 추출할 수 있습니다.

31/Mar/2009:11:45:29 +0200 [333] -> GET /author/libs/Personalize/content/statics.close.gif HTTP/1.1
31/Mar/2009:11:45:29 +0200 [334] -> GET /author/libs/Personalize/content/statics.detach.gif HTTP/1.1
31/Mar/2009:11:45:30 +0200 [335] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTpCxyuBNiTCoiBMmw000.default.gif HTTP/1.1
31/Mar/2009:11:45:32 +0200 [335] <- 304 text/html 0ms
31/Mar/2009:11:45:33 +0200 [334] <- 200 image/gif 31ms
31/Mar/2009:11:45:38 +0200 [333] <- 200 image/gif 31ms
31/Mar/2009:11:45:42 +0200 [336] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTZRXunQbbQtvuuCMbRRBuWXz0000.default.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [337] -> GET /author/titlebar_bg.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [336] <- 304 text/html 0ms
31/Mar/2009:11:45:44 +0200 [337] <- 304 text/html 0ms

rlog.jar를 사용하여 오랜 기간 동안 요청을 찾습니다 using-rlog-jar-to-find-requests-with-long-duration-times

AEM에는 다음과 같은 위치에 있는 다양한 도우미 도구가 포함되어 있습니다.
<cq-installation-dir>/crx-quickstart/opt/helpers

이것들 중 하나는 rlog.jar를 사용하여 를 빠르게 정렬할 수 있습니다 request.log 따라서 요청이 가장 긴 시간에서 가장 짧은 시간에 걸쳐 지속 기간별로 표시됩니다.

다음 명령은 가능한 인수를 보여 줍니다.

$java -jar rlog.jar
Request Log Analyzer Version 21584 Copyright 2005 Day Management AG
Usage:
  java -jar rlog.jar [options] <filename>
Options:
  -h               Prints this usage.
  -n <maxResults>  Limits output to <maxResults> lines.
  -m <maxRequests> Limits input to <maxRequest> requests.
  -xdev            Exclude POST request to CRXDE.

예를 들어 request.log 파일로 만든 후 가장 긴 기간을 가진 첫 번째 요청 10개를 표시합니다.

$ java -jar ../opt/helpers/rlog.jar -n 10 request.log
*Info * Parsed 464 requests.
*Info * Time for parsing: 22ms
*Info * Time for sorting: 2ms
*Info * Total Memory: 1mb
*Info * Free Memory: 1mb
*Info * Used Memory: 0mb
------------------------------------------------------
     18051ms 31/Mar/2009:11:15:34 +0200 200 GET /content/geometrixx/en/company.html text/ html
      2198ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/cq/widgets.js application/x-javascript
      1981ms 31/Mar/2009:11:15:11 +0200 200 GET /libs/wcm/content/welcome.html text/html
      1973ms 31/Mar/2009:11:15:52 +0200 200 GET /content/campaigns/geometrixx.teasers..html text/html
      1883ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/security/cq-security.js application/x-javascript
      1876ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets.js application/x-javascript
      1869ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets/themes/default.js application/x-javascript
      1729ms 30/Mar/2009:16:45:56 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8
      1510ms 31/Mar/2009:11:15:34 +0200 200 GET /bin/wcm/contentfinder/asset/view.json/ content/dam?_dc=1238490934657&query=&mimeType=image&_charset_=utf-8 application/json
      1462ms 30/Mar/2009:17:23:08 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8

개인을 연결해야 할 수 있습니다 request.log 큰 데이터 샘플에서 이 작업을 수행해야 하는 경우 파일입니다.

Apache Bench apache-bench

특수 사례(예: 가비지 수집 등)의 영향을 최소화하기 위해 다음과 같은 도구를 사용하는 것이 좋습니다 apachebench (예: ab 추가 설명서에서)를 사용하여 메모리 누수를 식별하고 응답 시간을 선택적으로 분석할 수 있습니다.

Apache Bench는 다음과 같은 방법으로 사용할 수 있습니다.

$ ab -c 5 -k -n 1000 "http://localhost:4503/content/geometrixx/en/company.html"
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, https://www.zeustech.net/
Licensed to The Apache Software Foundation, https://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software: Day-Servlet-Engine/4.1.52
Server Hostname: localhost
Server Port: 4503

Document Path: /content/geometrixx/en/company.html
Document Length: 24127 bytes

Concurrency Level: 5
Time taken for tests: 69.766 seconds
Complete requests: 1000
Failed requests: 998
(Connect: 0, Receive: 0, Length: 998, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 24160923 bytes
HTML transferred: 24010923 bytes
Requests per second: 14.33 /sec (mean)
Time per request: 348.828 [ms] (mean)
Time per request: 69.766 [ms] (mean, across all concurrent requests)
Transfer rate: 338.20 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.9 0 58
Processing: 138 347 568.5 282 8106
Waiting: 137 344 568.1 281 8106
Total: 139 348 568.4 283 8106

Percentage of the requests served within a certain time (ms)
50% 283
66% 323
75% 356
80% 374
90% 439
95% 512
98% 1047
99% 1132
100% 8106 (longest request)

위의 숫자는 기본 AEM 설치에 포함된 대로 geometrixx 회사 페이지에 액세스하는 표준 MAcBook Pro 노트북(2010년 중반)에서 가져옵니다. 페이지는 매우 간단하지만 성능에 최적화되지 않았습니다.

apachebench 또한 모든 동시 요청에 대해 요청당 시간을 평균으로 표시합니다. 참조 Time per request: 54.595 [ms] (평균, 모든 동시 요청). 동시성 매개 변수의 값을 변경할 수 있습니다 -c (한 번에 수행할 여러 요청의 수) 효과를 볼 수 있도록 해줍니다.

요청 카운터 request-counters

요청 트래픽(특정 기간 동안의 요청 수)에 대한 정보는 인스턴스의 로드를 나타냅니다. 이 정보는 request.log에는 카운터를 사용하면 데이터 수집을 자동화하여 다음을 확인할 수 있습니다.

정보 수집을 자동화하기 위해 RequestFilter를 설치하여 모든 요청에서 카운터를 증가시킬 수도 있습니다. 여러 카운터를 다양한 기간에 사용할 수 있습니다.

수집된 정보는 다음을 나타내기 위해 사용할 수 있습니다.

HTML 댓글 html-comments

모든 프로젝트에 html comments 서버 성능 좋은 사례가 많다. 페이지를 선택하고 볼 페이지 소스를 열고 아래쪽으로 스크롤하여 다음과 같은 코드를 표시할 수 있습니다.

</body>
 </html>
        <!--
        Page took 58 milliseconds to be rendered by server
         -->

JConsole을 사용한 성능 모니터링 monitoring-performance-using-jconsole

도구 명령 jconsole 는 JDK에서 사용할 수 있습니다.

J)VisualVM을 사용하여 성능 모니터링 monitoring-performance-using-j-visualvm

JDK 1.6 이후 도구 명령 jvisualvm 사용할 수 있습니다. JDK 1.6을 설치한 후 다음을 수행할 수 있습니다.

이 도구를 사용하여 스레드 덤프 및 메모리 헤드 덤프를 생성할 수 있습니다. 기술 지원 팀에서 이러한 정보를 요청하는 경우가 많습니다.

정보 수집 information-collection

설치에 대해 가능한 한 많이 알고 있으면 성능 변화를 일으킬 수 있는 대상과 이러한 변경 사항이 정당한지 여부를 추적하는 데 도움이 됩니다. 중요한 변경 사항을 쉽게 볼 수 있도록 이러한 지표를 정기적으로 수집해야 합니다.

다음 정보가 유용할 수 있습니다.

몇 명의 작성자가 이 시스템을 사용하고 있습니까? how-many-authors-are-working-with-the-system

설치 이후 시스템을 사용한 작성자의 수를 보려면 다음 명령줄을 사용하십시오.

cd <cq-installation-dir>/crx-quickstart/logs
cut -d " " -f 3 access.log | sort -u | wc -l

주어진 날짜에 작업하는 작성자 수를 보려면 다음을 수행하십시오.

grep "<date>" access.log | cut -d " " -f 3 | sort -u | wc -l

일별 평균 페이지 활성화 수는 얼마입니까? what-is-the-average-number-of-page-activations-per-day

서버 설치 이후 저장소 쿼리를 사용한 총 페이지 활성화 수를 보려면 CRXDE를 통해 - 도구 - 쿼리:

그런 다음 설치 후 경과된 일 수를 계산하여 평균을 계산합니다.

현재 이 시스템에서 몇 개의 페이지를 유지 관리하고 있습니까? how-many-pages-do-you-currently-maintain-on-this-system

현재 서버에 있는 페이지 수를 보려면 저장소 쿼리를 사용합니다. CRXDE를 통해 - 도구 - 쿼리:

MSM을 사용하는 경우 월별 평균 롤아웃 수는 얼마입니까? if-you-use-msm-what-is-the-average-number-of-rollouts-per-month

설치 후 저장소 쿼리를 사용한 총 롤아웃 수를 확인하려면 CRXDE를 통해 - 도구 - 쿼리:

설치 후 경과된 개월 수를 계산하여 평균을 계산합니다.

월별 Live Copy의 평균 수는 얼마입니까? what-is-the-average-number-of-live-copies-per-month

설치 후 저장소 쿼리를 사용한 총 라이브 카피 수를 확인하려면 CRXDE를 통해 - 도구 - 쿼리:

설치 후 경과된 개월 수를 다시 사용하여 평균을 계산합니다.

AEM Assets을 사용하는 경우 현재 Assets에서 몇 개의 자산을 유지 관리하고 있습니까? if-you-use-aem-assets-how-many-assets-do-you-currently-maintain-in-assets

현재 유지 관리하는 DAM 자산 수를 보려면 저장소 쿼리를 사용합니다. CRXDE를 통해 - 도구 - 쿼리:

자산의 평균 크기는 얼마입니까? what-is-the-average-size-of-the-assets

의 전체 크기를 확인하려면 /var/dam 폴더:

현재 사용되는 템플릿 수는 몇 개입니까? how-many-templates-are-currently-used

현재 서버에 있는 템플릿 수를 보려면 저장소 쿼리를 사용합니다. CRXDE를 통해 - 도구 - 쿼리:

현재 사용되는 구성 요소는 몇 개입니까? how-many-components-are-currently-used

서버에 현재 있는 구성 요소 수를 보려면 저장소 쿼리를 사용합니다. CRXDE를 통해 - 도구 - 쿼리:

최고 시간에 작성 시스템에 몇 개의 요청이 있습니까? how-many-requests-per-hour-do-you-have-on-the-author-system-at-peak-time

최대 시간에 작성 시스템에 있는 시간당 요청을 확인하려면:

최대 시간에 게시 시스템에 몇 개의 요청이 있습니까? how-many-requests-per-hour-do-you-have-on-the-publish-system-at-peak-time

게시 인스턴스에서 위의 절차를 반복합니다.

특정 시나리오 분석 analyzing-specific-scenarios

다음은 특정 성능 문제가 발생하는지 여부를 확인할 사항에 대한 제안 목록입니다. 이 목록은 (불행히도) 완전히 포괄적이지 않습니다.

CPU(100%) cpu-at

시스템의 CPU가 100%에서 지속적으로 실행되고 있는 경우 다음을 참조하십시오.

메모리 부족 out-of-memory

개발 및 테스트 중에 이러한 오류를 탐지해야 하지만 특정 시나리오가 미끄러질 수 있습니다.

시스템에 메모리가 부족한 경우 성능 저하 및 하위 텍스트를 포함하는 오류 메시지를 포함하여 다양한 방법으로 볼 수 있습니다.

java.lang.OutOfMemoryError

이 경우 다음을 확인합니다.

디스크 I/O disk-i-o

시스템에 디스크 공간이 부족하거나 디스크 스래싱이 시작하는 것을 발견하면 다음을 참조하십시오.

정규 성능 저하 regular-performance-degradation

재부팅한 후(1주일 이상) 인스턴스 성능이 저하되는 경우 다음을 확인할 수 있습니다.

JVM 조정 jvm-tuning

JVM(Java Virtual Machine)은 튜닝(특히 Java 7 이후)과 관련하여 크게 향상되었습니다. 따라서 적절한 고정 JVM 크기를 지정하고 기본값을 사용하는 것이 종종 적절합니다.

기본 설정이 적합하지 않으면 JVM을 튜닝하기 전에 GC 성능을 모니터링하고 평가하는 방법을 설정하는 것이 중요합니다. 여기에는 heap 크기, 알고리즘 및 기타 측면과 같은 모니터링 요소가 포함될 수 있습니다.

몇 가지 일반적인 선택 사항은 다음과 같습니다.

다음과 같은 GC 시각화 도우미에서 결과 로그를 수집할 수 있습니다.

[https://www.ibm.com/developerworks/library/j-ibmtools2/](https://www.ibm.com/developerworks/library/j-ibmtools2/)

또는 JConsole:

이렇게 하면 사용 중인 메모리 크기, 사용 중인 GC 알고리즘, 실행 시간 및 애플리케이션 성능에 어떤 영향을 주는지 확인할 수 있습니다. 이렇게 하지 않으면 튜닝은 "임의로 사용하는 매듭들"일 뿐입니다.