분류 전체보기: 2105개의 글
Throughput Collector Minor GC 동작 과정 요약 Throughput Collector Minor GC Throughput Collector Minor GC Log PrintGCDetails 플래그를 활성화 시켜서 발생한 Minor GC 로그를 보면 다음과 같다 Throughput Collector Full GC 동작 과정 요약 Throughput Collector Full GC Log [출처] [JVM] Throughput Collector - GC Log
4개의 GC 알고리즘에 공통적으로 적용되는 기본적인 튜닝 방법에 대해 알아보자 Heap Size 힙이 너무 작다면 너무 자주 GC가 일어날 것이고, 힙이 너무 크다면 중단은 줄어들지만 Full GC가 발생했을 때 중단 시간이 너무 길어진다. OS 메모리와 힙 사이즈 힙 사이즈는 [물리적 RAM - (OS에서 사용하는 RAM)] 보다 작게! OS는 스와핑, Paging을 통해 메모리를 가상화시켜서 관리한다. 예를들어 OS는 실제로 PC의 RAM은 8GB이지만 가상화를 통해 16GB로 보이도록 제공한다. 이때, 실제로 물리적인 RAM은 8GB이기 때문에, 나머지 8GB를 디스크에서 가져와서 사용한다. 이 과정은 사용자에게는 투명하지만 내부적으로 디스크에 있는 데이터에 접근할때마다 느려질 것이다. 힙 크기를 ..
GC 알고리즘을 살펴보기 전에, GC 기본 개념에 대해 다시 살펴보자 [JVM] GC 기본개념 - JVM메모리 구조 / Minor GC / Full GC 자바에서 가비지 컬렉터는 대부분의 객체는 한번 쓰고 버려진다는 사실을 이용해서 설계되었다. JVM에서 사용할 수 있는 가비지 컬렉터에는 여러 종류가 있다 모든 가비지 컬렉터는 힙을 별도의 제너레이션으로 나눠서 작업한다 Young 영 / Old 올드 영 제너레이션은 Eden 에덴과 Survivor Space 서바이버 스페이스로 나뉜다 Minor GC 모든 GC 알고리즘은 영 제너레이션에서 수집하는 동안 모든 어플리케이션 스레드를 중지시킨다. 매우 빨리 일어나는 작업이다. 객체는 처음 생성되면 먼저 힙의 영 제너레이션에 할당된다. 영 제너레이션이 가득차면 ..
컴파일 과정 모니터링 JVM의 PrintCompilation 옵션을 활성화시켜서 컴파일 로그를 확인하자 그리고 컴파일 되어야 하는 코드가 예상대로 컴파일 되고 있는지 확인하자 -XX:+PrintCompilation ( default : false ) - 메서드나 루프가 컴파일될 때마다 컴파일된 대상에 대한 정보를 출력한다 컴파일 로그 형식 [timestamp compilation_id attributes (tiered_level) method_name size deopt] - timestamp : JVM 시작시간을 0으로 했을 때, 컴파일이 끝난 시간 - attributes : 컴파일되고 있는 코드의 상태를 기호로 나타낸다. 1) % : OSR 컴파일을 의미 2) s : 메소드가 동기화됨 3) ! : 메..
컴파일러와 인터프리터 인터프리터는 코드를 한줄 읽고 바로 결과를 출력한다. 같은 기능을 하는 코드가 다시 나와도 또 다시 해석하여 결과를 출력한다. 컴파일러는 한번만 소스코드를 컴파일하여 같은 기능을 하는 코드가 있으면 미리 컴파일된 결과를 이용하여 결과를 출력한다. 때문에 한 번만 실행될 코드라면 인터프리터가 더 빠르다. 하지만 많이 실행될 코드라면 컴파일을 하는 것이 좋다. JIT : Just In Time, 그때그때! 핫스팟 JVM의 핵심, 컴파일 방법중 하나 핫스팟이란, 가장 자주실행되는 영역을 의미한다. 가장 자주실행되는 영역만을 컴파일한다고 생각하면 된다. 핫스팟 JVM은 코드를 바로 컴파일하지 않는다. 먼저 인터프리터가 동작하여 코드를 실행한다. 일정시간 동안, 인터프리터가 코드를 해석하며 ..
펌 영역에서 OOME(Out Of Memory Error)가 발생하면 아래와 같이 로그가 남는다 펌( PERM : Permanent Generation) 영역은 객체의 생명주기가 영구적일 것으로 생각하는 객체들을 관리한다. 이 영역은 GC대상에서 제외된다. 주로 자바의 Class 객체들이나 문자열에 속한 String 객체들이 위치한다. Class 객체들은, 시스템의 Classpath에 잡힌 객체들 또는 사용자에 의해 다이나믹하게 로드되는 클래스들이 있다. Spring같은 프레임워크들은 다이나믹하게 사용자가 정의한 클래스 정보를 로드한다. 주로 이 때 다이나믹하게 로드되는 클래스들에 의해 PERM영역의 OOME가 발생한다. 어떤 클래스 정보를 로드할 때, 해당 클래스의 정보만 로드하는 것이 아니라, 클래스..
CPU 사용률 $ top // 명령을 이용하면 CPU사용률을 볼 수 있다. 아래와 같이 bash가 75.2%의 CPU를 사용하는데 괜찮은 것일까? 가끔 컴퓨터가 버벅거릴때, CPU사용률을 보면 100%가 되는것들이 있다. 그때문에 CPU사용률이 100%가되면 문제가 있는것이라고 생각할 수 있는데, 그렇지 않다. CPU사용률은 특정 시간에 대한 평균값이다. 스레드마다 실행되는 시간이 정해져있고, 시간을 다 소모하게되면 다른 스레드가 돌고, 자기차례가 다시 돌아올때까지 유휴기간을 갖는다. 자신이 CPU사용시간을 받았을때, 사용시간 동안 CPU 를 사용한 퍼센트이기 때문에 높을수록 좋다. 따라서 CPU에 관해서, 성능을 높히기 위한 방법은 짧은 시간 동안 CPU 사용률을 가능한 높히는 것 CPU 사용시간은 두..
Heap 힙! 동적으로 할당되어 사용할 수 있는 메모리 영역 주로 실행중에 생성되는 객체들이 저장되고, 실행 후 제거되는 영역 GC(Garbage Collection)의 대상의 되는 메모리 영역 가비지 컬렉터는 가비지 컬렉션을 통해 힙 영역에 있는 사용되지 않는(더이상 참조가 없는) 객체를 회수한다. Memory Leak 메모리 누수! 힙 영역에 있는 동적으로 할당된 객체가, 더이상 사용되지 않음에도 불구하고 가비지 컬렉터에 의해 회수되지 않고 메모리에 남아있어서 자리만 차지하는 현상 메모리 누수가 쌓이면 메모리가 부족하게되서 결과적으로 OutOfMemoryError 가 발생한다 가비지 컬렉터는 메모리 누수인지도 모르고, 메모리가 부족하니까 계속 메모리를 회수하려고 가비지 컬렉션을 지속적으로 발생시킨다...
● GC (Garbage Collection) Java Application에서 사용하지 않는 메모리를 자동으로 수거하는 기능 C언어의 경우 malloc, free등을 이용해서 메모리를 할당하고, 일일이 그 메모리를 수거해줘야했다. 그러나 Java 언어에서는 GC가 알아서 해준다. ● Stop-the-world GC를 실행하기 위해 JVM이 어플리케이션의 실행을 멈춘다. 이를 Stop-the-world라고 한다. GC 튜닝이란, 이 Stop-the-world의 시간을 줄이는 것이다. ● Generational GCs 대부분의 객체는 오랜시간동안 살아있지 않는다. 오래된 객체에서 젊은 객체로의 참조는 아주 적게 존재한다. 이러한 두 가지에 조건하에 가비지 컬렉터를 효율적으로 동작시키기 위해 HotSpot ..
JVM에는 여러 종류가 있다. JVM Specification에 JVM의 기능을 명세한다. JVM Specification을 구현한 여러 JVM이 존재하게된다. 명세서는 구글에 검색하면 언제든지 볼 수 있다. JVM 명세서를 구현한 대표적인 JVM으로 Hotspot과 JRockit이 있다. 두 개로 나뉜 이유는 간단히 각각 특화된 부분이 다르기 때문이다. Hotspot은 클라이언트 용 어플리케이션에 특화되었다. 반면에 JRockit은 서버용 프로세스에 특화되었다. JRockit은 Oracle Weblogic Server의 디폴트 JVM이고, Hotspot은 Java JDK/JRE의 디폴트 JVM이다. 메모리 구조 또한 다르다. 여기서는 그냥 이런게 있구나~하고 넘어가자. 나중에 알게된다. Hotspot ..