Tagged: java

Mac 에서 JAVA_HOME 찾기

참조: http://stackoverflow.com/questions/6588390/where-is-java-home-on-osx-sierra-10-12-el-captain-10-11-yosemite-10-10

Mac 에는 여러버전의 Java 가 설치되어 있습니다. 그런데, 가끔씩 JAVA_HOME 이 어디인지를 알고 싶을때가 있습니다. 그럴때 다음과 같이 하면 알수 있습니다.

 

 

Creative Commons License
Mac 에서 JAVA_HOME 찾기 by Voyager of Linux is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

잠긴 글: WebLogic 구동 시 /dev/random 블로킹 이슈 해결

이 콘텐츠는 비밀번호로 보호되어 있습니다. 보려면 아래에 비밀번호를 입력해주세요:

Creative Commons License
WebLogic 10.3.6 서버 시작하기 by Voyager of Linux is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Spring MVC hello world Example in STS

spring pivotal이 글은 STS(혹은 Eclipse) 를 사용해서 Hello World 를 만드는 법에 대한 것이다.  Eclipse, STS 를 설치했다면 자체적으로 간단한 샘플 프로젝트를 제공 한다. 아무런 설정도 필요없고 간단하게 패키지명만 입력해주면 샘플 프로젝트가 제공되고 브라우저를 통해서 확인할 수 있다.

Eclipse 에는 Spring IDE 플러그인이 설치된 것으로 가정한다.

Spring Legacy Project

STS나 Eclipse 를 설치했다면 Spring Legacy Project 를 제공한다. File 메뉴 -> New -> Other.. 를 클릭하면 나오는 팝업창에서 ‘Spring’ 폴더를 클릭하면 다음과 같은 화면에 ‘Spring Legacy Project’ 가 보입니다.

Spring Legacy Project 생성 팝업
Spring Legacy Project 생성 팝업

이제 ‘Next’ 를 누르면 다음과 같은 화면이 나온다.

Spring 템플릿. 그런데 MVC Project 가 없다.
Spring 템플릿. 그런데 MVC Project 가 없다.

하지만 위 화면과 같이 나올 수도 있다. 원래는 MVC Project 가 나와야 하는데, 보이지 않는다. 그럴때는 위 화면에 ‘Configure templates…’ 를 클릭한다.

Template Projects 수정
Template Projects 수정

위 화면과 같이 두가지를 순차적으로 삭제 해준다. 위와같이 하면 이전화면이 다음과 같이 나온다. 삭제하고 난후에도 이전화면에서 ‘Spring MVC Project’ 가 나타나지 않으면 Eclipse 를 재시작해준다.

Spring MVC Project 생성
Spring MVC Project 생성

위 화면과 같이 Project name 에는 ‘HelloWorld’ 를 적어주고 아래 Template 은 ‘Spring MVC Project’ 를 선택하고 ‘Next’ 를 해준다.

패키지명 작성
패키지명 작성

위와같이 패키지명을 입력하고 난 후에 Finish 를 누르면 Hello World 프로젝트가 작성된다.

Spring MVC Project 로 작성된 Hello World
Spring MVC Project 로 작성된 Hello World

이를 실행시키면 Hello World 를 브라우져에서 확인해 볼수 있다.

UTF-8 로 출력하기

이는 Deployment Discriptor 인 Web.xml 파일에 Encoding 설정을 UTF-8 로 설정해 줘야한다. 이는 다음과 같다.

Session 공유 테스트 코드

WAS 서버를 세팅할때에 Session 을 공유하도록 가끔은 구성할 때가 있다. 요즘은 spring-data-redis 를 이용해서 Redis 에 Session 을 저장하도록 지원하고 있지만 WAS  서버 자체적으로 Session 을 공유하도록 설정해서 운영할 수 있다.

이때 과연 WAS  서버들간 Session 이 제대로 공유되고 있는지를 확인할 필요가 있는데 이때 사용할 수 있는 코드다. 참고로 이 코드는 다음의 github 저장소에서 가지고 왔다.

먼저, Controller 를 다음과 같이 수정한다.

그리고 다음과 같이 home.jsp 파일을 수정해준다.

위와같이 수정하고 실행을하면 세션관련된 내용을 출력되고 세션 공유를 테스트해 볼 수 있다.

JBoss EAP 에서 세션 공유

코딩만으로는 Session 공유가 되지 않는다. WEB-INF 디렉토리에 ‘jboss-web.xml’ 을 만들고 다음과 같이 작성한다.

그리고 web.xml 파일에 다음을 추가해 준다.

위와 같이 하면 웹 애플리케이션에서 세션이 공유된다.

Creative Commons License
Spring MVC hello world Example in STS by Voyager of Linux is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Java BookMark

윈도우용 JDK Portable 설치.

윈도우용 JDK를 보면 Portable 설치가 없다. 설치를 할려면 Windows Installer  를 이용하는 방법 밖에 없다. 문제는 두개의 버전, 1.7과 1.8 버전의 JDK 를 설치할 수가 없을 수도 있다. 최신판을 설치된 상태에서 구 버전을 설치할려면 이미 최신버전이 설치가 되어 있어서 설치가 안될 수도 있다.

이럴때 Linux 용 처럼 압축만 해제하면 쓸수 있도록 할 수 있지 않을까? 이 글은 JDK를 압축해제하는 것만으로 설치하는 방법인 Portable 설치에 대해서 다룬다. 또한, 이글은 다음 링크의 내용을 정리한 것이다.

참고로 JDK 1.7 버전만 가지고 테스트 됐다.

준비

구 버전의 Windows Installer 를 다운받는다. 보통은 .exe 확장자로 끝나는 파일이다. 또 다른 프로그램이 필요한데 .exe 를 압축해제할 수 있는 압축/해제 소프트웨어다. 많은 압축/해제 소프트웨어가 있지만 7-zip 을 이용했다.

압축해제

jdk 압축 해제
위 그림과 같이 7-zip 을 설치한 후 마우스 오른쪽 버튼을 클릭하면 .exe 파일을 압축해제할 수 있다.

압축을 해제하면 jdk-7u80-windows-x64 디렉토리가 생성되고 그 안에 ‘tools.zip’ 압축파일이 보인다. 그럼 이 tools.zip 도 압축을 해제한다.

pack 파일을 jar 파일로 변환하기

tools.zip 파일을 보면 pack 파일들이 보인다. windows installer 의 패키징 파일이다. 이것을 unpack 해서 jar 파일로 만들어주는게 핵심이 된다.

cmd 창에서 작업을 해야해서 cmd 창을 띄운다. 그리고 방금 압축해제한 디렉토리인 tools 로 이동한다.

cmd 창에서 tools 로 이동
cmd 창에서 tools 로 이동

그리고 다음과 같이 입력한다.

위와같이 하면 pack 파일이 전부 jar 파일로 변환된다.

이제 tools 디렉토리를 ‘JDK1.7’ 로 이름을 바꾸고 C:\ 로 이동시키면 Portable 하게 설치가 완료된다.

Creative Commons License
윈도우용 JDK Portable 설치. by Voyager of Linux is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

잠긴 글: 가비지 컬렉터를 위한 테스트 코드

이 콘텐츠는 비밀번호로 보호되어 있습니다. 보려면 아래에 비밀번호를 입력해주세요:

Creative Commons License
가비지 컬렉터를 위한 테스트 코드 by Voyager of Linux is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

GC 알고리즘

reference counting algorithm

count를 관리하여 reference count가 0이되면 그때그때 garbage collection을 수행하는것이다.object에 reference 가되면 reference count는 1이 증가하고 reference가 사라지면 1이 감소하는 식으로 동작한다. 그런데 이 reference 관계가 간접적이라 하더라도 참조하고 있는 모든 object에 대해 연쇄적으로 reference count가 변경된다 이reference count가 0 이될때마다 garbage collection이 발생하기 때문에 자연스럽게 Pause Time이 분산되어 실시간 작업에도 거의 영향을 주지 않는 장점이 있다. 그러나 reference의 변경이나 garbage collection의 결과에 따라 각 object마다 reference count를 변경해 주어야하기 때문에 이에 대한 관리 비용이 상당하다 또한 Garbage collecition이 연쇄적으로 일어 날수 있다는 것도 문제가 될 수 있다. 하지만 무엇보다 이 reference counting algorithm 문제는 memory leak의 가능성이 농후하다는데 있다 reference count가 0이 되어야 garbage collection이 될것인데 순환 참조의 구조에서는 regerence count가 0이 될 가능성이 희박하다 그렇기 때문에 garbage 가 되어도 heap 에서 사라지지 않게 되어 memory leak 을 유발할 가능성이 커지게 된다

mark-and-sweep algorithm

reference에 따라 object마다 count를 하는 방식대신, root set에서 시작하는 reference의 관계를 추적하는 방식을 사용한다. 이러한 방식은 garbage를 detection하는데 있어 상당히 효과적이기 때문에 이후의 garbage collection에서 detection은 대부분 이 algorithm을 사용하고 있다.

mark-and-sweep algorithm은 mark phase와 sweep phase로 나뉘어 진다. mark phase는 gabage object를 구별핸재는 단계로 root set 에서 reference 관계가 있는 object에 marking하는 방식으로 수행된다.marking 을 위해서는 여러가지 방법이 있는데 주로 object header에 flag 나 별도의 btimap table등을 사용한다

이 mark-and-sweep algorithm은 reference관계까 정확하게 파악될 뿐만 아니라 reference의 관계의 변경 시에 부가적인 작업을 하지 않기 때문에 속도가 향상된다는 장점이 있다. 그러나 garbage collection 과정 중에는 heap의 사용이 제한된다. 그것은 작업의 정확성과 meomry corruption을 방지 하기 위함인데 이 경우 프로그램이 잠깐 멈추는 현상이 발생한다 또하나의 문제는 바로 fragementation이 발생 할수 있다는 것이다.

mark-and-compaction algorithm

make-and-sweep algorithm의 fragmentation이라는 약점을 국복하고자 sweep 대신 compaction을 포함한 것이다.

이 algorithm은 mark phase와 compaction phase로 구성되어 있다. compaction이란 작업은 말 그대로 live object를 연속된 메모리 공간에 차곡차곡 적재하는 것을 의미하며 보통 하위 address로 compaction을 수행한다 compaction에는 여러가지 방식이 있는데 arbitrary 방식, linear방식, sliding 방식 등이 있다. 이중 arbitrary방식은 순서가 보장되지 않는 방식이다. linear방식은 reference의 순서대로 정렬된 compaction이다 그리고 sliding 방식은 할당된 순서대로 정렬되는 방식이다.

compaction을 원활하게 하기 위해 handle과 같은 자료구조를 사용할 수도 있다. handle에는 객체의 논리적인 주소와 실제 주소가 들어가 있다. mark phase에서는 live object의 handel에 marking한다. compaction phase에서는 일단 marking 된 정보를 바탕으로 garbage object를 sweep 한 후 heap의 한 쪽 방향으로 live object를 이동시킨다. 이동하는 방법은 sliding compaction의 방법을 사용한다. 그 이후 이동한 새로운 주소로 모든 reference를 변경하는 작업을 수행한다

fragmentation의 방지에 초점이 맞추어져 있기 때문에 메모리 공간의 효율성이 가장 큰 장점이다.그러나 compaction 작업 이후에 모든 reference를 업데이트 하는 작업은 경우에 따라서 모든 object를 access하는등의 부가적인 overhead가 수반 될 수도 있다. 또한 mark phase와 compaction phase는 모두 suspend 현상이 발생한다는 단점이 있다

copying algorithm

heap 을 active영역과 inactive 영역으로 나누어서 사요한느 특징을 가지고 있다. 이중 active영역에만 object를 할당 받을 수 있고 active영역이 꽉 차게 되어 더이상 allocation이 불가능하게 되면 garbage collection이 수행된다.

garbage collection이 수행되면 모든 프로그램은 일단 suspend 상태가 된다. 그리고 live object를 inactive영역으로 copy하는 작업을 수행한다. object를 copy할때 각각의 reference 정보도 같이 변경된다.

이렇게 작업이 끝나면 active영역에는 garbage object만 남아 있게 되고 inactive 영역에는 live object만이 남아 있게 된더. 그런데 inactive영역에 object를 copy 할 때는 한쪽 방향에서부터 차곡차곡 적재를 하기 때문에 마치 compaction을 수행한 것처럼 정렬이 된 상태가 된다 이렇게 garbage collection이 완료되는 시점에서 active 영역은 모두 freememory가 되고 active 영역과 inactive 영역은 서로 바뀌게 된다. 이를 scavenge라고 한다.

fragmantation의 방지에는 효과적이기는 하지만 전첼 heap의 절반 정도를 사용하지 못한다는 단점이 존재한다. 또한 suspend현상과 copy에 대한 overhead는 필요악이라 할 수 있을 것이다.

generational algorithm

copy algorithm의 연장선상에 있다. heap을 active, inactive로 나누는 것이 아니라 age 별로 몇개의 sub heap으로 나눈다. object는 youngest generation sub heap 에 할당되고 그 곳에서 성숙하게 되면 그 다음 age에 해당하는 sub heap으로 올라가 결국 oldest generation sub heap 까지 promotion하는 방식으로 동작한. age가 임계값을 넘엇 다른 generation으로 copy되는 것을 promotino이라고 한다.

무엇보다 이 algorithm의 장점은 각 sub heap에서 각각 적절한 algorithm을 적용 할수 있다는 것이다 이러한 장점으로 인해 hosspotjvm이나 ibm jvm에서도 generational algorithm을 사용하고 있다

train algorithm

Heap을 작은 Memory Block으로 나누어 Single Block 단위로, Mar Phase와 Copy Phase로 구성된 Garbage Collection을 수행한다.이러한 특징때문에 이 algorithm은 incremental algorithm이라고도 한다.

garbage collection을 수행하는 단위가 single block 인 만큼 전체 heap의 suspend가 아닌 collection 중인 memtory block만 suspend가 발생한다 다시 말해 suspend를 분산시켜 전체적인 pause time을 줄이자는 아이디어인 것이다.

heap을 tran으로 구성한다 이 train은 car라고 불리는 fixed size의 memory block을 묶어 놓은 체인이다. train은 필요에 따라 car를 추가 할수도 있고 하나의 train이 추가 될 수도 있다. 그리고 각 memory block은 car외부에서의 참조를 기억하는 remember set이라는 장치가 있다. 이러한 구조 때문에 train algorithm이라는 명칭을 사용하게 되었다.

remember set은 train algorithme이 single block 단위로 garbage collection을 한다는 의미에서 상당히 중요하다 copy나 compaction을 통해 objectr가 이동을 하게 되면 당연히 그 주소가 변경될 것이고 이를 참조하는 object들도 따라서 reference가 변겨이 되어야한다. 그런데 obejct가 이동을 하게 되면 당연히 그 주소가 변경될 것이고 이를 참조하는 object들도 따라서 reference가 변경이 되어야 한다. 그런데 object는 자신이 참조하는 refence는 가지고 있지만, 누가 나를 참조하고 있는지에 대한 정보는 가지고 있지 못하다. 그렇기 때문에 이동한 object를 누가 참조하고 있는지를 알기 위해서는 , 최악의 경우 모든 root set과 object의 reference를 모두찾아 다녀야 하는 경우가 발생한다. 이경우 suspend의 분산 효과는 현저히 떨어진다.

remember set은 이러한 일을 방지하는 효과가 있다. remember set을 구성하기 위해서는 write barrier라는 장치를 동반하게 된다. wite barrierㅇ는 간단한 코드로 되어 있는 instruction의 set, 즉 작은 이벤트 프로그램 또는 트리거 정도로 이해할 수 있다. 보통 write barrier는 reference 관계를 맺을때 대상 object가 같은 car에 있지 않을 경우 대상 object의 car에 있는 remember set에 기록하는 식으로 구성되어 있다

adaptive algorithm

지금까지 설명한 것과는 달리 특정 collection방법을 지칭하는 것은 아니다. heap의 현재 상황을 모니터링하여 적절한 algorithm을 선택 적용하는 것 또는 heap sizing을 자동화하는 일련의 방법을 의미한다. 이것은 hotspot jvm의 ergonomics 기능 또는 adaptive optino이나 ibm jvm의 tilting 기능 등으로 구현이 되고 있다.

Creative Commons License
GC 알고리즘 by Voyager of Linux is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

유용한 JVM 플래그들 – Part 8 (GC Logging)

이 씨리즈의 마지막은 가비지 컬렉션 로깅과 연관된 플래그들이다. GC 로그는 힙의 잠재적인 개선, GC설정 이나 애플리케이션의 객체할당 패턴을 들어내주는 아주 중요한 툴이다. 각 GC가 발생하면, GC 로그는 과정과 결과에 대한 정밀한 데이터를 제공한다.

-XX:+PrintGC

-XX:+PrintGC 나 혹은 별명인 -verbose:gc 는 모든 young generation GC와 모든 풀GC에 대해 라인으로 출력되는 단순히 GC 로깅 모드를 활성화한다. 예를들면 다음과 같다.

라인의 시작은, ‘GC’ 혹은 ‘Full GC’, GC 타입이다. 그 다음이 GC 전과 후에(화살표로 구분되는) 점유 힙 메모리고 괄호안에 용량은 현재 힙의 용량이다. 라인의 끝은 GC가 수행된 시간이다(초단위 시간).

따라서, 첫째라인에서, 246656K→243120K(376320K) 는 GC가 점유 힙 메로리를 246656K 에서 243120K 로 줄였다는 뜻이다. GC 당시에 힙 용량은 376320K 이고 GC 는 0.0929090 시간을 소비했다.

단순한 gC 로깅 포캣은 사용되는 GC 알고리즘과 아무런 상관이 없고 더이상 상세함을 제공하지 않는다. 위의 예제에서 우리는 GC가 young 에서 old generation 으로 객체가 이동될때에 로그에 기록할 수 없다. 그러한 이유로, 상세한 GC 로깅은 단순한 로깅보다 훨씬 유용하다.

-XX:+PrintGCDetails

만약 -XX:+PrintGC 보다 -XX:+PrintGCDetails 를 사용한다면, 우리는 사용되는 GC 알고리즘에따라 달라지는 “상세한” GC 로깅 모드를 활성화 한다. 처리량 컬렉터를 사용하는 young generation GC 에 의해서 생성된 출력을 살펴보는 것으로 시작한다. 좀 더 읽기 편하게, 나는 출력물을 몇개의 라인으로 나누고 그들을 들여쓰기를 했다. 실제 로그에서, 이것은 한줄이며 사람이 읽기는 불편하다.

우리는 단순한 GC 로그로부터 몇가지 요소를 알수 있었다. 점유 힙 메모리를 246648K 에서 243136K 감소시키고 0.0935090 초를 소비한 young generation GC가 있다. 추가로, young generation 자체에 대한 정보를 얻는데, 이것의 용량과 점유률뿐만아니라 사용된 컬렉터가 무엇인지를 알 수 있다. 위 예제에서, “PSYoungGen” 컬렉터는 점유된 young generation 힙 메모리가 142816K 에서 10752K 로 줄일 수 있었다.

우리는 young generation 용량을 알고 있기 때문에, young generation 이 다른 객체할당을 수용할 수 없기때문에 GC를 발생시켰다라고 쉽게 이야기할 수 있다. 활용가능한 142848K 중에 142816K 이 사용되었다. 게다가, 우리는 우리는 young generation에서 제거 된 개체의 대부분이 아직 살아 있고 old generation 으로 이동되었다고 결론 내릴 수 있다: 142816K→10752K(142848K) 와 246648K→243136K(375296K) 를 비교해 young generation 이 거의 완벽하게 비였음에도 불구하고, 전체 힙 점유률은 거의 같게 남았다.

상세 로그 섹션의 “Times”은 GC에 의해서 사용된 운영체제의 커널 공간(“sys”), 사용자 공간(“user”)으로 나뉜 CPU 시간에 대한 정보를 포함한다. 또, GC가 동작중에 소비한 real time(“real”) 가 보인다. (0.09 sms 로그에서 보여준 0.0935090 시간의 반올림일 뿐이다.) 만약 위 예제처럼 CPU time 이 소비된 real time 보다 상당히 높다면 GC가 다중 쓰레드를 사용해 동작했다고 결론내릴 수 있다. 이러한 경우, 기록된 CPU time 은 모든 GC 쓰레드들의 CPU time의 총 합이다. 그리고 추가로, 나는 위 예제에서 컬렉터가 8개의 쓰레드를 사용했다고 말할 수 있다.

이제 풀GC 출력에 대해서 생각해보자.

young generation 에 대한 추가된 상세함으로 인해서 old 와 permanert generation 에 대해 상세함을 우리에게 제공해준다. 전체 세가지 세대들에 대해, 우리는 사용된 컬렉터, GC 전후에 점유율, GC 시에 용량을 알 수 있다. 주목할 것은 총 힙에 대해 보여준 각 숫자는 ( 243136K→241951K(628736K) ) 는 young 과 old generation 의 숫자 합과 같다. 위 예제에서, 241951K 의 총 힙을 점유했고 9707K 는 young generation, 232244K 는 old generation 을 점유했다. 풀GC는 1.53초 소비됐고 user space에서 CPU time 10.96 초는 GC가 다중 쓰레드로 상되었음을 보여준다.(위와같이 8개 쓰레드)

다른 세대들에대한 상대한 출력은 GC 발생에대한 추론을 가능하게 한다. 만약에, 모든 세대에 대해, GC전에 점유한 로그 상태가 거의 현재 용량과 같다면 이 세대는 GC가 발생가능성이 높다. 하지만, 위 예제에서, 이것은 세가지 세대에대해 해당되지 않는다. 그러면 무엇이 이 경우에 GC를 발생시켰을까? 처리율 컬렉터에서 GC 인체공학이 세가지 세대중에 하나가 고갈되기전에 GC가 이미 실행되어야 한다고 결정했다면 실제로 이러한 일이 발생될 수 있다.

풀GC 또한 애플리케이션이나 외부 JVM 인터페이스중에 하나를 통해서 명시적으로 요청이 있을때에 발생될 수도 있다. “system GC” 경우에는 GC 로그에서 “Full GC” 대신에 “Full GC(System)”으로 시작되는 라인을 가지기 때문에 쉽게 파악할 수 있다.

시리얼 컬렉터(Serial Collector) 에서, 상세 GC 로그는 처리량 컬렉터와 매우 유사하다. 한가지 다른 점이라면 다른 GC 알고리즘을 사용하고 있기 때문에 다양한 섹션들에 이름들이 다르다.(예를들어, old generation 섹션은 “ParOldGen” 대신에 “Tenured” 라 부른다). 정확한 이름의 컬렉션을 사용하는 것이 좋은데, JVM의 의해서 사용되어지는 특정 가비지 컬렉션의 로그로부터 추론을 할 수 있기 때문이다.

CMS 컬렉터(CMS Collector)에서, young generation GC에 상세 로그는 역시 처리량 컬렉션과 매우 유사하지만 old generation GC에 대해서는 같지 않다. CMS 컬렉터에서 old generation GC들은 다른 단계를 사용해 애플리케이션에 동시적으로 작동한다. 그렇기 때문에, 그것의 출력은 풀GC 출력과 다르다. 추가적으로 다른 단계에대한 라인들은 일반적으로 동시적 컬렉션이 동작중에 발생된 young generation GC 에대한 라인에 의해서 로그와 분리된다. 다른 컬렉터들을 이미 봐왔기 때문에 GC 로그의 모든 요소들이 익숙하고 그래서 다른 단계에 대한 로그를 이해하기란 어렵지 않다. 다만 처리중일때에 특별히 조심하고 애플리케이션과 동시적으로 모든 단계가 실행된다는 것을 상기해야만 한다. 따라서, 반대되는 stop-the-world 컬렉션들처럼, 개별적인 단계 혹은 전체 GC 주기가 오랫동안 실행되는 시간이 항상 문제가 있다는 것은 아니다.

이 시리즈의 part 7에서 알아봤듯이, 풀GC들은 CMS 컬렉터가 재시간에 CMS 주기가 완료되지 않으면 발생 될 수 있다. 만약 그게 발생하면, GC 로그는 추가적으로 풀GC 발생 원인이 무엇인지와 같은 힌트를 포함한다. 예를들어, “concurrent mode failure” 와 같은.

이 기사를 짧게 유지하기 위해서, 나는 CMS 컬렉터 GC 로그의 상세한 설명을 자제할 것이다. 또, 실제 컬렉터 작성자중에 한분이 여기에 이미 훌륭한 설명을 발표했다. 나는 이것을 읽기를 강력히 추천한다.

-XX:+PrintGCTimeStamps and -XX:+PrintGCDateStamps

이것은 (단순하게 혹은 상세하게) GC 로그에 시간과 날짜 정보를 추가하는게 가능하다. -XX:+PrintGCTimeStamps 에서 timestamp 은 JVM이 시작된 이후에 초단위로 흐른 실제시간을 반영하도록 매 라인마다 추가된다. 예를들어

그리고 -XX:+PrintGCDateStamps 를 지정하면 로그가 쓰여질때에 각 시작 라인이 절대 날짜와 시간을가지고 시작된다.

두가지 출력이 좋아보이면, 두 플래그 조합이 가능하다. 나는 항상 두가지 플래그를 지정하도록 권하는데, 그러한 정보는 다른 소스들로부터 데이터를 가지는 GC 로그 데이터를 연관시키기위해 매우 유용하다.

-Xloggc

기본적으로 GC 로그는 stdout 에 쓰여진다. 대신 -Xloggc:<file> 로 우리는 출력 파일을 지정할 수 있다. 주목할 것은 이 플래그는 -XX:+PrintGC 과 -XX:+PrintGCTimeStamps 처럼 묵시적으로 지정한다. 역시, 나는 필요하다면 이러한 플래그들을 명시적으로 지정하길 권하는데, 새로운 JVM 버전들에 예기치않은 변화로부터 여러분들로부터 보호해준다.

“Manageable” Flags

자주 논의되는 것중에 프로덕트 시스템에 JVM에 GC 로깅을 활성화해야하느냐 마느냐 하는 것이다. GC 로깅의 오버헤드는 보통 매우 적다라는데 나는 분명히 “yes”다. 하지만, 이것은 JVM이 시작할때에 우리는 GC 로깅에 대한 고민을 할 필요가 없다건 좋은 것이다.

HotSpot JVM 은 “manageable”이라 불리우는 특별한(하지만 아주 작은) 카테고리 플래그들을 가진다. 관리 플래그들에 대해 런타임으로 그들의 값을 변경하는 것이 가능하다. 여기서 논의한 모든 플래그들과 “PringGC” 로 시작하는것들이 “manageable” 카테고리에 속한다. 따라서, 우리는 실행중인 JVM에서 우리가 원할때마다 언제든지 GC 로깅을 활성화하거나 비활성화할 수 있다. 관리 플래그들을 지정하기 위해서 우리는 JDK에 포함된 jinfo 를 사용하거나 JMX 클라이언트와 HotSpotDiagnostic MXBean 의 연산인 setVMOption를 호출해 가능하다.

 

Creative Commons License
비공개: 유용한 JVM 플래그들 &#8211; Part 8 (GC Logging) by Voyager of Linux is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.