태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

[ Enterprise Java는 거대한 동기화 머신이다 - GC ] Enterprise Java & Oracle 성능 분석의 기초 - Part5

Enterprise Java 2007.08.29 11:22
Enterprise Java는 거대한 동기화 머신이다.

Garbage Collection과 Thread 동기화
Enterprise Java 환경에서 성능에 가장 많은 영향을 미치는 동기화(Synchronization) 문제가 바로 Garbage Collection(GC)이다. WAS 환경을 구축하거나 운영해본 경험이 있는 사람이라면 누구나 GC 문제에 민감할 것이다. 어쩌면 치를 떨지도...?

GC가 발생하는 동안 Application Thread는 어떤 식으로든 작동을 멈추거나 지연이 발생하게 된다. 이런 멈춤(Pause)과 지연이 과도하면 Application의 성능에 치명적인 영향을 미치게 된다. Web Server-->WAS-->DB 로 이루어지는 복잡한 시스템에서는 WAS에서의 GC로 인한 작업 지연이 연쇄 작용을 일으켜 시스템 전체의 성능 저하를 유발할 수 있다.

일반적으로 GC에 의한 성능 저하 문제를 "동기화 문제"로 인식하는 경우가 잘 없기 때문에 "동기화"라는 용어에 고개를 갸우뚱할 지 모르겠다. 필자는 "GC"를 메모리라는 자원을 둘러싼 Thread 동기화의 문제로 보는 것이 가장 정확한 해석이라고 생각한다. Thread가 특정 메모리 영역을 사용하려고 하는 시점에 해당 메모리 영역에 대해 GC 작업이 발생하게 되면 Thread가 블로킹(Blocking)되면서 성능 저하 현상이 발생하는 것이 우리 겪는 GC의 성능 문제이다.

Garbage Collection와 JVM
JVM은 Sun이 정하는 표준이다. 하지만 GC 자체는 표준이 아니다. 다만, Java와 같이 메모리를 핸들링하는 API를 제공하지 않는 어플리케이션에서는 자동화된 메모리 해제 작업이 필요하기 때문에 Garbage Collection 기능이 필수가 된 것 뿐이다.

GC가 표준이 아니기 때문에, GC를 구현하는데 있어서 어떤 알고리즘을 쓸지 또한 전혀 약속된 바가 없다. 각 JVM 벤더들이 자신들 고유의 알고리즘을 통해 GC를 구현한다. 앞으로 몇 차례의 글을 통해 Sun HotSpot JVM과 IBM JVM의 GC의 작동방식과 장단점에 대해 깊이있는 논의를 하게 될 것이다.

Java의 메모리(Non-Heap + Heap) 관리 기법과 GC 알고리즘은 실과 바늘같은 관계이다. GC를 어떻게 할지에 따라 메모리 관리 기법이 결정된다는 것이 정확한 표현일 것이다.

Sun HotSpot JVM과 IBM JVM은 전혀 다른 종류의 GC 기법을 구현해왔다. 최근(특히 Java 5부터)에 와서는 서로의 장점을 흡수해서 상당히 비슷한 개념들을 제공하지만, 여전히 뚜렷한 차이점들을 보인다.

각 JVM이 제공하는 GC의 작동 방식과 장단점을 정확하게 이해해야만 합리적인 성능 개선이 가능하다.

GC의 성능을 보는 두가지 관점
[성능을 개선시킨다]라는 말은 매우 추상적이고 기준이 애매모호하다. 따라서 좀 더 정확한 기준을 정할 필요가 있다. 여기에는 무수히 많은 방법론과 기준이 있겠지만, 보편적으로는 다음과 같은 두 가지의 기준을 사용한다.
  • Throughput 개선: Throughput은 흔히 "처리량"으로 해석된다. 즉 주어진 시간내에 얼마나 많은 일을 하느냐가 곧 Troughput이다.
  • Response Time 개선: Response Time은 "응답시간"으로 해석된다. 즉 특정 요청에 대해 얼마나 빨리 응답을 보내느냐가 Repsonse Time의 기준이다.
Throughput과 Response Time은 상호 배반적인 속성을 지니고 있다. Throughput을 개선시키려면, 즉 주어진 시간내에 최대한 일을 많이 하려면 되도록 통신량을 줄이고 일을 모아서 처리할 수 밖에 없다. 이런 이유로 Throughput을 개선시키기 위해서는 Batch 프로세싱을 사용할 수 밖에 없다.

반면 Response Time을 개선시키려면 작업을 처리하면서 결과가 나오는 즉시 결과를 보내주어야 한다. 이런 이유로 Response Time을 개선시키려면 Looping 프로세싱을 사용할 수 밖에 없다.

(참고) 오라클과 같은 DBMS에서도 동일한 원리가 적용된다. 오라클의 OPTIMIZER_GOAL ALL_ROWS라면 Throughput 기준의 최적화를, FIRST_ROWS라면 Response Time 기준의 최적화를 수행하게 된다. 오라클의 PL/SQL 블록은 항상 수행단위가 블록이기 때문에 예외없이 Throughput 기준의 최적화가 수행된다. 오라클에서도 이 원리를 잘 이해해야만 최적의 쿼리 튜닝이 가능하다.

두 가지 종류의 Garbage Collector
위에서 설명한 이유때문에 어떤 JVM의 Garbage Collector라도 항상 두 가지 종류 이상(Throughput 기준 하나+Response Time 기준 하나)를 제공한다.

Sun HotSpot JVM
IBM JVM
Througput 기준
-XX:+UseParallelGC-Xgcpolicy:optthruput
Response Time 기준
-XX:+UseConnMarkSweepGC
-Xgcpolicy:optavgpause
기타-XX:+UseSerialGC-Xgcpolicy:gencon

Throughput 기준의 Garbage Collector는 공격적으로 GC를 수행한다. 사용자가 체감하는 응답 시간을 다소 희생하더라도 GC 작업 자체를 최대한 효율적이고 집중적으로 수행할 수 있도록 한다. 따라서 GC 작업 시간이 다소 길 수 있고 이로 인해 Thread의 장시간 동기화 및 응답 시간의 지연을 초래하게 된다.

반면 Response Time 기준의 Garbage Collector는 다소 소극적인 GC를 수행한다. GC를 수행하는 과정에서 Thread가 동기화되고 이로 인해 사용자가 대기하는 시간을 최소화하기 위해서 GC 작업 자체에 대한 자원 소모를 줄이면서 오랜 시간에 걸쳐 나누어서 하게 된다. 하지만 그 만큼 비효율적이고 장기적으로는 사용자의 작업을 저해하는 결과를 낳을 수 있다.

각 GC가 제공하는 기능을 정확하게 이해해야만 Application의 요구 사항에 따라 적절한 GC를 선택할 수 있다.

-----------------------------------------------------------------------------------------

다음 글에 계속...




신고
Trackback 0 : Comments 3
  1. 멀더엄마 2007.08.30 17:21 신고 Modify/Delete Reply

    GC 알고리즘도 중요하지만, WAS 인스턴스에 할당하는 메모리 사이즈도 중요한듯.
    메모리 사이즈를 크게주면, Full GC하는 간격이 늘어나지만 그만큼 Full GC 시간이 많이 걸리니 그시간동안 Thread 가 대기하게되는 문제가 있고,
    메모리 사이즈를 작게하면, Full GC 발생 주기가 짧아지는대신 GC 하는 시간이 줄어들어 그만큼 짧은시간동안만 Thread가 대기하게됨.

    WAS 인스턴스 갯수나 request 수 등을 고려해서 적당하게 메모리를 잡으면 될듯. 보통 1~2기가로 잡아주는것같음(???)
    다 ... 아는 얘긴가?

  2. 욱짜 2007.08.30 17:44 신고 Modify/Delete Reply

    Heap Size와 함께 Heap를 구성하는 Young(Eden+Survivor), Tenured Space의 크기도 중요... Part6을 참조

  3. 카이스턴 2007.09.13 11:35 신고 Modify/Delete Reply

    공부중이라 좋은 자료 발견해서 비밀글로 퍼갑니다~

Write a comment

티스토리 툴바