Java

Java

From Chaehyun

(Difference between revisions)

Jump to: navigation, search

Revision as of 13:27, 22 May 2012

Lock을 피하는 10가지 방법 -> 나중에 읽어볼 것
쓰레드 덤프
- linux : kill -3 pid 명령어
- windows : ctrl + break
- 공통 : jstack (비추)
- kill -3 dump는 크게 문제 없음 (운영 중인 서비스라 할지라도)

pid 확인 방법
- linux : ps -ef | grep java
- windows : 작업 관리자 프로세스 화면 -> 보기 -> 열선택

JConsole
- cmd 창에서 JConsole - Connect
- jps
- jstack ### (dump 나옴)

deadlock 실습
- http://examples.oreilly.com/jenut/Deadlock.java
- linux에서 컴파일 하고 실행
- kill -3 ### (이건 실행되고 있는 화면에 업데이트 됨)
- 이거 실제로 눈으로는 못함

툴을 사용하자
- TDA (Thread Dump Analyer) http://java.net/projects/tda/
- 윈도우에서 로그 남기는 팁
  - putty 설정 - Change Setting - Session - Logging - All Session output
  - screen은 끄고 하는 게 신상에 이로움
- TDA에서 로그 파일을 연다
  - 로그파일(날짜)로 시작하는 파일이어야 TDA에서 제대로 인식함

ps -eLf | grep java
- thread별 cpu 사용량을 보여준다
- watch out L option
- TDA에서 Native-ID랑 ps -eLf 네 번 째 옵션이랑 동일함 -> TDA에서 해당 Native ID를 확인하면 어느 thread가 계속 먹고 있는지 확인할 수 있음
- TDA에서 네 번째 쌍안경을 누르면 계속 각 dump에서 계속 살아 남은 thread를 확인할 수 있음

Contents

1 실습
2 메모리

실습

네이버 뉴스
- 네트워크, 디스크 가 병목이었을 수 있음
포토
- 자바 문제가 아님, 아파치 웹 서버 문제였음
- 스레드 수로 대충 파악 가능함
activeQ
- thread에서 AlamrmListener 클릭
- 아래에 링크 클릭
- 모니터로 연결
- 많은 thread가 줄 서 있음
cafe
- elf log 보면서 시간이 많이 걸린 녀석들을 찾아본다
- TDA - thread에서 Native ID로 조회해서 확인
- GC가 시간을 다 먹고 있었음
- memory leak

메모리

c1visualizer : 메모리가 어떻게 사용되는지 보여준다...??
- 최적화된 for문 찾기??
- debug option이 사용 가능한 JDK가 필요함
- 오라클 사이트에서 DEBUG build 를 다운 받는다

Java OutOfMemoryError 뒤에 나오는 멘트가 중요함

교재 참조

jstat -gcutil pid 5s : fgc 보고 heap dump를 뜰지 판단한다
jstat -gccapacity : 영역별로 점유되어 있는 메모리의 크기

heap dump

메모리 leak이 있다고 생각될 때
jmap -histo pid : 어느 객체가 메모리를 많이 사용하고 있는가
- 시작하자 마자 heap dump
- 1일 후, 1주일 후, heap dump를 써서 비교한다 ->

냐함

jvisualvm
cat /proc/interrupts
vmstat 2

collectd 설치

Retrieved from "http://chaehyun.kr/w/Java"