'Java/Java Advanced'에 해당되는 글 20건

  1. 2012.10.26 Java NIO의 DirectByteBuffer는 필요한 갯수만큼만 만들어서 사용하자.
  2. 2012.04.06 High Performance Libraries of Java
  3. 2011.09.01 [Java Spec] JVM Spec과 Java Language Spec 문서 업데이트
  4. 2011.07.21 [자바 메모리 모니터링] JVM에서 사용하는 전체 메모리를 모니터링하는 방법
  5. 2011.05.03 [LogCompilation] 자바의 JIT가 어떻게 컴파일이 되는지 보고 싶다면...
  6. 2011.03.28 [Advanced Java] Attach API
  7. 2011.03.21 [링크] Java Attach API
  8. 2010.12.21 [자바 객체의 크기] Shallow size와 Retained size
  9. 2010.11.15 Java Concurrency in Practice 저자의 블로그
  10. 2010.06.30 [Java Concurrent] 일반적으로 모르는 자바에 대한 사실들
  11. 2009.12.22 [Java PDF] 자바로 PDF 파일을 만들어 주는 iText 라이브러리
  12. 2009.06.16 [JavaOne 2009] 자바원 2009 세미나 자료들
  13. 2009.04.10 [Java Performance Tips] 자바 성능 팁
  14. 2009.03.09 [자바 스택정보 보기] jstack을 이용해서 스택정보(쓰레드 덤프, Thread dump) 확인
  15. 2009.02.19 [NetBeans 성능 튜닝 관련 링크 모음] 넷빈즈 사이트에서 제공하는 성능 관련 링크들
  16. 2009.01.28 [성능 튜닝 가이드] 기본적인 자바 성능 튜닝 가이드
  17. 2009.01.11 [J2EE Cache] ehcache를 사용한 페이지 캐시
  18. 2008.07.18 [쓰레드 덤프 분석] 자바 쓰레드 덤프 분석을 통한 병목 구간 찾기
  19. 2008.07.05 [Link] AIX (IBM JVM사용시)에서의 자바 문제 해결 방법
  20. 2008.06.13 [Memory leak] Oracle의 OCI를 사용할 때 C Heap 과 관련된 OutOfMemoryError가 발생할 때

어제 성능 테스트를 하다가 성능이 안나오는 프로그램이 있어 확인을 하던 중, 
어떤 프로그램에서 System.gc()라는 불러서는 안되는 코드를 부른 다는 것을 직감(?)했다. 

개발된 코드를 뒤져도 그 코드는 안나오고, 
어디를 뒤져오 안나오길래 아주 단순한(?) 방법으로 원인이 되는 놈을 찾아 내었다. 
(여기서 단순한 방법은 http://www.tuning-java.com/421 를 참고하시길...)

우선 관련해서 DirectByteBuffer를 막 생성하면 안된다고 이야기해 주신 정보를 제공해주신 훌륭한 "응주박" 선수에게 감사하다는 말을 전한다. 

이러한 문제가 발생하는 원인을 확인해 보기 위해서 아침에 출근하자마자 샘플 코드를 작성해봤다. 먼저 다음의 코드를 보자.

import java.nio.ByteBuffer;


public class DirectByteBufferCheck {


  public static void main(String[] args) {

    DirectByteBufferCheck check=new DirectByteBufferCheck();

    for(int loop=1;loop<99999999;loop++) {

      check.getDirectByteBuffer();

      if(loop%100==0) System.out.println(loop);

    }

  }

  public ByteBuffer getDirectByteBuffer() {

    ByteBuffer buffer;

    buffer = ByteBuffer.allocateDirect(65536);

    return buffer;

  }

}

뭐 별거 없다.
루프 돌면서 ByteBuffer의 allocateDirect() 메소드를 호출해서 DirectByteBuffer를 생성한다.
이 프로그램 돌리고 GC 상태를 보면 다음과 같이 나온다.

$ jstat -gcutil 1484 1s

  S0      S1      E        O       P        YGC     YGCT    FGC    FGCT     GCT   

  0.00   0.00   2.00   0.90  22.04      0    0.000    77    0.736    0.736
  0.00   0.00   0.00   0.90  22.07      0    0.000    84    0.795    0.795
  0.00   0.00   0.00   0.90  22.07      0    0.000    91    0.855    0.855
  0.00   0.00   0.00   0.90  22.08      0    0.000    97    0.911    0.911
  0.00   0.00   0.00   0.90  22.08      0    0.000   104    0.975    0.975
  0.00   0.00   0.00   0.90  22.08      0    0.000   111    1.041    1.041
  0.00   0.00   0.00   0.90  22.08      0    0.000   117    1.093    1.093

빨간색으로 표시한 Full GC 횟수가 1초에도 무지막지하게 증가하는 것을 볼 수 있다. 


왜 이런 현상이 발생할까?


그 원인은 ByteBuffer.allocateDirect(65536) 메소드 호출 부분에 있다. 
이 메소드를 부르면
1. DirectByteBuffer라는 클래스의 생성자가 호출되고 
2. 그 생성자에서는 Bits.reserveMemory(65536) 이라는 static 메소드를 호출한다.
Bits 클래스의 소스는 "요기링크"를 참조하기 바란다. 


링크를 보면 왜 DirectByteBuffer클래스의 객체를 계속 생성하면 System.gc()가 계속 발생할 수가 있는지를 확인해 볼 수 있다. 

신고
Posted by tuning-java Trackback 0 : Comment 0

Java Performance 라는 사이트에서 제공하는 뉴스레터를 보다가 발견한 내용이다.

http://vanillajava.blogspot.co.uk/2012/02/high-performance-libraries-in-java.html


가장 마음에 드는 것은 구글의 구아바. (구글이 만들어서 웬지 더 믿음이 가~~~)

http://code.google.com/p/guava-libraries/


High scale lib 

http://sourceforge.net/projects/high-scale-lib/


Trove

http://trove.starlight-systems.com/


Fastutil

http://fastutil.dsi.unimi.it/


나중에 첫 책 2nd Edition 쓸때 참고해야겠다. ㅎㅎ


신고
Posted by tuning-java Trackback 0 : Comment 0
몇년간 업데이트가 되지 않았던 
JVM Spec 문서(1999년이 최종이었음)와
JLS (2005년이 최종이었음)
문서가 이번에 JDK 7이 나오면서 새로운 버전의 문서가 제공되고 있다.

기존의 버전 번호를 그대로 가지 않고,
Java SE 7 Edition
이라는 이름으로 문서 이름이 바뀐 점이 특이하다.

다운로드 링크는 요기다. 
http://download.oracle.com/javase/cmn/spec_index.html 

영어인건 다 아시죠?  
신고
Posted by tuning-java Trackback 0 : Comment 0
회사 동료분이 공유해 주신 자료가 있어 그 링크를 적어놓는다.

http://www.ibm.com/developerworks/linux/library/j-nativememory-linux/ 

리눅스에서 특정 프로세스의 메모리 사용량을 모니터링하는 방법이다.

이걸 진작에 알았더라면, 트러블 슈팅 책에 썼을텐데.
- -;

 
신고
Posted by tuning-java Trackback 0 : Comment 0
http://wikis.sun.com/display/HotSpotInternals/LogCompilation+overview 를 보면 상세한 내용을 볼 수 있을 것이다.

일단 LogCompilation이라는 것이 뭔지 알아야 하는데...
자바 실행시 옵션에 

-XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation 


라고 하면 XML 형태의 로그파일을 생성한다. hotspot.log라는 이름으로...
이클립스에서 실행하거나 어디에 이 파일이 생성되는지 모르면 다음과 같이 지정하면 된다.

-XX:LogFile=/develop/ztemp/logcompile.xml


당근 /develop/ztemp 라는 디렉터리가 있어야 잘 되겠죠?

이렇게 세가지 옵션을 지정하고 자바 애플리케이션을 실행하면 XML 타입의 로그가 쌓인다.

이 XML 분석방법은 일단 나중에 ...
http://wikis.sun.com/display/HotSpotInternals/LogCompilation+tool
에 보면 logc.jar가 만들어 진다는데, 뭘 해야 만들어지는지 아직 모르겠음. - -;
 
소스 코드에서 그냥 make 실행하면 logc.jar파일이 만들어지긴 하는데 parsing이 잘 안된다.

이거 괜히 알았다가 산넘어 산이다. 
신고
Posted by tuning-java Trackback 0 : Comment 0
자바에는 Attach API라는 것이 있다.

이게 뭐냐면,
현재 떠 있는 JVM에 붙어서 뭔가 작업을 하는 것을 도와주는 API다. 
패키지가
com.sun.tools.attach 로 시작하기 때문에,
일반 자바 API 문서에는 링크가 없다.
대신 javadoc/jdk/api/attach/spec/index.html 을 보면 된다.

자세한 설명은 아래 링크를 참조하면 좀 이해가 될 듯...
http://www.javaworld.com/community/node/470 

 
신고
Posted by tuning-java Trackback 0 : Comment 0
원문 출처 : http://www.yourkit.com/docs/95/help/sizes.jsp

번역 : 내가 했음. ㅎㅎ

Shallow size of an object is the amount of memory allocated to store the object itself, not taking into account the referenced objects. Shallow size of a regular (non-array) object depends on the number and types of its fields. Shallow size of an array depends on the array length and the type of its elements (objects, primitive types). Shallow size of a set of objects represents the sum of shallow sizes of all objects in the set.

객체의 Shallow 크기라는 것은 객체 자체가 저장되는 메모리의 양을 말하며, 참조되는 객체가 포함되지 않은다. 배열이 아닌 Shallow 크기는 해당 객체가 갖고 있는 필드의 갯수와 타입에 따라 달라진다. 배열의 Shallow 크기는 배열의 길이와 요소(객체, 기본자료형)의 타입에 의존적이다. 객체의 집합(set)에 대한 Shallow 크기는 해당 집합(set)에 있는 모든 객체의 Shallow 크기의 합을 말한다. 

Retained size of an object is its shallow size plus the shallow sizes of the objects that are accessible, directly or indirectly, only from this object. In other words, the retained size represents the amount of memory that will be freed by the garbage collector when this object is collected.

Retained 크기는 Shallow 크기 + 해당 객체에서만 직/간접적으로 접근 가능한 객체들의 shallow 크기를 말한다. 다시 말해서, retained 크기는 가비지 컬렉터에 의해서 해당 객체가 제거될 때 사라지는 메모리의 크기를 나타낸다. 

To better understand the notion of the retained size, let us look at the following examples:

retained size에 대한 보다 더 자세한 이해를 위해서 다음의 예제를 살펴보자.

In order to measure the retained sizes, all objects in memory are treated as nodes of a graph where its edges represent references from objects to objects. There are also special nodes - GC root objects, which will not be collected by Garbage Collector at the time of measuring (read more about GC roots).

retained size를 측정하기 위해서는, 메모리에 있는 모든 객체들은 그래프의 노드로 간주되며, 그것들의 edge는 객체들에서 객체들로의 참조를 나타낸다. 여기에 특별한 노드가 있는데, 이는 GC root 객체이며 이것은 측정 당시에 가비지 컬렉터에 의해서 처리되지 않는다. 

The pictures below show the same set of objects, but with varying internal references.

아래 그림을 보면 돌일한 set을 가지는 객체들이며, 내부적인 참조는 다른 상황이다.

Figure 1:
Figure 2:

Let us consider obj1.
As you can see, in both pictures we have highlighted all of the objects that are directly or indirectly accessed only by obj1. If you look at Figure 1, you will see that obj3 is not highlighted, because it is also referenced by a GC root object. On Figure 2, however, it is already included into the retained set, unlike obj5, which is still referenced byGC root.

obj1을 생각해보자.
여러분들이 볼 수 있듯이, 두 그림에서 색칠되어 있는 객체들은 obj1에서만 직/간접적으로 접근가능하다. 그림 1에서는 obj3이 색칠되어 있지 않은 것을 볼수 있다. 왜냐하면 해당 객체는 GC root 객체에서 참조하고 있기 때문이다. 그림 2에서는 obj3이 retained set에 포함되어 있다. obj5는 아직도 GC Root에서 참조하고 있는 것을 볼 수 있다.

Thus, the retained size of obj1 will represent the following respective values:

  • For Figure 1: the sum of shallow sizes of obj1obj2 and obj4
  • For Figure 2: the sum of shallow sizes of obj1obj2obj3 and obj4

따라서  obj1의 retained size는 다음의 값들을 나타낸다.
  • 그림 1 : obj1,2,4의 shallow size의 합
  • 그림 2 : obj1,2,3,4의 shallow size의 합


Looking at obj2, however, we see that its retained size in the above cases will be:

  • For Figure 1: the sum of shallow sizes of obj2 and obj4
  • For Figure 2: the sum of shallow sizes of obj2obj3 and obj4

obj2를 보자. 이 객체의 retained 크기는 
  • 그림 1 : obj2, 4의 shallow size의 합
  • 그림 2 : obj2,3,4의 shallow size의 합

In general, retained size is an integral measure, which helps to understand the structure (clusterization) of memory and the dependences between object subgraphs, as well as find potential roots of those subgraphs.

일반적으로 retained size는 integral 한 측정이며, 메모리의 구조와 객체 하위 그래프의 의존관계를 이해하는데 도움이 된다. 그리고 이러한 하위 그래프의 잠재적인 root를 찾을 수 있다.  


신고
Posted by tuning-java Trackback 0 : Comment 0
http://www.briangoetz.com/pubs.html

2006년에 발간된 Java Concurrency in Practice라는 책의 블로그이다.

자바에 대한 매우 많은 유용한 문서들을 많이 작성했다.

한번 들어가서 내용들을 보시길...

애기 돌잔치한다고 11월을 바삐 지냈더니 벌써 중순.
예전에 짱박아 놨던 글 하나 포스팅... ㅋㅋ
신고
Posted by tuning-java Trackback 0 : Comment 0
IBM 디벨롭터 웍에 좋은 글이 있어서 링크를...
글이 두개인데, 파트1은 한글, 파트2는 영어다.
제목은 "java.util.concurrent에 대해 모르고 있던 5가지 사항"

링크를 보다보니 다른 글도 있을 것 같아서 뒤져보니 다음과 같은 글들이 있다. ^^;

Java Collections API에 대해 모르고 있던 5가지 사항, Part 1
Java Collections API에 대해 모르고 있던 5가지 사항, Part 2

그 밖에 아직 번역안된 영어글들
5 things you didn't know about ... JARs

5 things you didn't know about ... Java performance monitoring, Part 1
(요 내용은 didn't know는 아닌듯 ㅋㅋ. 특히나 내책을 본 사람들에게는 ㅎㅎㅎ)
아직 8번째 글은 안썼나부다.
신고
Posted by tuning-java Trackback 0 : Comment 0
업무상 필요해서,
자바를 이용해서 PDF 파일을 만드는 라이브러리를 찾아 보았다.

그 중 가장 많이 쓰이고, 적당한 라이브러리로 iText를 찾았고,
해당 라이브러리는 주기적으로 update 되는 것으로 보인다.

iText 홈 : http://www.lowagie.com/iText

한글로 설명 되어 있는 문서 : http://www.ibm.com/developerworks/kr/library/os-javapdf/index.html

iText in action 책의 sample sources : http://www.1t3xt.info/examples/itext-in-action.php


가장 좋은 방법은 한글 문서를 본 후 iText in action 책에 있는 샘플 소스를 참조하는 방법이다.

한글이 깨지는 문제가 있다고 하는데,
그 내용은 구글에서 "iText 한글"로 찾으면 많은 블로그 링크를 찾을 수 있을 것이다.
신고
Posted by tuning-java Trackback 0 : Comment 0
http://developers.sun.com/learning/javaoneonline/j1online.jsp?track=javase&yr=2009

Java One 2009 자료들이 떴다.
이 자료들을 보려면 SDN 계정이 있어야만 한다.
(대부분 아시겠지만, 이 계정은 무료다. ^^)

지난 몇년간 성능테스트만 하고,
튜닝 업무는 주가 아닌 부 작업이 되었을 때 자료들을 보는 것과
지금 튜닝 업무가 주요 작업인 지금 자료들을 보는 것은 천지차이다.

역시 어떤 자료던지,
자기한테 필요가 있어야만 처다보게 되고,
머리에 쏙쏙 들어온다는 거~~~.

그나 저나 팀장님이 도움이 될꺼 같냐고 물어봤을때,
강력하게 이야기할 걸 그랬다.

내년엔 경기도 좋아지고,
팀도 계속 남아있고,
Java One 2010도 꼭 해서,
한번 참석해보고 싶당...
(회삿돈으로... ㅋㅋㅋ)
신고
Posted by tuning-java Trackback 0 : Comment 0
오늘 팀장님께서 복사한 문서를 한번 읽어 보라고 주셨다.
9개의 자바 성능 팁에 대해서 아~주 간단하게 정리되어 있는 문서다. (2페이지에 걸친...)

그 장의 첫번째 구문에는 Michael A. Jackson 이라는 할아버지가 쓴 글귀가 있다.

The First Rule of Optimization : Don't do it
The Second Rule of Optimization (for experts only) : Don't do it yet.

이 문서가 언제 쓴 문서인지는 모르겠지만.... 이 글귀는 약간 이해는 안된다. ^^;

Tip #1 : Object creation is bad
Tip #2 : static is good  ==> I don't think so 다.
Tip #3 : Table switch good, lookup switch bad
Tip #4 : Small methods are good methods
Tip #5 : Exceptions are exceptional
Tip #6 : Use decorator patterns with care
Tip #7 : instanceof is faster on classes
Tip #8 : Use synchronized minimally
Tip #9 : Beware external libraries
신고
Posted by tuning-java Trackback 0 : Comment 0

기본적으로 자바는 Process와 Thread로 구성되어 있다.

이게 뭔지는 Java 성능을 결정짓는 코딩 습관과 튜닝 이야기라는 책에 잘 나와 있고...


여하튼.. 어떤 Thread가 뭔 짓을 하고 있는지를 보려면 Thread dump를 보면 된다.

자바는 기본적으로 Thread dump를 제공하기 위해서 jstack이라는 명령어(프로그램)을 제공하며 자세한 설명이 필요한 분은 아래의 설명을 보기 바란다.

http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jstack.html

http://java.sun.com/javase/6/docs/technotes/tools/share/jstack.html

 

만약 JDK 버전이 5.0이면

Jstack pid

JDK 버전이 6.0 이면

jstack -l pid

명령을 수행하면 된다.


만약 솔라리스나 리눅스에서 이 명령으로 수행이 안되면

jstack -F pid

로 수행하면된다.


여기서 pid 는 프로세스의 id다.

만약 jstack이 수행하는데 너무 오래 걸리고, 서버에 부하가 된다면 kill -3으로 쓰레드 덤프를 뜨는 것도 도움이 된다.


분석하는 방법은 쉽지 않지만 다음과 같은 툴들이 있다.
TDA라는 툴
https://tda.dev.java.net/

IBM의 JCA라는 툴

http://www.alphaworks.ibm.com/tech/jca



신고
Posted by tuning-java Trackback 0 : Comment 0
http://dlc.sun.com/pdf/819-3681/819-3681.pdf

문서의 제목은 Sun Java SystemApplication Server 9.1 PerformanceTuning Guide라고 되어 있다.

하지만, 실제 내용은 특정 Application 서버에 한정된 내용이 아닌 범용적이고, 기본적인 이야기가 많이 정리되어 있다.

세부적인 내용은 아니더라도, 제목만이라도 읽어 놓으면 많은 도움이 될 듯 하다.

바로 다운로드 받기 귀찮은 분들은 아래의 내용을 펼쳐서 제목만이라도 읽어보기 바란다.

목차보기

신고
Posted by tuning-java Trackback 0 : Comment 0
kenu님 미투데이에 놀러갔다가 ehcache 를 발견했다.

간단히 사용법을 정리한 블로그는 영어지만,
http://blog.cherouvim.com/caching-pages-using-ehcache


ehcache는 홈페이지에서 다운로드 가능하다.
http://ehcache.sourceforge.net 

왜 페이지 캐시가 필요한지는 대부분 아시겠지만,
예를 들어서 간단하게 말씀드리면...
온라인 쇼핑몰에서 대분류, 중분류, 소분류로 상품의 목록이 나오고
해당 상품의 개수가 나와있다고 가정해보자.
만약 이런 페이지의 캐시를 지정하지 않았다면, 페이지를 호출할 때마다 해당 카테고리의 상품 개수를 가져오는 쿼리가 계속 수행될 것이다.

그런데 캐시를 사용한다면???
거의 HTML을 읽어오는 속도로 메모리에서 데이터를 읽어 올 수 있으므로,
해당 화면이 엄청나게 자주 불리는 초기화면이거나 include되는 화면이라면 WAS 와 DB 사용량이 현저하게 줄어들 수 있다.
추가로 I/O 도 줄어들 수 있을 것이다.
신고
Posted by tuning-java Trackback 0 : Comment 0
http://www.j2eestudy.co.kr/lecture/lecture_read.jsp?table=j2ee&db=lecture0201_1&id=24

금일 세미나 수강생중 한분이 쓰레드 덤프를 어떻게 분석하는지에 대한 질문을 하셔서,

관련 자료를 찾다가 가장 적절한 내용이기에 링크를 정리해 둔다.

조대협님이 정리하신 내용인데,
정말 상세하고 잘 되어 있다.

근데...

개발자 분들은 직접 분석하려고 하는 것 보다는,
WAS 엔지니어나 서버 엔지니어 분들께 분석을 요청 드리는 것이
가장 빠르고, 현명하고, 간편하고, 머리 안아픈 방법이라는 것을 명심해 주기 바란다.
신고
Posted by tuning-java Trackback 0 : Comment 0
http://www.ibm.com/developerworks/kr/library/au-javaonaix_memory.html

AIX 서버 (IBM JVM을 사용하는 서버)에서 자바 관련 문제가 발생되었을때 해결방안이 정리되어 있다.

그중 가장 마음에 드는 구절은 다음 부분이다. ^^;

메모리 문제는 매우 복잡하고, 해결하기도 매우 어려우며, 진단에도 많은 시간이 요구됩니다. 메모리 관련 문제들은 다음과 같은 이유로 인해 해결하기 매우 어려운 작업입니다.

  • 부적절하게 튜닝 된 OS나 JVM
  • 부적절하게 객체를 관리하는 자바 애플리케이션
  • 부적절하게 할당된 큰 객체 또는 중첩 객체들
  • 단편화(Fragmentation)
  • JNI/네이티브 코드에서 올바르게 릴리스 되지 못한 메모리
  • JVM 메모리 할당과 사용에 대한 이해의 부족

ㅋㅋㅋ

신고
Posted by tuning-java Trackback 0 : Comment 0

http://www.jennifersoft.com/46/forum/page/3/show/1130.html

메모리 릭을 발생시키는 원인은 무척 많지만,
Oracle의 OCI를 사용할때 C Heap이 계속 누적되어 OutOfMemoryError가 발생할 수 있다고 한다.

데이터 건수가 적을때는 조금씩 쌓여도 간에 기별도 안가겠지만,
화면에서 제대로 처리하지 못하고 3만, 10만건을 조회하다가 오류가 발생하면 이러한 문제가 발생할 수도 있다.


 

신고
Posted by tuning-java Trackback 0 : Comment 0