몇일 전에 Apache 재단에서 제작해 배포하는 Log4j2 에 대해, 보안 취약점 등급 10등급으로 즉시 취약을 말하면서 보안설정과 패치를 하라는 권고를 했다. 이는 전 세계적인 현상으로 우리나라 뿐만 아니라 미국등에도 매우 심각한 현상임을 인지하고 뉴스에도 나올만큼 큰 뉴스거리가 되었다. Log4j2 만 문제냐 하지만 이 업계에 10년 넘게 밥벌이를 하는 입장에서 별로 놀랍지도 않고 왜 그렇게 호들갑이냐 하는 생각이 먼저 든다. 모르는 사람이야 뉴스에도 나오고 전문가들이 심각하다고 하는데 ‘호들갑’ 이라고 말하니 내가 뭔가 잘못 말한것처럼 생각이 들겠지만 실상을 알고 나면 그렇지 않다는걸 […]
Java
스트림(Stream)
자바(Java) 세계에서 언제부터인지 스트림(Stream) 이라는 단어를 목격하게 되었다. 내 기억으로는 Java 8 에서부터 시작된 것 같은데 난데없는 이 단어가 왜 그렇게 핵심이 되었는지가 의문이였다. 도대체 왜 스트림(Stream) 이냐 하는 질문에 대한 대답을 듣기도 어려웠던 시절이기도 하다. 그져 사용하는 방법을 익히는데에 몰두하는 모습만 목격됐을 뿐이다. java.util.stream 스트림(Stream) 에 대한 정의는 다양하다. 데이터 소스(Array, List) 로부터 흐름을 가지는 데이터의 집합체이며 통합연산을(bulk processing) 통해 데이터를 변형시키고 최종적으로 소비자가 그 데이터를 소비하도록 한다. 스트림을 다루게 되면 항상 다음과 같은 데이터 소스들을 만나게 된다. 모두 […]
Java, Programming
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 […]
Java, Programming
유용한 JVM 플래그들 – Part 8 (GC Logging)
이 씨리즈의 마지막은 가비지 컬렉션 로깅과 연관된 플래그들이다. GC 로그는 힙의 잠재적인 개선, GC설정 이나 애플리케이션의 객체할당 패턴을 들어내주는 아주 중요한 툴이다. 각 GC가 발생하면, GC 로그는 과정과 결과에 대한 정밀한 데이터를 제공한다. -XX:+PrintGC -XX:+PrintGC 나 혹은 별명인 -verbose:gc 는 모든 young generation GC와 모든 풀GC에 대해 라인으로 출력되는 단순히 GC 로깅 모드를 활성화한다. 예를들면 다음과 같다.
|
1 2 |
[GC 246656K->243120K(376320K), 0,0929090 secs] [Full GC 243120K->241951K(629760K), 1,5589690 secs] |
라인의 시작은, ‘GC’ 혹은 ‘Full GC’, GC 타입이다. 그 다음이 GC 전과 후에(화살표로 구분되는) 점유 힙 메모리고 괄호안에 용량은 현재 힙의 용량이다. 라인의 […]
Java, Programming
유용한 JVM 플래그들 – Part 7 (CMS Collector)
HotSpot JVM의 CMS 컬렉터(The Concurrent Mark Sweep Collector)는 주요한 목표중에 하나를 가진다: 낮은 애플리케이션 일시정지 시간. 이 목표는 웹 애플리케이션과 같은 대부분의 상호작용 애플리케이션들에게 중요하다. 관련된 JVM 플래그들을 살펴보기전에, 짧막하게 CMS 컬렉터 운영과 이것을 사용할때에 부닥치게될 주요 이슈들에대한 요점을 다룰것이다. 처리량 컬렉터와 같이, CMS 컬렉터는 old generation 에서 객체들을 다루지만 그 운영방식은 훨씬더 복잡하다. 처리량 컬렉터는 늘 애플리케이션 쓰레드들을 잠시 멈추게하지만, 아마도 적지않은 시간, 그 시간을 애플리케이션이 안전하게 무시할수 있도록 한다. 그와 대조적으로, CMS 컬렉터는 대부분 애플리케이션 쓰레드들과 동시적으로 실행되도록 디자인되었고 아주 적은(혹은 짧은) 잠시 정지시간만 발생시킨다. 응용프로그램과 동시에 […]
Java, Programming
유용한 JVM 플래그들 – Part 6 (Throughput Collector)
실제로 우리가 찾은 대부분의 애플리케이션 영역에서, 가비지 컬렉션(GC) 알고리즘은 두가지 기준에 따라 평가되어져 왔다. 보다 높은 처리율을(throughput) 달성하기 위한 좀 더 나은 알고리즘 결과적으로 좀 더 적은 일시 정지시간을(pause times) 가지는 좀 더 나은 알고리즘 먼저, 우리는 GC 맥락에서 “일시 정지시간” 과 “처리율” 말을 명확하게 할 필요가 있다. JVM은 항상 전용의 쓰레드에서, “GC 쓰레드”라 부르는, GC를 수행한다. GC 쓰레드가 활성화될때마다, 그들은 활용할 프로세서와 CPU 시간을 가지고 활동적인 “application 쓰레드”들과 경쟁한다. 조금 단순화하면, 우리는 애플리케이션 쓰레드들이 실행중일때에 전체 프로그램 실행 시간의 […]
Java, Programming
유용한 JVM 플래그들 – Part 5 (Young Generation Garbage Collection)
이번 시간에 우리는 주요한 힙 영역의 하나인 “young generation” 에 집중한다. 첫째로, 우리는 우리의 애플리케이션의 성능에 아주 중요한 young generation의 알맞은 설정이 무엇인지 논의한다. 그리고나서 우리는 적절한 JVM 플래그들에 대해서 알아보도록 하자. 순수하게 기능적인 관점에서, JVM은 young generation 을 전혀 필요하지 않는다. – 그것은 하나의 힙 영역으로만으로도 동작한다. 첫위치에 young generation 을 가져야할 유일한 이유는 가비지 컬랙션(Garbage Collection, GC) 성능을 최적화하는데 있다. 구체적으로, young generation 과 old generation 으로 힙의 분리는 두가지 장점을 가진다. 새로운 객체의 할당을 간소화해주고 (왜냐하면 메모리 […]
Java, Programming
유용한 JVM 플래그들 – Part 4 (힙 튜닝)
이상적으로, 자바 애플리케이션은 아무런 플래그를 지정하지 않은채 기본 JVM 세팅만으로도 잘 동작한다. 하지만 운이 나쁘게도 성능적인 문제에 직면했을때, 관련 JVM 플래그에 대한 지식들은 훌륭한 안내서가 된다. 이번시간에는 메모리 관리 영역에 대한 몇몇 JVM 플래그들을 살펴볼 것이다. 이러한 플래그들에 대해서 알고 있는 것과 이해하는 것은 개발자나 운영자로서의 높은 가치를 증명한다. 모든 설치된 HotSpot 메모리 관리와 가비지 컬렉션 알고리즘은 힙(Heap)의 동일한 기본 분할에 기초한다: “young generation” 은 새롭게 메모리가 할당된 것과 짧은 삶을 사는 객체를 가진다. 반면에 “old generation” 은 특정연령 이상 수명이 긴 […]
Java, Programming
유용한 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} |
각 테이블 […]