ktds OpenSource Group

OS command 및 tool을 이용한 check방법 IBM의 분석법 1. ps 명령을 이용하여, JEUS Process의 각 시스템thread의사용률을 구한다. % ps -mp [JEUSPID] -0 THREAD 여기서 CP가 가장 높은 부분을 찾는다. 이 시스템 쓰레드가 CPU를 가장 많이 점유하고 있는 시스템 쓰레드이다. (여기서는 66723 이다.) 2. dbx 명령을 이용해서 1.에서 찾은 시스템 쓰레드의 Java Thread ID를 얻어온다. 1) % dbx -a [JEUSPID] 2) dbx에서 “thread” 명령을 치면 Thread ID 를 Listing할 수 있다. k-tid 항목에서 1에서 찾은 Thread ID 를 찾고, 그 k-tid에 해당하는 thread id를 찾는다. (여기..

JEUS상의 문제 분석 방법 Log의 GC 추이 및 루핑 유무 분석 1.SUN 및 HP - -Xloggc:${LOG_HOME}/gc.log 2.IBM - -verbose:gc -Xverbosegclog:${LOG_HOME}/gc.log 위와같이 설정하여 Full GC가 일어나는 회수를 관찰합니다.(기타 gc로그분석기를 활용) 3.루핑 로그 판별 아래와 같이 log에 루핑에 대한 흔적이 있는지 관찰한다. [DEBUG] [14:58:38] ========ServiceTest WORK START============ [DEBUG] [14:58:38] ========ServiceTest WORK END============ [DEBUG] [14:58:38] ========ServiceTest WORK END==..

CPU에 영향을 주는 로직 1)과도한 String연산(루프 포함) String 연산과 루프(for, while)는 CPU를 과도하게 사용하는 경향이 있어서 예전 DAO 코딩 시 String Buffer를 많이들 사용 하였습니다. 2)과도한 RMI Call RMI호출은 Java object를 직렬화 하고 역 직렬화하는 과정을 수반하는데, 이는 CPU를 많이 사용하는 작업이기 때문에 항시 주의를 요합니다. 특별히 RMI Call을 하지 않더라도 EJB를 call하는 것이 Remote일 때는 RMI호출을 사용하게 되고 부하량이 많을 때는 이 부분이 주로 병목의 요인이 되곤 한다. JEUS에선 single-vm-only 및 local invocation optimize 기능을 적절히 잘 사용합니다. 3)JNDI..

1, SUN, HP HP Jmeter를 활용하기 위해선 JVM option에 아래와 같은 옵션을 추가해 주어야 합니다. -Xrunhprof:heap=all,cutoff=0 HP jmeter 실행은 아래와 같이 합니다. Memory dump size에 따라 heap을 조절 하여야 합니다. java -mx128m -jar HPjmeter.jar 위와같이 하고 kill -3 java_pid와 같이 하여 분석하고자 하는 Container에서의 memory snapshot을 jmeter를 통해 확인 할 수 있게 됩니다. 주의할 점은 운영 시 위와 같은 JVM옵션으로 인해 performance가 저하 될 수 있으므로 꼭 확인 할 수 있는 상황에서만 쓰도록 한다. Window-> New Window 그리고 다른 me..

Heap Analyzer를 통해서 Memory leak을 분석을 위해 아래와 같이 Tree view를 확인하고 Memory를 많이 차지하거나 leak이 있을 의심스러운 곳을 마우스 오른쪽 클릭을 하여 locate a leak suspect부분을 누르면 아래와 같은 화면을 확인할 수가 있습니다. 아래 분석 결과를 보면 110M에서 8M로 급격히 떨어지는 부분을 확인 할 수가 있는데, 모두 java.util.hashtable(대략 5K)이 모여서 110M 정도의 메모리를 소요하고 있음을 확인 할 수 있습니다. 대략적으론 이렇고 어느 어플리케이션 에서 일으키는지 확인하려면 heapdump 발생 후에 발생한 javacorexxx.txt를 분석해야지 알 수가 있습니다. 아래는 dump 분석 결과를 보면 정확히 J..

JEUS상의 문제 분석 방법 JEUS Server log분석 1) OutOfMemory인데 어떤 유형의 OOM인지 대략적으로 파악을 합니다. 2) Log size가 크면 split같은 command를 이용하여 file을 자르거나 Log pattern 검색 스크립트 같은 것을 작성하여 필터링한 로그를 가지고 따로 확인합니다. webadmin의 gc 모니터링 GC log 분석 gc.log를 생성하여 tail –f gc.log를 하여 Full GC 횟수 및 시간등을 파악한다. 원인 파악을 위한 JVM 옵션 및 JEUS 옵션 1.SUN 및 HP - -Xloggc:${LOG_HOME}/gc.log 2.IBM - -verbose:gc -Xverbosegclog:${LOG_HOME}/gc.log Thread dump..

OutOfMemory Exception 정의 Garbage Collector가 새로운 Object를 유지하기 위해 충분한 메모리 공간을 확보하지 못할 때 발생함. Vendor사의 JVM 메모리 모델방식을 참조하여야 함. OutOfMemory는 이하 OOM이라 약어로 표기함. OOM유형별 현상정리. Heap Memory가 Full인경우 1)응용프로그램의 특정시점에서의 과도한 메모리 사용에 의한 경우(급진적 증가) 응용프로그램에서 과도하게 heap 메모리를 사용하여 OOM이 발생하는 경우는 이 에러가 발생하는 시점의 Thread dump를 통하여 어느 프로그램인지를 판별할 수 있습니다. 특정시점에서 Thread dump를 2~3번정도 시도하여야 정확하게 어느 로직에서 문제를 야기 시키는지 명확해 집니다. 2..

classloader 상의 해당 class의 모든 위치를 찾아주는 소스입니다.

현재 설정된 로케일 정보를 확인 하는 소스 입니다.