Java Memory 이야기

java core 2009. 3. 25. 20:45
자바 인스턴스의 메모리를 측정하는 방법은 여러가지 인데, 그중에 Runtime과 JMX를 알아본다.

Posted by '김용환'
,

svn과 연동 (svnkit)

java core 2009. 3. 25. 04:04

'java core' 카테고리의 다른 글

JMX를 통해서 cpu 정보 구하기  (0) 2009.03.25
Java Memory 이야기  (0) 2009.03.25
exception시 어떻게 되는가?  (0) 2009.03.05
PermGen에서의 OutOfMemoryError 발생 대처하기  (0) 2009.02.25
Generic Erasure  (0) 2009.02.24
Posted by '김용환'
,

Exception이 생기면 어떻게 되는지 궁금해 하는 분이 계시던데.. 기본적인 것이고, thinking in java를 꼭 정독하면 좋겠다.

 

아래의 코드를 보자

 

 



import org.junit.Test;


import com.opensymphony.xwork.interceptor.annotations.After;
import com.opensymphony.xwork.interceptor.annotations.Before;


public class TestCase {

 int a = 0;
 @Before
 public void setup() throws Exception {

 }
 
 @After
 public void teardown() throws Exception {
  
 }
 
 public void a() {
  a = 0;
  try {
   a = 1;
   throw new Exception ("1");
  } catch (Exception e) {
   a = 2;
  }
  a = 3;
 }
 
 @Test
 public void execute() throws Exception {
  a();
  System.out.println(a);
 }
 
}

 

 

 

3이 출력된다.

java 언어는 예외처리 개념을 두었는데(여기에 대한 엄청난 의견들이 있음..) catch로 묶는 순간 이미 이것은 처리를 하겠다는 개념으로 생각하면 됨.

'java core' 카테고리의 다른 글

Java Memory 이야기  (0) 2009.03.25
svn과 연동 (svnkit)  (0) 2009.03.25
PermGen에서의 OutOfMemoryError 발생 대처하기  (0) 2009.02.25
Generic Erasure  (0) 2009.02.24
Java Profiling API 공부 시작..  (0) 2009.02.20
Posted by '김용환'
,

자바에서 클래스 메타 정보영역인 PermGen영역에서 OutOfMemoryError 가 나면..

보통 permgen 영역을 넓히면 된다.

 

해결 방법을 소개한다.

1. MaxPermSize을 늘린다.

-XX:MaxPermSize=256m 옵션을 실행할떄 추가한다. 보통 이정도면 꽤 많이 쓰는 것이다. 톰캣이라면, catalina.sh에 추가하면 된다.

 

 

만약 ConcurrentMarkSweep (CmS)  GC를 할 때면, 아래 옵션을 추가해야 한다.. CMS GC때는 반드시 permgen 영역을 gc하지 않는다. 따라서 추가하는 것이 많다. 아무 때나 추가하는 것이 절대 아니다.

 

2. CMSPermGenSweepingEnabled , CMSClassUnloadingEnabled 를 추가한다.

-XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled 옵션을 추가한다.

중요한 것은 ParreleGC

 

'java core' 카테고리의 다른 글

svn과 연동 (svnkit)  (0) 2009.03.25
exception시 어떻게 되는가?  (0) 2009.03.05
Generic Erasure  (0) 2009.02.24
Java Profiling API 공부 시작..  (0) 2009.02.20
아파치 세션이 계속 있다??  (0) 2009.02.20
Posted by '김용환'
,

Generic Erasure

java core 2009. 2. 24. 03:19

jdk5 부터 지원되는 generic을 컴파일하고 ,jad로 역컴파일하면, generic 코드부분은 완젼 사라져 있다.

이것을 erasure 라고 한다.

자바가 erasure라는 것을 사용하는 것은 바로 java runtime 환경에 backwards compatibility  때문이다. generic이 생기전에 먼저 jvm이 생겼음을 생각해 보자.

 

이런 generic을 왜 지원하게 될까? 그것은 runtime때 일어나는 부주의한 실수조차 없게 하기 위함이다. 하지만, 이렇게 자주 사용하게 되면, 반발이 많이 일어날 수 있다. 불필요한 수준의 타입 명시로 인해서 개발비용은 늘어날 수도 있다.

 

아마도 이 만든 사람은 Static Typed language를 지원함으로서, classcasetexception이 일어나지 않도록 도와주려고 한거 같은데. 그 마음 누가 알랴?

 

 

 

참조

http://www.mindview.net/WebLog/log-0060

http://lastmind.net/blog/2007/01/effective-java-reloaded.html

 

 

'java core' 카테고리의 다른 글

exception시 어떻게 되는가?  (0) 2009.03.05
PermGen에서의 OutOfMemoryError 발생 대처하기  (0) 2009.02.25
Java Profiling API 공부 시작..  (0) 2009.02.20
아파치 세션이 계속 있다??  (0) 2009.02.20
jstack  (0) 2009.02.20
Posted by '김용환'
,

자바 프로파일링 api를 이용해서 자바에서 정보를 꺼집어오는 일을 할 것 같다..

흐흐~~ 공부 시작~

 

출처 : http://zeous.egloos.com/tag/java/page/1

 

3. ASM

3.1 정보를 수집&분석하는 Tool 이다.
3.2 BCI의 API 를 이용해서 가장 low 레벨로 컨트롤하는 방법임
3.3 HPRof가 모든 class에 대한 분석임에 반해 이 방법은 특정 클래스에 대한 action을 원하는 형태로 지정(코딩)할수 있다.
3.4 장단점
    - 특정 class에 대한 컨트롤이 가능하다(예, connection 연결이 몇번 호출되었는지 카운트가능)
    - 자유도가 높은 만큼 처음부터 코딩해야 한다.
3.5 참고자료
    - http://somnusong.tistory.com/275
    - http://asm.objectweb.org/index.html

 

 

출처

http://openframework.or.kr/Wiki.jsp?page=JvmtiNjvmpi

 

 

Java Profiling API

 

 

http://j2eearchitect.net/viewtopic.php?t=1322

Java Profiling API란 무엇인가?

보통 프로파일러라고 함은 애플리케이션의 문제를 진단하고 성능을 측정하기 위해서 사용하는 도구를 의미합니다.

자바에서는 Profiling API를 통해서 애플리케이션의 다양한 정보를 프로파일링할 수 있습니다.

그렇게 하기 위해서는 어떻게 해서든지 간에 JVM의 정보를 가지고 와야 합니다. 보통 JVM의 정보를 실시간으로 가져오기 위해서 자바에서 제공하는 특별한 API를 이용하여 JVM과 통신을 시도하고 콘솔은 원격 JVM과 통신을 통해서 프로파일링 정보를 가지고 오게 됩니다.

Java Profiling API란 프로파일러와 JVM 간의 통신을 수행하고 프로파일링 정보를 가져올 수 있게 하는 Sun에서 규정한 API입니다.

이러한 API는 JVMPI와 JVMTI가 있습니다. 실제로 비슷해 보이지만 동작하는 구조와 그 특성은 서로 상이합니다.

JVMPI for Java 1.3, 1.4

JVMPI(http://java.sun.com/j2se/1.5.0/docs/guide/jvmpi/index.html)는 원래 클래식 자바 가상 머신에서 잘 동작하도록 설계되어 있기 때문에 현대적인 JVM에서는 잘 어울리지 않습니다. 예를 들면 Java 1.4가 되겠습니다.

최신의 JVM은 바이트 코드를 동적으로 최적화 하는 기능이 들어 있는데 JVMPI는 성능 정보를 수집하기 위해서 이벤트를 이용합니다.

이 이벤트가 많은 문제를 발생시키는데 대표적으로 GC를 제대로 동작하지 못하게 하는 문제점입니다. 또 다른 문제는 JVMPI가 큰 크기의 힙 메모리를 제대로 프로파일링 하지 못한다는 점입니다.

Sun에서 JVMPI를 "실험적"이라고 밝히고 있기 때문에 JVMPI는 사실 완전한 표준이 되기 어렵다고 봅니다. 하지만 실제로 마치 표준처럼 사용하고 있습니다.

JVMPI는 Java 1.3, Java 1.4에서 사용가능한 프로파일링 인터페이스이기 때문에 Java 5에서는 호환성의 이유로 JVMPI를 지원합니다. 하지만 Java 6에서는 더이상 JVMPI를 지원하지 않습니다.

일반적으로 JVMPI를 구동하려면 JVM을 구동할 때 JVM 입력 인자로 -Xrun... 을 이용합니다. 예를 들면 JProfiler는 다음과 같은 인자를 이용합니다.

코드:

#java -Xrunjprofiler FooClass

-Xrun 인자는 JVMPI를 구동하라는 의미로써 "-Xrun"을 제외한 "jprofiler"에 대해서 JVMPI를 이용하여 JVM과 통신할 네이티브 코드 파일을 의미합니다.

즉, Windows에서는 jprofiler.dll, Linux에서는 jprofiler.so, HPUX에서는 jprofiler.sl을 로딩하려고 시도합니다.

새로운 JVMTI for Java 5 이상

JVMPI의 이벤트 기반 모델 대신, JVMTI(http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/index.html)는 이른바 "bytecode instrumentation"이라는 방법을 사용합니다.

"bytecode instrumentation"이란 애플리케이션을 프로파일링 하기 위해서 프로파일링할 애플리케이션의 바이트 코드를 변경한다는 의미입니다.

즉, 모니터링 하고자 하는 바이트 코드의 정확한 위치에 프로파일링 코드를 추가함으로써 프로파일링을 수행합니다.

그러므로 이론적으로 이러한 접근은 더욱더 perspective하지만 Java 5에서 JVMTI의 구현은 여러 가지 문제가 있습니다(물론 이 문제는 Java 6에서 해결되었습니다).

-XX:+UseConcMarkSweepGC, -Xincgc 옵션을 이용한 parallel garbage collector을 지원하지 않는데 JVMPI 또한 이러한 제한이 있습니다.

그러므로 메모리 스냅샷을 생성했을 때 정확한 배열의 길이를 가져올 빠른 방법이 없습니다. 또한 여러 가지 성능 문제도 있습니다.

JVMTI는 JVMPI와 다르게 구동하는 JVM 입력 인자가 다릅니다. 예를 들어 YourKit Java Profiler의 경우 JVMTI를 활성화 시키기 위해서 다음과 같이 입력 인자를 사용해야 합니다.

코드:

#java -agentlib:yjpagent FooClass

Java 버전별 프로파일링 API 지원

* JVMPI : Java 1.3, Java 1.4 * JVMTI : Java 1.5 (강력 권장), Java 1.

 

'java core' 카테고리의 다른 글

PermGen에서의 OutOfMemoryError 발생 대처하기  (0) 2009.02.25
Generic Erasure  (0) 2009.02.24
아파치 세션이 계속 있다??  (0) 2009.02.20
jstack  (0) 2009.02.20
톰캣-이클립스 리모트 디버깅 하기  (0) 2009.02.19
Posted by '김용환'
,

아파치-톰캣 환경에서 아파치 세션을 확인해보다.

 

WGWWWWWWWWWWWWWWWWWWWWWww_,...................

 

 Sending Relpay "W"

 

 

 

sending Replay 객체가 엄청 많아졌다. 확인해보니.

하나는 deadlock, 또 하나는 wait 되는 녀석이었다.

 

jstat 으로 쓰레드 덤프해서 찾으면 된다..

 

1분당 한번씩, 3번 찍어서 파일 다운로드헤서 kdiff3로 비교해서 공통된 것이 나오면 가능하다.^^

 

그러면, 틀리지 않는 공통의 것이 나온다..

 

"TP-Processor76" daemon prio=10 tid=0x09724400 nid=0x584e sleeping[0x8451e000..0x84520120]

 

어디선가 wait되어 있거나 deadlock되어 있다면 빙고~~

게다가 jdk6에서는 kill -3 으로 하든 jstat -l로 덤프를 뜨든.. deadlock 상황을 잘 알려준다.

'java core' 카테고리의 다른 글

Generic Erasure  (0) 2009.02.24
Java Profiling API 공부 시작..  (0) 2009.02.20
jstack  (0) 2009.02.20
톰캣-이클립스 리모트 디버깅 하기  (0) 2009.02.19
multipool / 웹 미들웨어 조사  (0) 2009.02.06
Posted by '김용환'
,

jstack

java core 2009. 2. 20. 23:19

쓰레드 덤프 하기

 

이 툴은 아주 효과 만점이다.

kill -3 자바프로세스번호 하면서 고생하던 것을 쉽게 해결해준다.

 

치면 이렇게 나온다.

 

Usage:
    jstack [-l] <pid>
        (to connect to running process)
    jstack -F [-m] [-l] <pid>
        (to connect to a hung process)
    jstack [-m] [-l] <executable> <core>
        (to connect to a core file)
    jstack [-m] [-l] [server_id@]<remote server IP or hostname>
        (to connect to a remote debug server)

Options:
    -F  to force a thread dump. Use when jstack <pid> does not respond (process is hung)
    -m  to print both java and native frames (mixed mode)
    -l  long listing. Prints additional information about locks
    -h or -help to print this help message

 

강제로, native영역과 함께, 특히 deadlock 여부까지!! 오호! 굿

 

테스트 해보자. 물론 리눅스 환경에서. (윈도우도 되겠지만)

/usr/local/jdk6/bin/jps v             // ps -ef | grep java와 같다.

 /usr/local/jdk6/bin/jstack 21720 > td.txt    // java 프로세스 넘버주면, 파일로 덤프가 가능하다.

 

/usr/local/jdk6/bin/jstack -l 21720 > td.txt   // 이렇게 하면,  deadlock까지 체크!

 

 

Posted by '김용환'
,

 

jpda를 이용하여 리모트 디버깅이 가능하다. jpda라는 것을 이용하면 된다. 설명은 아래~

써머으니 좋더라~~

 

 

http://www.eaves.org/blog-archive/000246.html

 

Debugging with Tomcat and Eclipse using jpda

I've not had much need for debugging my servlets, but while I'm currently working on a legacy codebase, it's a great means of stepping through what is really happening.

I'm not a fan of the "run Tomcat in Eclipse", well, just because it feels ooky, and I'd rather run the two VM's separately so I can bounce them independently, and because I write such crap code, I'd rather not crash both of them at the same time.

The information on how to make Tomcat and Eclipse play nicely together is a bit sparse, so I've provided a nice little summary here. This is working with Tomcat 5.0.X, Eclipse 3.2, JDK 1.4.2_*

Step 1. Configure Tomcat
(This is for the Win32 build with the spiffy UI for starting/stopping)
a) Open up the configuration GUI ("Configure Tomcat")
b) Select the Java tab
c) Into the Java Options include (substituting the correct locations)
-Xdebug
-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n
-Dcatalina.home=c:\tomcat
-Djava.endorsed.dirs=c:\tomcat\common\endorsed
-Djava.io.tmpdir=c:\tomcat

NB: These are all on separate lines, with a <CR> at each EOL
d) Select the Startup tab
e) Into the Arguments section include:
jpda
start

NB: These are all on separate lines, with a <CR> at each EOL
f) Start and Stop Tomcat completely

2. Configure Eclipse (well, not much really to configure)
a) While in the Java perspective select Run/Debug...
b) Choose "Remote Java Application" from the tree (right click/New)

c) The defaults are all that is required.
d) Click "Debug" in the bottom corner to start it now, or Close for later

3. Debugging the Application
a) Select the servlet/code that requires examination
b) Create a breakpoint in the code
c) Click on the "Debug" (if not already debugging) (*)
d) Click on the Debug Perspective (optional)
-- this should show the Eclipse connected to Tomcat, and there should be a huge list Threads and the title of the Debug should be something like:
NameOfApplication [Remote Java Application]
Java HotSpot(TM) Server VM[localhost:8000]

e) Now just run the application as normal (via a browser or whatever)
f) Watch in amazement as Eclipse debugs the application at the breakpoint.

(*) If you get an error such as "Failed to connect to remote VM. Connection Refused". This normally means that Tomcat isn't started, _or_ there is already a debugging session started via jpda. Check Tomcat is running, and check the Debug perspective to make sure that it isn't running.

Posted by jon at May 10, 2006 10:16 AM
Posted by '김용환'
,

DB 커넥션을 웹 서버마다 붙이면, DB는 커넥션 유지를 위해서 메모리와 해당 커넥션 관리를 해야 한다. 특히 자바의 특성상 connection pool을 써야 하기에 어쩌다 쓰는 쿼리를 위해서 써야만 했다.

이를 위해서 대충 조사를 해봤다.

 

sqlrelay나 c-jdbc를 테스트해보 쓸 수 있으면 써야 겠다.

 

 

 

상용 솔루션

-       BEA tuxedo : 이건 미들웨어형태로 제공합니다. UI/모니터링/로깅/자바/EJBAPI/로드밸런싱 지원합니다.

-       Tmaxsoft Tmax: 턱시도와 비슷

-       웹로직 – Multipools

-       나머지는 비주류 

Free 솔루션

-       Sqlrelay: http://sqlrelay.sourceforge.net/ - Linux GPL license

n  Database connection pooling을 지원하고, 프록싱과 로드밸런싱을 지원합니다.

n  장점 : 외국에서는 많이 사용되는 경우인 것으로 보임. 바로 사용 가능. 문서화 잘되어 있고, 웬만한 DB와 프로그래밍 언어 API를 지원합니다

n  단점 : UI 제공 없고, 재시작할 떄 오래 걸리고, 커넥션 문제시 해결을 위해서는 재시작해줘야 함 -> 시스템적으로 풀어야 하는 솔루션 ( + 나머지는 개발 필요),  

n  버전 : 0.40  (최신버젼이 나옴, 2009.1.8)

n  설명 잘된 한국어 웹 페이지 : http://kldp.org/node/45012

 

-        C-jdbc (http://c-jdbc.objectweb.org/) Apache LGPL license

n  Database connection pooling을 지원하고, 프록싱과 로드밸런싱을 지원하는 클러스터 DB 미들웨어.

n  장점 : JMX 기반의 모니터링과 어드민 지원,순수 자바로 개발. 문서화와 및 개발 커뮤니티가 제공됩니다. 트랙잰션/failover/로깅/모니터링 제공합니다.

n  단점 : 아직 모름.

n  버전 : 2.10.10 (2008.5.7)

n  설명 잘된 한국어 웹 페이지 : http://blog.empas.com/holyjohn/list.html?p=2

 

Posted by '김용환'
,