'성능'에 해당되는 글 56건

  1. 2013.02.28 자바의 신 Vol.1 인터넷 서점 링크 목록 (4)
  2. 2010.06.30 [자바 무료 프로파일링 툴] Java Free profiling tools
  3. 2010.01.29 [Java Profiler] 오픈소스 자바 프로파일러들 (1)
  4. 2009.12.22 [자바 GC] 도대체 Permanent 영역에는 어떤 놈들이 있는 것일까?
  5. 2009.11.04 [Linux] netstat와 wc 명령어를 사용하여 네트워크 상태 확인하기
  6. 2009.10.30 [사이트] HP Software user club 소개 - BTO 클럽
  7. 2009.10.08 [Tomcat] Tomcat 성능 튜닝 가이드라인 (tomcat performance tuning)
  8. 2009.10.01 [IT 서적이나 책은 어떻게 만들어 지는가? -3] 시작하기 (2)
  9. 2009.08.06 [성능 튜닝] 고급 성능 조정의 개념
  10. 2009.06.27 [jensor] 무료 자바 프로파일링 툴 젠서
  11. 2009.06.16 [JavaOne 2009] 자바원 2009 세미나 자료들
  12. 2009.06.14 [Dtrace] Solaris 서버 사용자를 위한 Dtrace를 이용한 Java 분석
  13. 2009.06.05 [GC] 자바의 CMS(Concurrent Mark & Sweep)을 대체할 G1
  14. 2009.06.03 [Blog2Book] 이제는 태교서적으로 분류되는구나 (3)
  15. 2009.05.29 [자바 성능을 결정짓는 코딩 습관과 튜닝 이야기] Collection 에 관하여 (1)
  16. 2009.05.25 [GC] Java GC Tuning 방법 (자바 메모리 튜닝)
  17. 2009.05.22 [Heap Dump] 자바 힙 덤프(java heap dump) 분석기 - Eclipse Memory Analyzer
  18. 2009.05.07 [iBATIS] iBATIS의 성능 문제
  19. 2009.04.30 [Java Visual VM] JDK에 포함된 무료 프로파일링 툴
  20. 2009.04.28 [성능 참조 사이트] 성능과 관련된 참조할 만한 사이트
  21. 2009.04.10 [Java Performance Tips] 자바 성능 팁
  22. 2009.03.09 [자바 스택정보 보기] jstack을 이용해서 스택정보(쓰레드 덤프, Thread dump) 확인
  23. 2009.03.02 [자바 모니터링] 자바 모니터링 툴 직접 만들기
  24. 2009.02.25 [Garbage First] G1 콜렉터란 ??? (1)
  25. 2009.02.19 [NetBeans 성능 튜닝 관련 링크 모음] 넷빈즈 사이트에서 제공하는 성능 관련 링크들
  26. 2009.02.19 [자바 메모리 옵션 튜닝] Sun 에서 제공하는 자바 메모리 옵션 튜닝
  27. 2009.02.10 [JIRA] 지라 성능 튜닝
  28. 2009.01.28 [성능 튜닝 가이드] 기본적인 자바 성능 튜닝 가이드
  29. 2009.01.19 [JVM Option] 자바 성능 튜닝에 대한 좋은 글- JVM Option 위주의 튜닝 방법
  30. 2009.01.11 [J2EE Cache] ehcache를 사용한 페이지 캐시
지난주에 회사에서 "GC 튜닝의 이해"라는 과정을 개설해서,
강의를 했다. 

강의 자료를 만들고 있는데,
도대체 자바의 Permanent 영역에는 정확히 어떤 놈들이 있는 것일까?
라는 의문이 생겨서 여기저기 찾아 보다가, 가장 정리가 잘 되어 있는 놈을 발견했다.

궁금하신 분들은 아래 글을 읽어보기 바란다.
http://blogs.sun.com/jonthecollector/entry/presenting_the_permanent_generation

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

netstat라는 명령어를 리눅스에서 사용하면,
네트워크의 상태를 볼 수 있다.

네트워크 상태를 진단할 때 매우 유용하게 사용할 수 있는데,
다음과 같이 사용하면 TIME_WAIT 상태인 연결들의 개수를 확인할 수 있다.
만약 연결된 개수를 확인하려면 grep 뒤에 CONNECTED로 바꾸면 된다.

netstat -n | grep TIME_WAIT | wc

여기서 netstat의 -n은 연결된 장비 이름이 IP 주소로 나타난다.
여기에 a 옵션을 추가하여 -an 이나 -na로 지정해 주면,
연결된 IP나 연결을 기다리는 장비의 IP와 함께 목록을 제공해준다.

추가로 wc 는 라인 및 단어의 개수를 제공하는 옵션이다.
wc만 쓸 경우
3 6 9
와 같이 3개의 숫자가 나타나는데,
가장 앞의 숫자는 라인수(여기서는 관련 연결 개수가 될 것이다.)
두번째는 단어 수,
세번째는 바이트 수를 의미한다.

라인수만 보고 싶을 때에는 -l
단어수만 보고 싶을 때에는 -w
바이트수만 보고 싶을 때에는 -c
옵션을 wc 뒤에 붙여주면 된다.



신고
Posted by tuning-java Trackback 0 : Comment 0
http://www.btoclub.co.kr/

오늘 우연히 알게 되었지만,
HP Software user 를 위한 클럽이 있다는 걸 알았다.

뭐 일반 개발자 분들에게는 별 관인이 가진 않겠지만,
로드러너를 사용하는 분들을 모아서 간담회도 가지고,
세미나도 주기적으로 하는 것 같다.

개인적으로는 로드러너가 좋은 툴이긴 하지만,
금전적으로 너무 사용하기 힘들게 되어 있는 툴이기 때문에,
그리 좋아하진 않지만,
만약 쉽게 사용할 수 있는 환경에 있다면,
성능 테스터들에게는 매우 편리한 툴이다.

누군가에게는 불가능한 테스트라 할지라도,
그 불가능함을 해결한 사람도 분명히 있을 수 있기 때문에,
저런 간담회는 가끔 가주면 좋을 듯...

요즘은 LR 쓸 일이 없어서...
신고
Posted by tuning-java Trackback 0 : Comment 0
내가 한, 두번 Tomcat 5.5와 6성능 비교를 해 본 결과
동일한 Application을 수행할 때 Tomcat 6에는 성능 문제가 존재한다.
아직 정확한 성능 저하의 원인을 밝히진 못했지만,
TPS 상으로 적어도 10~20% 정도 저하된다.

어느정도 Tomcat 6의 성능이 안정화 될 때까지는 쓰지 않는 것을 권장한다.

참고로 아래 링크를 활용하면, 어떻게 Tomcat의 성능을 최적화 할 수 있는지 알 수 있다.

http://www.solutionhacker.com/?p=147




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

다시 또 한번 이야기 하지만, 이 이야기는 지극히 개인적인 의견을 정리한 것이다.



출판사마다 작업의 방식이 다를 수 있고,
집필자마다 순서가 다를 수 있다.
절대적인 방법이 아니라는 것을 알아두기 바란다.
그리고, 순서대로 읽어주기 바란다.

 


그럼 세번째... 어떻게 시작해야 할 지에 대해서 알아보자.
집필을 하기 위해서 먼저 해야 하는 것은 "목차"를 만드는 것이다.
다른 것이 우선 아니냐고?

아니다.

먼저 목차를 만들어야 한다.
물론 목차를 만들기 전에는 앞에서도 이야기 했지만, 무엇에 대해서 책을 쓸 지에 "주제"를 선정하고, 자료를 모으는 작업은 선행되어야 한다.
하지만, 이 작업은 책을 쓰지 않는다고 하더라도 누구나 본인이 하는 작업을 정리 할 때 필요한 작업이다.

그래서, 본격적인 집필 시작은 목차를 만드는 작업이라는 것이다.

목차는 뭐 상세 목차까지 적어주면 되겠지만, 그럴 필요는 없이 그냥
대분류 목차로 적어도 15~20개 정도 적어 두면 된다.
(되도록이면 엑셀로)
만약 처음 집필하는 분이시라면, 상세 목차도 적어두면 좋을 것이다.

목차가 이쁘게 잘 선정 되었다면, 그 다음에는 출판사에 Contact 하는 것이다.
-주변에 아는 사람이나 친구, 친구의 친구가 출판사와 아는 사람이거나,
-친구중 저자가 있을 경우에는
그 아는 사람 통해서 Contact하는게 좋다.

만약 지인이 없어도 그냥 출판사에 Contact 해도 뭐라고 할 사람 아무도 없다.

메일로 연락해도 되고, 전화로 해도 되고, 만나도 된다.
아마도 여러분이 제시한 주제, 목차, 구성이 마음에 든다면 직접 만나서 이야기 하자고 할 것이다.

참고로 Blog2Book 자바 성능을 결정짓는... 책의 경우에는
A모 출판사에서 두명의 리뷰어에게 목차 리뷰를 받은 후 빠꾸를 먹었다.
(이런책은 아무도 필요 없다는 어떤 리뷰어의 리뷰와 함께...
논란의 여지가 있을 수 있어 말씀드리지만, 다른 한분은 목차가 괜찮다고 하셨지만,
책의 주제를 다른방향(Advanced Java ? 뭐 그런 방향...)으로 바꾸어 보라는 의견을 주셨다.)

하지만 운 좋게도, 그 빠꾸를 먹은날 한빛미디어에 책을 서너권 집필한 저자와 만났는데,
그분이 직접 출판사와 연결 시켜 주셨다.
그때 그 지인이 이야기한 중요한 이야기는
"책을 쓰려고 할때, 자신이 원하는 방향의 책이 아니면 쓰지 않는 것이 나아요.
이책임(그땐 직급이 책임(과장)이었다.)님은 튜닝 책을 쓰려고 한거지 다른 책을 쓰려고 한게 아니잖아요..."
라는 말이다. 그 말에 용기를 얻고 한빛 담당자분과 만나서, 목차를 약간 수정하고 집필하기로 했다.
안 그랬으면, 아마도 그 책은 세상에 나오지도 못했을 것이다.


이 이야기를 왜 하냐면,
여러분들이 직접 쓰고 싶은 책이 있다면, 출판사 하나에서 빠꾸 먹었다고 포기하지 말라는 것이다.

그런데, 어느 출판사나 이익을 내야하기 때문에, 1000부도 팔릴 것 같지 않은
그런 책을 내지는 않는다.
다시 말하면, 여러분들도 사지 않을 그런 책은, 다른 사람도 안산다는 것이다.

필자는 이번에 테스트 책을 썼지만, 원래는 테스트 책을 쓸 생각도 없었다.
그냥 Rex Black 아저씨 책 중 기본이 되는 몇권중 한권을 번역하려고 했었다.
하지만, 그 결과는 4개 출판사에서 그러한 번역서는 시장성이 없다는 이유로 빠꾸 먹었다. - -;
그 4개 출판사와 Contact하는 중에 심심해서 적어 놓은 것이 이번에 나올 Blog2Book Test책의 목차다.

그것도 그냥 책 쓸려고 한 것도 아니고, 그냥 목차만 만들어 놓고 한번 정리해 보면 좋겠다고 생각하고,
출판사 담당자에게 그냥 함 보라고 보여 줬던 것이 화근(?)이 되었다.
(그 담당자가 윗분에게 보여드리고, 그분이 한번 진행해 보라는 지시가 떨어져서리...)

여하튼,
출판사에서 OK하면,
책을 누가 보고, 누가 사고, 어떤 내용인지에 대한 소개서를 쓰고,
샘플챕터 하나 써서 내라고 한다.(아무리 목차가 좋아도 글이 맘에 안들면 안되니까...)
그리고 나서 마음에 들 경우,
계약금 받고 (보통 신사임당 10장에서 세금 좀 띄고) 계약서를 쓴다.

그런데, 여기서 한가지 유의할 점은,
"뭐 그럴 필요 있나? 다 쓰고 나서 가져가지"
라는 생각을 할 수도 있을 것이다.
그런데, 샘플 챕터를 제출하는 이유는 필자의 어떤 점들을 고쳐야 할지를 확인하는 데에도 의의가 있다.


그렇게 다듬고, 나머지 부분을 작성하는 것과
모두 작성해 놓고 문체나 책의 방식을 수정하는 것은
엄청난 차이가 있을 것이다.
(뭐 "난 상관 없어~~" 라는 분들은 그냥 다 써놓고 출판사를 만나도 된다.)

다음에는 본격적인 집필을 하기 위한 또 다른 준비작업에 대해서 알아보자.

신고
Posted by tuning-java Trackback 0 : Comment 2
http://www.ibm.com/developerworks/kr/library/au-aixperformancetuning/index.html

아침에 메일온걸 확인하다가, 고급 성능 조정의 개념이라는 글이 있어 이렇게 링크를 건다.

그런데, 상세한 가이드라기 보다는 개략적인 가이드라서
어느 정도 경험이 있는 분들이 봐야하는 그런 문서인듯...

추가로 메일을 보니, 에릭 감마 아저씨가 한국에 오는듯... 근데 무슨 QnA가 한시간이여???
안구라 선배가 가면 많은걸 물어볼텐데... ㅋㅋ

Jazz라는 제품 설명하러 오는거 같다.
신고
Posted by tuning-java Trackback 0 : Comment 0
http://jensor.sourceforge.net/

형이 어떻게 알고 알려준건지는 모르겠지만,
알려준 프로파일링 툴인 젠서(이렇게 읽으면 되나?)

관련 문서들을 대충 읽어 봤는데,
하나의 메소드당 30 마이크로 초 정도 잡아먹는단다.
그럼 그게 30번 불리면 1ms 정도 잡아 먹는다는 이야기가 되는데...
30000 번 정도의 메소드 호출이 있으면,
1초의 시간을 잡아 먹을듯...

근데 원격 기능이 없는듯 해서 약간 아쉽다.
신고
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
자바의 GC 방식에는 여러가지가 있지만,
최근에 나온 기술에는 G1이라는 것이 있다.
최근에 나온 JDK 6.0 update 14에는 early access 로 G1을 사용할 수 있도록 했다.
G1을 적용하기 위해서는 java start option에
-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC
라고 명시해 주면 된다.

추가로 G1을 사용할 때 GC로 인한 최대 대기시간을 지정하기 위한
-XX:MaxGCPauseMillis=<X>
옵션을 추가할 수 있으며,
-XX:GCPauseIntervalMillis=<X>
옵션을 통해서 GC 대기 사이의 간격을 지정할 수 있다.
그런데 여기서 중요한 것은
이 옵션은 Goal 이다. Promise나 guarantee 가 아니라는 것이다.
(목표일 뿐이고, 이건 약속이나 보장한다는 것이 아닐 뿐이고~~)

G1이 다른 GC와 다른 것은 GC를 담당하는 New와 Old의 장벽이 사라졌다는 것~~~
자세한건 아래 링크의 비됴나 문서를 함 보시길~~~

Sun Tech Days 2008-2009 자료 보기
http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5419&yr=2008&track=javase


신고
Posted by tuning-java Trackback 0 : Comment 0
먼저 자바 성능을 결정짓는 코딩 습관과 튜닝 이야기를 구매하고, 읽어주신, 그리고, 읽고 계신 독자 여러분께 감사하다는 말씀을 드립니다.

이렇게 글을 올리는 이유는 책을 쓴 저자가 책을 읽는 여러분이 정확한 지식을 습득해야 한다고 생각하기에 책이 나온지 1년 3개월이 지난 지금 이렇게 글을 씁니다.(이렇게 갑자기 책에 대해서 이야기하는 것은 가장 아래에 적어 놓았습니다.)

먼저 제 책에 있는 몇몇 오류에 대해서는 손권남씨께서 자신의 블로그 http://kwon37xi.egloos.com/3733755 에서 잘 설명해 두었습니다. 여기서 제가 보기에도 완전한 문제라고 생각된 부분에 대해서는 2쇄 발행시 많이 수정하였습니다.

그런데, 가장 논란이 많은 부분은 역시 Collection관련 부분입니다.
물론 테스트를 제대로 하지 않았다는 점에 대해선 100% 인정합니다.
(http://agbird.egloos.com/4800620 에 있는 내용을 잘 읽어 보시면 도움이 되실겁니다.)

각각의  Map, Set, List, Queue 등은 자신의 용도에 맞게 사용해야만 합니다. 

그렇다면, 제가 책에 왜 Collection에 대해서 썼을까요?
잘못된 지식을 주기 위해서?
제 책에 안티하신 분들이 말씀하시는 잘못된 테스트 방법을 알리기 위해서 ?
모두 아닙니다.

사실 Collection은 일반 웹 프로그래밍을 할 때 성능의 관점으로 보았을 때 중요하지 않습니다.
하지만 만약 여러분들이 Batch 프로그램이나, WAS 등을 개발한다면 이야기는 완전히 달라집니다. 굉장히 중요합니다.
책을 보신분은 아시겠지만, 테스트 케이스는 적어도 만번 이상 반복 수행을 한 내용입니다.
일반 웹에서는 그렇게 많은 회수의 데이터 검색 및 처리를 해서는 안됩니다.
그렇게 몇만건의 데이터 처리를 하게 된다면 고객을 반드시 설득시키시기 바랍니다. 그건 Web이 아니라, Web의 껍데기를 하고 있는 C/S프로그램입니다.

책을 쓰면서 여러 자료를 수집하면서, 웹 상에서 어떤 Collection이 가장 빠르냐에 대한 논쟁이 일어난 부분을 많이 보았습니다.
그러한 논쟁은 웹 개발시에는 그리 큰 의미가 없다는 것을 알리기 위해서 쓴 부분 입니다.
그렇게 Collection의 성능이 걱정되신다면 구글 Collection을 쓰세요. 

다시 한번 책에 잘못된 지식을 전달한 점에 대해서 죄송하다는 말씀을 드립니다.

그런데, 지금까지 가만히 있다가 왜 갑자기 이런글을 썼을까요?
이번주 화요일에 사내에서 컨퍼런스가 있었습니다.
자바 성능과 관련된 부분이 있어 관심있게 듣게 되었습니다.
그런데, 사전에 컨퍼런스 자료를 검토하던중, 제 책이 잘못되어 있다고 되어 있는 부분을 발견하여
발표자에게 컨퍼런스 전에 메일을 드렸지만, 
메일을 보지 못하고 컨퍼런스를 진행하시더군요. - -;

그 발표자 분과는 컨퍼런스 후에 메일을 통해서 이야기를 하게 되었는데,
예전에 발표자와 다른 어떤 분이 Collection 부분 때문에 엄청 심하게 싸웠고,
그러한 문제 때문에 책에 대한 문제점을 세미나에서 다루었다고 말씀하시더군요.

제가 쓴 책 때문에 다툼까지 발생하리라고는 생각지도 못했습니다.
추후에라도 제가 잘못 쓴 부분 때문에 많은 분들이 다투지 않았으면 하는 생각에 글을 쓰게 되었습니다.

제가 완벽하지도, 똑똑하지도 않은 사람이지만,
성능에 때문에 고생하는 많은 분들을 위해서 쓰게된 책입니다. 조금더 성능에 대한 정확하고 심오한 정보를 얻고 싶으시다면, Effective Java를 반드시 읽어 보세요. 

그래도, 저도 사람인지라 깊이가 낮다. 일부분의 오류 때문에 잘못된 책, 믿지 못할 책이라는 평가를 보면 하루 종일 기분이 좋지 않더군요. 그래서 최근에는 검색을 잘 안해보고 있습니다. ^^:

지금은 "개발자도 쉽게 배우는 테스트와 테스트 툴 이야기(가제)"라는 책을 쓰고 있습니다.
이 책도 저번 책과 마찬가지로, 테스트에 대해서 잘 모르는 초급 개발자와 간단히 참조하기를 위한 중급 개발자분들을 위한 책입니다. TDD에 대한 심오한 이야기나 CI에 대한 깊은 이야기를 다루지는 않았습니다. 
단지, 그러한 단어가 무엇을 뜻하는지, 왜 해야하는지, 테스트라는 말만 들으면 스트레스를 받는 분들을 위해서 최대한 쉽게 쓰려고 노력하고 있습니다.
지금 쓰고 있는 책의 서문에도 써 놓았지만(나중에 출판사에서 그 내용을 뺄 수도 있습니다.), 
자신이 고급 개발자라고 생각하시는 그런 분들은 절대 제가 쓰고 있는 책을 사지 마세요.
그런 분들은 안읽으셔도 됩니다. (보시면 도움이 될만한 부분이 적어도 하나는 있겠지만...)

지금 쓰고 있는 책을 탈고하고, 출판을 한 이후에는
"자바 성능을 결정짓는 튜닝, 그 두번째 이야기"를 쓸 예정입니다.(목차는 거의 완성되었습니다.)
그 책은 성능에 대해서 깊게 쓸 예정이므로, 첫번째 이야기에 실망하신 분들은 기대하셔도 좋습니다.
두번째 책도 실망하시는 분들은 제가 어쩔 수 없죠. - -; 
단, 출판사와 계약 안하고 90% 완료한 상태에서 계약할 예정입니다. ^^;
(빠르면 내년 10월쯤 나올 것 같습니다. )

넋두리가 심했네요.

긴글 읽어 주셔서 감사합니다. 
신고
Posted by tuning-java Trackback 0 : Comment 1
GC가 뭔지 잘 모르시는 분들은 제 블로그의 다른 글을 찾아보시거나,
"자바 성능을 결정 짓는 코딩 습관과 튜닝 이야기"를 참조하시길...

자바의 메모리 구조는 다음과 같이 되어 있다.
  • Code Cache: contains memory used for compilation and storage of native code
  • Eden Space: pool from which memory is initially allocated for most objects
  • Survivor Space: pool containing objects that have survived Eden space garbage collection
  • Tenured Gen: pool containing long-lived objects
  • Perm Gen: contains reflective data of the JVM itself, including class and memory objects
  • Perm Gen [shared-ro]: read-only reflective data
  • Perm Gen [shared-rw]: read-write reflective data

    아래는 GC를 어떻게 튜닝하는지에 대한 자세한 설명이 있는 사이트 링크다.
    http://java-monitor.com/forum/showthread.php?t=30

    이것도 귀찮은 분을 위해서 더 간단한 튜닝 정보
    http://developer.amd.com/documentation/articles/pages/4EasyWaystodoJavaGarbageCollectionTuning.aspx

    완벽한 GC의 방식과 처리에 대한 자세한 정보를 보려면 아래 링크에 있는 PDF 파일을 참조하는 것도 좋다.
    http://www.cecmg.de/doc/tagung_2007/agenda07/24-mai/2b3-peter-johnson/index.html


    한글로 된 설명을 보고자 하신다면
    다시한번 말씀드리지만,
    "자바 성능을 결정 짓는 코딩 습관과 튜닝 이야기"를 참조하시길...
    지금 생각해보면 이 책에 이 부분에 대한 설명을 좀 약하게 적었다는 생각이 많이 들긴 한다.
    다음책에선 자세히 적어놔야지...

    추가로 Java 6 GC 튜닝 방법에 대한 Sun의 자료는 아래와 같다.
    http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html

  • 신고
    Posted by tuning-java Trackback 0 : Comment 0
    자바 힙 덤프 분석기는 jhat등 여러가지 툴이 있지만,
    최근에 발견한 Eclipse Memory Analyzer 라는 프로그램이 있다.

    http://www.eclipse.org/mat/

    다운로드하여 압축을 해제하고, 이클립스만 수행하면 된다.
    단, 기본 자바 VM을 사용할 때 발생한 HPROF 덤프 파일의 확장자는 반드시 hprof 여야만 읽을 수 있다.

    작성된 힙 덤프 파일을 이 프로그램에서 읽으면 다음과 같은 화면을 제공한다.
    사용자 삽입 이미지

    신고
    Posted by tuning-java Trackback 0 : Comment 0
    요즘 iBATIS를 사용하는 프로젝트가 많이 있다.
    예전 회사에서도 이런 경우가 발생한 것으로 생각되는데,
    iBATIS를 사용하면 WAS의 CPU 사용량이 어느 정도 이상 증가하지 않고,
    TPS도 증가하지 않는 현상이 발생하는 경우가 간혹 있었다.

    최근에도 이런 문제를 확인했는데,
    그 이유는 iBATIS의 com.ibatis.common.beans.ClassInfo 클래스에 있었다.
    뭐 내가 잡은건 아니고 내 옆자리에 있는 박박사님께서 ^^;

    만약 쿼리들이 느린 경우에는 이런 문제가 야기 되지 않겠지만,
    쿼리들이 엄청 빠를 경우 WAS에 병목이 생긴다. 아래의 링크를 보자.
    https://issues.apache.org/jira/browse/IBATIS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683961

    이중으로 Lock을 잡은 것이 문제였으며,
    우연찮게도, 미쿡 애들도 비슷한 시기에 문제를 확인한 것 같다.
    http://www.kaigrabfelder.de/en/2009/05/01/concurrency_vs_synchronization.html

    가장 좋은 해법은 ConcurrentHashMap 을 사용하는 것이다.

    해당 버젼이 release (2.3.5)되면 성능을 위해서 update 하는 것이 좋을 듯 하다.


    신고

    'Framework > iBATIS' 카테고리의 다른 글

    [iBATIS] iBATIS의 성능 문제  (0) 2009.05.07
    Posted by tuning-java Trackback 0 : Comment 0
    https://visualvm.dev.java.net/

    VisualVM이라는 무료 툴이 있다.
    사용자 삽입 이미지

    이 툴이 JDK 6.0의 update 7 부터는 JDK의 bin 디렉토리에 jvisualvm.exe 라는 파일로 추가되어 있다.

    한번 사용해 보면 알겠지만, 정말 대단한 툴이다.

    jconsole은 JMX를 데이터를 보기 위한 툴이라면,
    이 툴은 메모리 상태 파악 및 성능 및 메모리 프로파일링까지 가능하기 때문에 성능상 문제가 있는 분들에게
    많은 도움이 될 것이라 생각된다.

    하지만, 아직까지 안정화 되지는 않아서 모니터링 대상 JVM이 죽는 현상이 발생할 수 있으므로,
    조심해서 사용하기 바란다.

    운영서버보다는 테스트 서버에서...

    추가로 이 툴을 사용한 후기를 "영어"로 작성할 능력이 있다면
    500불을 받을 수 있는 기회를 놓치지 말기 바란다.

    나도 함 시간 있으면, 해보려고~~
    자세한 내용은 아래 링크 참조.
    http://java.sun.com/community/javavisualvm/


    신고
    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://java.sun.com/javaone/sf/2008/articles/rockstar_tonyprintezis.jsp

    먼저 위의 인터뷰 내용을 읽어보자.
    Garbage First Collector가 뭔지 대충 감을 잡을 것이다.

    분명 대부분 안읽어 보시겠지만....적어도 아래 줄들은 일어 주기 바란다.
    G1=next-generation low-pause garbage collector
    G1 will ultimately replace the Concurrent Mark-Sweep (CMS) garbage collector
    G1, even though it is generational, there is no physical separation between the two generations.

    Three Objectives of G1
    The first objective is consistent low pauses over time.
    The second objective is to avoid, as much as possible, having a full GC.
    The final objective is good throughput.


    if you care about getting the job done as quickly as possible, and don't care much for how long your application is going to be stopped by the garbage collector, the throughput collector is the best choice.

    if you have a batch job that is going to take a few minutes or a few hours and you want it to be done as quickly as possible, then a throughput collector is clearly the best choice.

    But, if you are working on a very interactive job that needs to interact with people, other applications, or users through web pages, then a low latency garbage collector is the best choice.


    Why does garbage collection take so long? ==> Garbage collection is very memory-bound. And memory speeds these days are quite slow compared to CPU speeds

    글 중간에는 다음의 내용을 읽어보라고 이야기한다.
    GC와 친해지는 코딩 방법
    http://developers.sun.com/learning/javaoneonline/2007/pdf/TS-2906.pdf

    그리고, 저 이너뷰 한 사람이 사진을 잘 찍는가본데, 사진과 개발과의 상관관계를 아래와 같이 이야기 했다.
    You need to be committed and to be patient and try out things again and again, to make sure that you get it just right. I see some parallels between photography and development.

    마지막엔 그가 이야기하는 아름다운 코드란....
    Beautiful code is code that is simple, easy to understand, and efficient
    란다.

    더 자세한 내용을 보시려면 아래의 영어지만, 쉽지 않은 용어로 되어 있는 문서를 참조하기 바란다.
    http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf

    참고로 G1은 JDK 7 부터 추가된단다.
    그리고, early access 로 JDK 1.6.1에서 추가 되었다.
    http://www.tuning-java.com/272

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

    http://java.sun.com/performance/reference/whitepapers/tuning.html

    썬에서 제공하는 자바 튜닝 whitepaper

    물론 JVM 옵션 튜닝만 한다고 해서 답은 안나오겠지만,
    튜닝할게 더이상 없다면, JVM 버젼 upgrade 및 옵션 튜닝을 해야 할 것이다.

    아래는 이 글의 목차다.

    뭐 다 읽기 귀찮으신 분들은 4.2 부터 적용해 보시면 된다.

    1   Introduction

    1.1   Goals
    1.2   This is a Living Document
    1.3   How to Use this White Paper

    2   Best Practices

    2.1   Use the most recent Java™ release
    2.2   Get the latest Java™ update release
    2.3   Insure your operating system patches are up-to-date
    2.4   Eliminate variability

    3   Making Decisions from Data

    3.1   Beware of Microbenchmarks!
    3.2   Use Statistics
    3.3   Use a benchmark harness

    4   Tuning Ideas

    4.1   General Tuning Guidelines

    4.1.1   Be Aware of Ergonomics Settings
    4.1.2   Heap Sizing
    4.1.3   Garbage Collector Policy
    4.1.4   Other Tuning Parameters

    4.2   Tuning Examples

    4.2.1   Tuning Example 1: Tuning for Throughput
    4.2.2   Tuning Example 2: Try the parallel old generation collector
    4.2.3   Tuning Example 3: Try 256 MB pages
    4.2.4   Tuning Example 4: Try -XX:+AggressiveOpts
    4.2.5   Tuning Example 5: Try Biased Locking
    4.2.6   Tuning Example 6: Tuning for low pause times and high throughput
    4.2.7   Tuning Example 7: Try AggressiveOpts for low pause times and high throughput

    5   Monitoring and Profiling

    5.1   Monitoring
    5.2   Profiling

    6   Coding for Performance
    7   Pointers
    8   Feedback and the Java Performance Community

    8.1   Feedback
    8.2   Java Performance Community

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

    http://www.atlassian.com/software/jira/docs/latest/performance.html

    지라 자체적으로 성능 튜닝이 가능한 환경이 마련되어 있다.

    이렇게 링크까지 만들어 정리해 놓은것을 보면 성능 이슈가 많긴 많은가 부다.


     

    신고
    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
    http://2005elc.elancer.co.kr/eTimes/page/eTimes_list.html?cstr=Q0FURUNPREU9QTEwMDAxNTAw

    자바 성능 튜닝은 JVM 옵션만 튜닝한다고 해서 되는 것은 아니다.

    하지만, Application 단에서 튜닝을 모두 마쳤을 경우 가장 마지막에 해야 하는 것이
    JVM의 GC 옵션 및 메모리 부분의 튜닝이다.

    물론 사람에 따라 방식이 틀려서 GC 옵션을 처음부터 할 수도 있다.
    신고
    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