HotSpot JVM의 CMS 컬렉터(The Concurrent Mark Sweep Collector)는 주요한 목표중에 하나를 가진다: 낮은 애플리케이션 일시정지 시간. 이 목표는 웹 애플리케이션과 같은 대부분의 상호작용 애플리케이션들에게 중요하다. 관련된 JVM 플래그들을 살펴보기전에, 짧막하게 CMS 컬렉터 운영과 이것을 사용할때에 부닥치게될 주요 이슈들에대한 요점을 다룰것이다. 처리량 컬렉터와 같이, CMS 컬렉터는 old generation 에서 객체들을 다루지만 그 운영방식은 훨씬더 복잡하다. 처리량 컬렉터는 늘 애플리케이션 쓰레드들을 잠시 멈추게하지만, 아마도 적지않은 시간, 그 시간을 애플리케이션이 안전하게 무시할수 있도록 한다. 그와 대조적으로, CMS 컬렉터는 대부분 애플리케이션 쓰레드들과 동시적으로 실행되도록 디자인되었고 아주 적은(혹은 짧은) 잠시 정지시간만 발생시킨다. 응용프로그램과 동시에 […]
유용한 JVM 플래그들 – Part 6 (Throughput Collector)
실제로 우리가 찾은 대부분의 애플리케이션 영역에서, 가비지 컬렉션(GC) 알고리즘은 두가지 기준에 따라 평가되어져 왔다. 보다 높은 처리율을(throughput) 달성하기 위한 좀 더 나은 알고리즘 결과적으로 좀 더 적은 일시 정지시간을(pause times) 가지는 좀 더 나은 알고리즘 먼저, 우리는 GC 맥락에서 “일시 정지시간” 과 “처리율” 말을 명확하게 할 필요가 있다. JVM은 항상 전용의 쓰레드에서, “GC 쓰레드”라 부르는, GC를 수행한다. GC 쓰레드가 활성화될때마다, 그들은 활용할 프로세서와 CPU 시간을 가지고 활동적인 “application 쓰레드”들과 경쟁한다. 조금 단순화하면, 우리는 애플리케이션 쓰레드들이 실행중일때에 전체 프로그램 실행 시간의 […]
유용한 JVM 플래그들 – Part 5 (Young Generation Garbage Collection)
이번 시간에 우리는 주요한 힙 영역의 하나인 “young generation” 에 집중한다. 첫째로, 우리는 우리의 애플리케이션의 성능에 아주 중요한 young generation의 알맞은 설정이 무엇인지 논의한다. 그리고나서 우리는 적절한 JVM 플래그들에 대해서 알아보도록 하자. 순수하게 기능적인 관점에서, JVM은 young generation 을 전혀 필요하지 않는다. – 그것은 하나의 힙 영역으로만으로도 동작한다. 첫위치에 young generation 을 가져야할 유일한 이유는 가비지 컬랙션(Garbage Collection, GC) 성능을 최적화하는데 있다. 구체적으로, young generation 과 old generation 으로 힙의 분리는 두가지 장점을 가진다. 새로운 객체의 할당을 간소화해주고 (왜냐하면 메모리 […]
유용한 JVM 플래그들 – Part 4 (힙 튜닝)
이상적으로, 자바 애플리케이션은 아무런 플래그를 지정하지 않은채 기본 JVM 세팅만으로도 잘 동작한다. 하지만 운이 나쁘게도 성능적인 문제에 직면했을때, 관련 JVM 플래그에 대한 지식들은 훌륭한 안내서가 된다. 이번시간에는 메모리 관리 영역에 대한 몇몇 JVM 플래그들을 살펴볼 것이다. 이러한 플래그들에 대해서 알고 있는 것과 이해하는 것은 개발자나 운영자로서의 높은 가치를 증명한다. 모든 설치된 HotSpot 메모리 관리와 가비지 컬렉션 알고리즘은 힙(Heap)의 동일한 기본 분할에 기초한다: “young generation” 은 새롭게 메모리가 할당된 것과 짧은 삶을 사는 객체를 가진다. 반면에 “old generation” 은 특정연령 이상 수명이 긴 […]
유용한 JVM 플래그들 – Part 3 (모든 XX 플래그들과 값들을 프린팅하기)
최근 java 6 의 업데이트 (반드시 20이나 21로 업데이트되 있어야하는), HotSpot JVM은 JVM이 시작되자마자 커맨드라인에 모든 XX 플래그들과 그들의 값을 테이블로 출력하도록 하는 두 개의 새로운 커맨드라인 플래그들을 제공한다. 많은 HotSpot 사용자들은 첫번째 자바버전 이후부터 이러한 기능들을 원했었는데, 그래서 나는 이 글의 주제를 이것으로 하기로 했다. -XX:+PrintFlagsFinal and -XX:+PrintFlagsInitial 바로 새로운 플래그들에 대한 출력물들을 살펴보도록 하자. -XX:+PrintFlagsFinal 사용해 클라이언트 VM 을 시작하면 알파벳으로 정렬된 590개의 XX플래그 테이블을 얻게된다. (주의할 것은 각 HotSpot버전마다 플래그 숫자는 다를 수 있다.)
|
1 2 3 4 5 6 7 8 9 10 11 |
$ java -client -XX:+PrintFlagsFinal Benchmark [Global flags] uintx AdaptivePermSizeWeight = 20 {product} uintx AdaptiveSizeDecrementScaleFactor = 4 {product} uintx AdaptiveSizeMajorGCDecayTimeScale = 10 {product} uintx AdaptiveSizePausePolicy = 0 {product} [...] uintx YoungGenerationSizeSupplementDecay = 8 {product} uintx YoungPLABSize = 4096 {product} bool ZeroTLAB = false {product} intx hashCode = 0 {product} |
각 테이블 […]
유용한 JVM 플래그 – Part 2 (플래그 카테고리들과 JIT 컴파일러 진단들)
두번째 시간으로, HotSpot JVM에서 제공하는 플래그의 다른 카테고리들을 소개한다. 또한, 나는 JIT 컴파일러 진단(diagnostics)와 연관된 몇가지 흥미로운 플래그들에 대해서 이야기할 것이다. JVM 플래그 카테고리들 HotSpot JVM은 세개의 플래그 카테고리들을 제공한다. 첫번째 카테고리는 표준 플래그(stand flag)들을 포함한다. 이름에서도 알수 있듯이, 기능적인부분과 표준 플래그들의 출력 모두 안정적이며 미래에 릴리즈 되는 JVM에서 잘 바뀌지 않을 것이다. java 실행시에 아무런 파라메터를 주지않으면 모든 표준 플래그 리스트들을 얻을 수 있다.(혹은 표준 출력이 있는 -help 파라메터를 사용하거나) 우리는 첫번째 시간에 몇몇 표준 플래그들을 이미 봤었다. 예를들어 […]
유용한 JVM 플래그 – Part 1 (JVM 타입들과 컴파일러 모드들)
현대의 JVM들은 효율적이고 안정적인 방법으로 자바 애플리케이션을(혹은 JVM과 호환되는 프로그래밍 언어들) 실행시키는 놀라운 일을 한다. 맞춤 메모리 관리(Adaptive memory management), 가비지 컬렉션(garbage collection), just-in-time compilation, 동적 클래스로딩(dynamic classloading), 락 최적화(lock optimization) – 이러한 것이 마법처럼 인용되지만 일반적인 프로그래머들에게 직접적으로 영향을 주진 않는다. 실행 시점에서, JVM은 지속적인 측정과 프로파일링을 기반으로 애플리케이션이나 그것의 일부를 핸들링하는 방법을 최적화한다. 여전히 JVM이 자동화 수준과 같은 것이나 그보다 못한 것들에 대해서 외부 모니터링이나 수동 튜닝을 위한 충분한 설비를 제공하고 있다는 것은 중요하다. 에러나 낮은 퍼포먼스의 경우에는 […]
[발 번역] 자바 가비지 컬렉션
이글은 Garbage Collectors Available In JDK 1.7.0_04 를 발 번역한 것입니다. Jack Shirazi 씨는 가비지 컬랙터가 무엇이고 오파클 자바 7 업데이트 4 JVM 에서 활용할 수 있는 가비지 컬렉터 조합에 대해서 말해줄 것입니다. Published June 2012, Author Jack Shirazi 마침내 G1 을 공식적으로 – i.e. 더 이상 실험적 가비지 컬렉터가 아니다 – 1.7.0_04 (Java 7 update 4) 릴리즈에서 지원되며 이것은 이제 Sun JVM 의 가비지 컬렉터 측면에서 활용가능한 가치있는 주식(?)을 가지는 중임을 말한다. 아래에 기술할 자세한 사항은 다른 많은 Sun JVM […]
JAVA에서 스크린 Refresh 하기
리눅스 터미널에서 실행되는 각종 모니터링 프로그램들을 보면 화면이 그대로 인채 수치만 바뀌는 형식을 취하는 프로그램들이 많다. 사실 터미널 스크린을 빠르게 Refresh 하는것인데, 자바에서는 다음과 같이 프로그래밍을 하면 된다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
import java.io.Console; public class monitor_jmx { public static final char ESC = 27; public static void main(String[] args) throws Exception{ // TODO Auto-generated method stub Console c = System.console(); if (c == null) { System.err.println("no console"); System.exit(1); } // clear screen only the first time c.writer().print(ESC + "[2J"); c.flush(); Thread.sleep(200); for (int i = 0; i < 100; ++i) { // reposition the cursor to 1|1 c.writer().print(ESC + "[1;1H"); c.flush(); c.writer().println("hello " + i); c.flush(); Thread.sleep(200); } } } |
Console 객체를 이용해 구현한다.
Jmxterm – 커맨드 라인 JMX
JAVA 에는 JMX(Java Management Extension) 이라고해서 JAVA 애플리케이션을 관리하기 위한 확장을 제공합니다. JAVA 애플리케이션을 시작할때에 다음과 같이 JVM 옵션을 주게되면 사용할 수 있습니다. -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port -Dcom.sun.management.jmxremote.authenticate -Djava.rmi.server.hostname -Dcom.sun.management.jmxremote.ssl hostname, port 그리고 authenticate 을 설정하면 특정 호스트에서 특정포트를 통해서 인증을 통해서 JMX 클라이언트를 통해서 접속할 수 있는데, JMX 클라이언트로 가장 유명한 것이 JConsole 입니다. 그런데, 보안상의 이유로 JMX 는 활성화하되 접속은 로컬호스트에서만 되도록 설정을 해놓는 경우가 많습니다. 다음과 같이 말입니다.
|
1 2 3 4 5 |
export JMX_OPTS=" -Dcom.sun.management.jmxremote \ -Dcom.sun.management.jmxremote.port=8090 \ -Dcom.sun.management.jmxremote.authenticate=false \ -Djava.rmi.server.hostname=localhost \ -Dcom.sun.management.jmxremote.ssl=false " |
대부분의 로컬호스트가 리눅스일 경우에는 JConsole 을 이용하기 위해서는 터미널의 터널링을 […]