- Jmeter란

a부하테스트를 위한 Apache 재단의 오픈소스 툴

 


□ 설치 방법

 

Apache 사이트에서, Jmeter 다운로드 후 {설치폴더}/bin/jmeter.bat으로 실행

 

jmeter.apache.org/

 

Apache JMeter - Apache JMeter™

Apache JMeter™ The Apache JMeter™ application is open source software, a 100% pure Java application designed to load test functional behavior and measure performance. It was originally designed for testing Web Applications but has since expanded to oth

jmeter.apache.org

□ 구조

 

Test Plan - 테스트 케이스들이 모인 가장 상위 단위
Thread Group - Sampler들이 모인 테스트 케이스 단위
Sampler - 하나의 작은 작업 단위

 

□ 수행 방법

 

1. Add Thread Group

 

Number of Threads : 부하를 발생시킬 유저의 수

Ramp-up period : 전체 쓰레드가 작업이 완료되는 시간 

ex : Thread가 3이고, Ramp-up 이 15일시, 5초마다 3개 쓰레드가 실행 . ( 총 15초 수행 )

Loop Count : 해당 Thread 작업 반복횟수

 

2. Sampler 추가

 

- 이번 작업에서는 Tomcat 으로 띄워논 웹페이지 부하테스트로, HTTP Sampler 추가 ( 단순 DB Select 결과값을 보여주는 화면 )

 

HTTP(s) / IP / Port / Request path 작성

 

3. 모니터링을 위한 Listner 추가

 

Summary Report , View Result Tree 및 Graph Results 정도 추가해서, 추이확인 예정

 

4. Run 버튼으로 수행

 

Summary Report

Result Tree

Graph Result

 

'모니터링 > Scouter' 카테고리의 다른 글

(3) 스카우터를 통한 부하 분석  (0) 2021.04.29
(1) 설치 및 적용  (0) 2021.04.27
(0) Scouter 란  (0) 2021.04.27

GitHub에서 설치파일 다운로드 - github.com/scouter-project/scouter/releases/

 

Server, Agent, Client 모두 설치 예정이므로 All 버전 다운로드

-> 압축 풀어주면 설치는 완료


1) Server 구동

 

□ 설치 디렉토리/server/conf/Scouter.conf 파일 수정

 

  -  아무것도 작성이 안되어있어, Default 로 동작하겠지만, 수정이 필요하면 옵션 수정

     TCP, UDP Port 및 DB,log 저장 Path

더보기

# Agent Control and Service Port(Default : TCP 6100)
net_tcp_listen_port=6100

# UDP Receive Port(Default : 6100)
net_udp_listen_port=6100

# DB directory(Default : ./database)
db_dir=./database

# Log directory(Default : ./logs)
log_dir=./logs

□ 설치 디렉토리/server/conf/Start.bat 수행

 

2) Client로 접속 확인

 

 - Default Port : <server>:6100 Port

 - Default ID/PWD : admin/admin

- 서버는 가동되었으나, 수집되는 정보는 없는 상태

3) Agent 구동하여 데이터 수집하기

 

3-1) Host Agent

 

□ 설치폴더/agent.host/conf/scouter.conf 수정

 

# Default Setting

### scouter host configruation sample
#net_collector_ip=127.0.0.1
#net_collector_udp_port=6100
#net_collector_tcp_port=6100
#cpu_warning_pct=80
#cpu_fatal_pct=85
#cpu_check_period_ms=60000
#cpu_fatal_history=3
#cpu_alert_interval_ms=300000
#disk_warning_pct=88
#disk_fatal_pct=92

// Admin 서버 정보
net_collector_ip=127.0.0.1 // 데이터를 전송받을 Admin Server IP

net_collector_udp_port=6100 // UDP Port ( 기본 6100 )
net_collector_tcp_port=6100 // TCP Port ( 기본 6100 )

// CPU 알림 여부

#cpu_warning_pct=80 // Warning %
#cpu_fatal_pct=85 // Fatal %
#cpu_check_period_ms=60000 // CPU 수집 주기

#cpu_fatal_history=3  // Fatal 알림 누적 카운트 
#cpu_alert_interval_ms=300000 // CPU 알림 주기

// DISK 알림여부
#disk_warning_pct=88 // Warning %
#disk_fatal_pct=92 // Fatal %

 

 

설치폴더/agent.host/host.bat 수행

 

OS 정보 수집되는것 확인

3-2) Java Agent

 

□ Java agent는 단독실행이 아니라, 인스턴스에 붙어서 수행됌

 

□ 설치폴더/agent.java/conf/scouter.config 수정

### scouter java agent configuration sample
obj_name=test_01
net_collector_ip=127.0.0.1
net_collector_udp_port=6100
net_collector_tcp_port=6100

 

□ Tomcat 실행옵션에, Scouter 추가.

 

Eclipse VM Option에 하기 내용 추가

-javaagent:"D:\scouter-all-2.7.1.tar\scouter\agent.java/scouter.agent.jar"
-Dscouter.config="D:\scouter-all-2.7.1.tar\scouter\agent.java/conf/scouter.conf"

 

□ 수집하는것 확인

'모니터링 > Scouter' 카테고리의 다른 글

(3) 스카우터를 통한 부하 분석  (0) 2021.04.29
(2) Jmeter를 통한 부하  (0) 2021.04.29
(0) Scouter 란  (0) 2021.04.27

LG CNS에서 만든 오픈소스 APM

- Github 에서 설치 및 사용방법등 확인 가능  https://github.com/scouter-project/scouter 

※ APM ( Application Performance Monitoring ) : 어플리케이션 성능과 가용성에 대한 모니터링 및 관리

크게 Server , Agent , Client로 구분되어 있다.

 

1) Server 

Agent로 부터 데이터를 수집하여, 모니터링 가능하게 UI로 띄워놓는다.

2) Agent

OS에 설치하여 각종 성능 데이터들을 Server로 보낸다. 크게 Host 와 java agent로 나뉜다

 

 2-1 ) Host agent : CPU, Memory, F/S 등의 OS 정보 전송

 2-2 ) Java agent : 자바 프로세스, 인스턴스에 대해 Heap Memory, Request Transaction 등의 JVM 정보 전송 ( JVM 옵션적용 필요 )

 

3) Client

Server에 접속하여, 수집된 정보들을 UI로 확인할 수 있다.


※ 수집하는 데이터 

  • 각 요청의 응답속도 / 프로파일링 정보
  • 서버 요청 수 / 응답 수
  • 처리 중인 요청 수
  • 응답속도의 평균
  • JVM 메모리 사용량 / GC 시간
  • CPU 사용량

+ 프로파일링 정보를 통해서

  • 서버간 요청의 흐름
  • 각 SQL 쿼리의 수행 시간 / 통계
  • API 호출 수행 시간
  • request header 정보
  • 메소드 호출시 수행 시간

'모니터링 > Scouter' 카테고리의 다른 글

(3) 스카우터를 통한 부하 분석  (0) 2021.04.29
(2) Jmeter를 통한 부하  (0) 2021.04.29
(1) 설치 및 적용  (0) 2021.04.27

■ Eclipse - Tomcat 연동

 

먼저, 개발하기 쉽게 Eclipse에 Tomcat을 연동한다

 


■ Tomcat - Postgre 연결

 

- jdbc Driver 설치

 

jdbc.postgresql.org/download.html

 

자바 버전에 맞추어 설치 후 Tomcat 라이브러리 폴더로 이동 ( $Catalina_HOME/common/lib )

 

Tomcat 에서 Postgre로 연결하는 방법 중, Connection Pool로 맺어보려한다.

 

■ jsp 페이지내에서 접속정보를 입력하고, 직접 커넥션 맺기
■ Connection Pool 생성 후, Pool 안에서 커넥션 맺기

 Tomcat 설정

 

1. server.xml Context 밑에 추가

<Resource name="jdbc/DBName"
                    auth="Container"
                    type="javax.sql.DataSource"
                    driverClassName="org.postgresql.Driver"
                    loginTimeout="10"
                    maxWait="5000"
                    username="아이디"
                    password="비밀번호"
                    testOnBorrow="true"
                    url="jdbc:postgresql://127.0.0.1/디비이름" />

 

2. web.xml에 추가

<resource-ref>
        <description>PGSQL DB Connection</description>
        <res-ref-name>jdbc/DBName</res-ref-name>
        <res-type>javax.sql.DataSource</res-type>
        <res-auth>Container</res-auth>
</resource-ref>

3. JSP 페이지 작성하여 JNDI 불러오기

※ JSTL 사용. 다음장에 정리 예정
<%@ page contentType="text/html;charset=utf-8" session="true" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/sql" prefix="sql" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
 
<sql:query var="rs" dataSource="jdbc/test">
select * from connect_check
</sql:query>
 
<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8">
    <title>DB 테스트</title>
  </head>
  <body>
 
<c:forEach var="row" items="${rs.rows}">
    사번: ${row.employee_num}, 
    ID: ${row.employee_id},
    IP: ${row.ip}, 
    <br/>
</c:forEach>
 
  </body>
</html>

 

4. 구동시켜 확인해보기

'IT > 서버 구성해보기' 카테고리의 다른 글

VM Image 초기세팅  (0) 2021.09.29
로컬서버 (1) 환경 설정  (0) 2021.04.23

■ 아키텍쳐 구성

 

- JAVA : 1.8.0_181

- WEB : IIS

- WAS : tomcat 9.0

- DB : PostgreSql or MariaDB

 


 

 WAS 및 DB 다운로드 ( 압축 해제 혹은 간단한 인스톨으로, 링크만 기재 )

 

- Tomcat 9.0 Download

tomcat.apache.org/download-90.cgi

- Eclipse Download ( 2020-06 ver )

www.eclipse.org/downloads/packages/release/2020-06/r

- Postgrel SQl Download ( 10 )

www.postgresql.org/download/

 

'IT > 서버 구성해보기' 카테고리의 다른 글

VM Image 초기세팅  (0) 2021.09.29
로컬서버 (2) WAS - DB 연결  (1) 2021.04.23

앞선 케이스에서는 튜닝 포인트가 없다. 또한 GC 튜닝은 권장되지 않는 작업이다.

하지만 극단적인 케이스에서는, GC로 인한 서비스 순단을 최소화 할 수 있다.

 


- 튜닝이 필요한 케이스?

 

GC 시간 및 주기를 파악해보고, 정상여부 확인

더보기
  • Minor GC의 처리시간이빠르다 (50ms내외).
  • Minor GC 주기가빈번하지않다 (10초내외).
  • Full GC의처리시간이빠르다 (보통1초이내).
  • Full GC 주기가빈번하지않다 (10분에 1회 )

- 튜닝 대상

 

1. Old 영역으로 넘어가는 객체 최소화 

 

Full GC는 Minor GC에 비해 5~10배 이상 오래걸린다.

그래서 Old 영역에서의 GC보다는, New 영역안에서 이루어지는 GC만으로 메모리 관리하는 것이 가장 좋다.

 

2. Full GC 시간 단축

 

GC시에는 stop-the-world 로 인해 프로세스가 멈추므로 , GC 시간을 최소화 하는것이 좋다

특히 Full GC는 시간이 오래걸리기때문에, 연계 프로세스에서 타임아웃이 걸릴수도 있다.

Old 영역의 크기를 잘 조절하여 GC 시간을 관리하여야 한다.

 

 

Old 영역을 줄인다

=> Full GC 시간은 줄어드나, 횟수가 증가함. 남은 Old 영역보다 많은 객체가 들어올 경우 OOM 발생

 

Old 영역을 늘린다

=> Full GC 횟수는 줄어드나, 시간이 증가함

 

- 튜닝 작업

 

※ 각 시스템, 서버, 프로그램 마다 변수가 다양하기 때문에 정해진 값이나, 권고 값은 없다.

   설정값 변경후에, 모니터링을 하며 ( 최소 24시간 ) 맞는 값을 찾아가야한다.

 

1. GC 방식 결정

 

  • Serial GC - 적은 메모리와 CPU 코어수가 작을 때 유리
  • Parallel GC - 메모리와 코어수가 많을때 유리. Serial과 다르게 다중 스레드 처리
  • Concurrent Mark & Sweep GC(이하 CMS) - 응답속도가 매우 빠르나, 메모리와 코어를 가장 많이 잡아먹는다.
  • G1(Garbage First) GC - Young / Old 에 개념이 없고, 객체별로 객체 할당 및 GC가 이루어짐. JDK 7 버전부터 적용

자세한 내용은 ( d2.naver.com/helloworld/1329 ) 참조

 

2. 메모리 설정

 

먼저, 힙 메모리의 크기를 정해준다.

 

더보기

-Xms : 힙메모리 초기 할당값

-Xmx : 힙메모리 최대 값

 

다음으로 할당된 메모리중에서 , New/Old 영역의 비율을 결정해준다.

 

더보기

-XX:NewRatio : New / Old 영역 비율 지정

ex) Ratio = 4 / New : Old = 1:4

 

3. 설정값 적용 후, 모니터링하며 값들을 수정한다.

 

#참조

d2.naver.com/helloworld/37111

'서버운영 > 자바 GC ( Garbage Collection )' 카테고리의 다른 글

GC분석 - GUI를 통한 gc 추이분석  (0) 2021.04.05
GC 분석 - gc 케이스 분석  (0) 2021.04.05
GC 관리  (0) 2021.04.04
GC ( Garbage Collection )  (0) 2021.04.04

GC 분석 방법에는 여러가지가 있다.

 

1. gceasy

 

- 별도 프로그램 설치없이, ( gceasy.io/ ) 접속 후에 로그파일을 올리기만 하면된다.

 

 

2. IBM JAVA Garbage Collector ( PMAT )

 

- 다운로드 : www.ibm.com/support/pages/node/1109973

- 실행 : java -Xmx1g -jar ga458.jar

 

- File -> Open verbosegc 수행후 gc.log 파일을 넣어주면 아래와 같이 요약본이 나온다.

- 표로 GC를 Timestamp 별로 정리해서 볼수도 있다.

 

- 그래프로 시간대별 GC 수행시간 / 수행전후 메모리 사용량 등을 확인할 수 있다.

 

- GC 비율 및 수행시간 확인

 

Minor GC : 4922회 수행/ 평균 10ms

Full GC : 27회 수행 / 평균 310ms 수행

 

 

 

3. Java VisualVM

 

- Jdk1.6 부터 bin 밑에 존재하는 JVM 분석 툴

- visualvm.github.io/에서 따로 내려받을수도 있다.

 

 

4. HP Jmeter

 

- HP에서 제공하는 분석툴

- m.blog.naver.com/PostView.nhn?blogId=bumsukoh&logNo=110142702864&proxyReferer=https:%2F%2Fwww.google.com%2F

'서버운영 > 자바 GC ( Garbage Collection )' 카테고리의 다른 글

GC 튜닝  (0) 2021.04.06
GC 분석 - gc 케이스 분석  (0) 2021.04.05
GC 관리  (0) 2021.04.04
GC ( Garbage Collection )  (0) 2021.04.04

gc.log 분석하는 방법을 작성해보려한다.

 

JVM 기동옵션은 아래와 같다.

더보기

-XX:+DisableExplicitGC : system.gc() 메소드를 수행하지 않음.

※ 자바에서 RMI ( Remote Method Invocation ) 사용시, 60초마다 system.gc() 를 호출해 Full GC 발생 

 

-XX:-UseAdaptiveSizePolicy : New 영역의 크기가 동적으로 변하지 않음

-verbose:gc : GC 기록을 출력

-Xloggc:{gc_Path}.gclog : GC를 파일로 출력함

-XX:+PrintGCDetails : GC에 대한 상세정보 출력

-XX:+PrintGCTimeStamps : GC를 초단위로 기록함

-XX:+PrintHeapAtGC : GC시에 Heap 메모리 상태 기록

 

GC 로그파일은 아래와 같다.

 

- Minor GC

 

더보기

{Heap before GC invocations=1 (full 0):
 PSYoungGen      total 354304K, used 315392K [0x00000007a8000000, 0x00000007c0000000, 0x00000007c0000000)
  eden space 315392K, 100% used [0x00000007a8000000,0x00000007bb400000,0x00000007bb400000)
  from space 38912K, 0% used [0x00000007bda00000,0x00000007bda00000,0x00000007c0000000)
  to   space 38912K, 0% used [0x00000007bb400000,0x00000007bb400000,0x00000007bda00000)
 ParOldGen       total 2228224K, used 0K [0x0000000720000000, 0x00000007a8000000, 0x00000007a8000000)
  object space 2228224K, 0% used [0x0000000720000000,0x0000000720000000,0x00000007a8000000)
 Metaspace       used 11772K, capacity 12066K, committed 12160K, reserved 1060864K
  class space    used 1284K, capacity 1401K, committed 1408K, reserved 1048576K
4.788: [GC (Allocation Failure) [PSYoungGen: 315392K->19963K(354304K)] 315392K->19979K(2582528K), 0.0095085 secs] [Times: user=0.14 sys=0.02, real=0.01 secs] 


Heap after GC invocations=1 (full 0):
 PSYoungGen      total 354304K, used 19963K [0x00000007a8000000, 0x00000007c0000000, 0x00000007c0000000)
  eden space 315392K, 0% used [0x00000007a8000000,0x00000007a8000000,0x00000007bb400000)
  from space 38912K, 51% used [0x00000007bb400000,0x00000007bc77ede8,0x00000007bda00000)
  to   space 38912K, 0% used [0x00000007bda00000,0x00000007bda00000,0x00000007c0000000)
 ParOldGen       total 2228224K, used 16K [0x0000000720000000, 0x00000007a8000000, 0x00000007a8000000)
  object space 2228224K, 0% used [0x0000000720000000,0x0000000720004000,0x00000007a8000000)
 Metaspace       used 11772K, capacity 12066K, committed 12160K, reserved 1060864K
  class space    used 1284K, capacity 1401K, committed 1408K, reserved 1048576K
}

한줄씩 분석해보면,

 

{Heap before GC invocations=1 (full 0):

 

- invocations=1 : 프로세스가 구동되고, 발생한 GC의 횟수

- full 0 : 발생한 Full GC 횟수

 

 PSYoungGen      total 354304K, used 315392K [0x00000007a8000000, 0x00000007c0000000, 0x00000007c0000000)
 PSYoungGen      total 354304K, used 19963K [0x00000007a8000000, 0x00000007c0000000, 0x00000007c0000000)

 

- Young Generation이 354,304KB 중에 315,392KB 사용중 -> 19,963KB 사용

 

  eden space 315392K, 100% used [0x00000007a8000000,0x00000007bb400000,0x00000007bb400000)
  from space 38912K, 0% used [0x00000007bda00000,0x00000007bda00000,0x00000007c0000000)
  to   space 38912K, 0% used [0x00000007bb400000,0x00000007bb400000,0x00000007bda00000)
  
  eden space 315392K, 0% used [0x00000007a8000000,0x00000007a8000000,0x00000007bb400000)
  from space 38912K, 51% used [0x00000007bb400000,0x00000007bc77ede8,0x00000007bda00000)
  to   space 38912K, 0% used [0x00000007bda00000,0x00000007bda00000,0x00000007c0000000)

- Eden 영역 100% 사용으로 인한 GC 발생으로 보임.

- GC후에 Survivor From 영역으로 이동. Eden 0% 사용

 

 ParOldGen       total 2228224K, used 0K [0x0000000720000000, 0x00000007a8000000, 0x00000007a8000000)
  object space 2228224K, 0% used [0x0000000720000000,0x0000000720000000,0x00000007a8000000)
 Metaspace       used 11772K, capacity 12066K, committed 12160K, reserved 1060864K
  class space    used 1284K, capacity 1401K, committed 1408K, reserved 1048576K

- New 영역에 대한 Minor GC 였으므로, Old 영역은 변화가 없음

 

4.788: [GC (Allocation Failure) [PSYoungGen: 315392K->19963K(354304K)] 315392K->19979K(2582528K), 0.0095085 secs] [Times: user=0.14 sys=0.02, real=0.01 secs] 

GC 결과 요약

- GC ( Allocation Failure ) : GC 발생이유. 메모리 할당 실패로 인한 GC발생

- Young 영역 정리 ( 315,392KB -> 19,963KB , 354,304KB 정리 )

- 0.0095초 소요

 


- Full GC

 

더보기

{Heap before GC invocations=3 (full 1):
 PSYoungGen      total 354304K, used 38891K [0x00000007a8000000, 0x00000007c0000000, 0x00000007c0000000)
  eden space 315392K, 0% used [0x00000007a8000000,0x00000007a8000000,0x00000007bb400000)
  from space 38912K, 99% used [0x00000007bda00000,0x00000007bfffafa8,0x00000007c0000000)
  to   space 38912K, 0% used [0x00000007bb400000,0x00000007bb400000,0x00000007bda00000)
 ParOldGen       total 2228224K, used 107K [0x0000000720000000, 0x00000007a8000000, 0x00000007a8000000)
  object space 2228224K, 0% used [0x0000000720000000,0x000000072001af50,0x00000007a8000000)
 Metaspace       used 20783K, capacity 21068K, committed 21248K, reserved 1069056K
  class space    used 2337K, capacity 2460K, committed 2560K, reserved 1048576K
5.461: [Full GC (Metadata GC Threshold) [PSYoungGen: 38891K->0K(354304K)] [ParOldGen: 107K->38122K(2228224K)] 38999K->38122K(2582528K), [Metaspace: 20783K->20783K(1069056K)], 0.0532366 secs] [Times: user=0.57 sys=0.03, real=0.05 secs] 


Heap after GC invocations=3 (full 1):
 PSYoungGen      total 354304K, used 0K [0x00000007a8000000, 0x00000007c0000000, 0x00000007c0000000)
  eden space 315392K, 0% used [0x00000007a8000000,0x00000007a8000000,0x00000007bb400000)
  from space 38912K, 0% used [0x00000007bda00000,0x00000007bda00000,0x00000007c0000000)
  to   space 38912K, 0% used [0x00000007bb400000,0x00000007bb400000,0x00000007bda00000)
 ParOldGen       total 2228224K, used 38122K [0x0000000720000000, 0x00000007a8000000, 0x00000007a8000000)
  object space 2228224K, 1% used [0x0000000720000000,0x000000072253a938,0x00000007a8000000)
 Metaspace       used 20783K, capacity 21068K, committed 21248K, reserved 1069056K
  class space    used 2337K, capacity 2460K, committed 2560K, reserved 1048576K
}

- from 영역의 Full로 인한 Full GC

- Old 영역이 107KB -> 38,122KB 로 증가

- GC 소요시간은 0.053초 정도. Minor GC 의 5배 정도 시간이다. ( 0.3초까지 걸리기도 함 )

'서버운영 > 자바 GC ( Garbage Collection )' 카테고리의 다른 글

GC 튜닝  (0) 2021.04.06
GC분석 - GUI를 통한 gc 추이분석  (0) 2021.04.05
GC 관리  (0) 2021.04.04
GC ( Garbage Collection )  (0) 2021.04.04

GC로 인해, 시스템에 장애가 올수도 있으므로 모니터링 및 관리가 필요하다.

 

 

※ 오랫동안 Full GC 발생하는 경우

 

1. Full GC 시간동안 Stop the world로 인해, 서비스가 중지되고

2. 그동안 쌓여있던 Queue로 인한 서비스 부하

 

※ Old 영역이 작게 할당되있을 경우

 

Old 영역이 작다면, Full GC의 수행시간이 짧아질수 있다.

그러나 계속 사용되는 객체 양에비해, Old 영역이 작다면 OOM이 발생할 것이다.

 

 

 

관리 옵션

 

JVM 기동 시, 자원 관련한 옵션들을 간단하게 정리해보았다.

 

-Xms , -Xmx : Heap 메모리 초기 할당값, 최대값 ( OS에서 프로세스에 할당해주는 값 )

-XX:NewSize : New 영역의 초기 할당값

-XX:MaxNewSize : New 영역의 최대값

-XX:NewRatio : New / Old 영역의 비율

-XX:SurvivorRatio : New / Survivor 영역의 비율

-XX:+UseParallelGC : 다중 스레드로 GC를 수행한다

 

 

모니터링 옵션

 

- GC 수행결과를 출력한다.

 

-XX:PrintGCDetail : GC에 대한 상세 정보를 출력

-XX:PrintGCTimeStamps : GC 수행시간에 대한 정보 출력

-XX:PrintHeapAtGC : GC시에 힙메모리 정보 출력

 

- OOM ( Out of Memory )발생시 , 당시에 Heap 메모리 사용량을 파일로 떨어트린다.

※ Heap 메모리 사용량과 동일한 용량으로 파일이 생성되므로, F/S 여유공간을 꼭 확인할 것

 

-XX:-HeapDumpOnOutOfMemoryError : OOM 발생시 Heap dump 생성

-XX:HeapDumpPath                         : Heap dump 파일의 위치

 

 

 

# 참조

 

waspro.tistory.com/340 ( GC 옵션 )

www.holaxprogramming.com/2013/07/20/java-jvm-gc/ ( JVM 기동 옵션 )

'서버운영 > 자바 GC ( Garbage Collection )' 카테고리의 다른 글

GC 튜닝  (0) 2021.04.06
GC분석 - GUI를 통한 gc 추이분석  (0) 2021.04.05
GC 분석 - gc 케이스 분석  (0) 2021.04.05
GC ( Garbage Collection )  (0) 2021.04.04

+ Recent posts