안녕하세요! 오늘은 D2 OPEN SEMINAR를 다녀온 후기를 올리도록 하겠습니다.
5월 22일 NAVER D2 STARTUP FACTORY 강의장에서 진행했던 D2 OPEN SEMINAR에 참석했습니다.
세미나에서 음식은.... 너무 개발자스럽지 않나 싶은 아메리카노와 도너츠를 제공하시더군요!
이건 너무 개발자 스러운거 아니야? 냄새날꺼같아! 하면서도 맛있게 먹었습니다 ㅋ
강의를 들었던 강의장에 개최된 첫 세미나였다니... 앞쪽 중앙에 보이는 간판(?) 이 아주 멋지더군...요.....;;; 이번 세미나가 처음이었던 강의장이라니 팁같지도 않은 팁을 드리자면... 더우면 빨리 블라인드커텐내릴것, 오른쪽 맨 뒤의 의자가 제일 편하다는것 정도입니다 ㅋ
세션은 아래와 같이 진행됐습니다.
1.Java 성능에 대한 오해와 편견
2.스레드덤프 분석기법과 사례
3.Java 애플리케이션 트러블 슈팅 사례 & Pinpoint
4.Pinpoint 개발하면서 고민한 문제들
5.연사와 참석자들이 자유롭게 토론하는 시간
Pinpoint란게 궁긍해서 가봤던건데...
기존 Pinpoint개발자는 퇴사하시고... 같이 하시던분이 계속 이어가고 있다고 들었습니다.
Pinpoint는 GitHub에 올라온 기능이 거의더라구요.
1) Google Dapper를 차용하여 트랜잭션을 이용한 Multi tier Map 생성하여 가시화
추후 컴포넌트 별 Groupping하여 제공할 계획도 있다고 합니다.
2) 토종 APM에 빠지지 않는 응답시간 분포도
여기서 좀 특별했던 기능은 트랜잭션 콜트리를 보여줄 때 컴포넌트별로 좌측에 라인 색을 다르게 하여 표시해주는 것이었습니다.
3) 각 컴포넌트 별 성능 확인 가능
4) 네이버에서 사용하는 로그분석 프로그램과 연동하여 로그 확인 가능
전 개발자는 아니지만.. Java 개발자 입장에서 답변하기 곤란했던 것에 대한 답변 및 어플리케이션 문제생겼을 경우 어떻게 잘 해결하나에 초점을 잘 맞춘 세미나 였습니다.
첫번째 세션인 Java 성능에 대한 오해와 편견의 결론은 'Java는 native보다는 느리지만 개발 및 서비스 운영하기에는 느리지 않다'였습니다. 부가티와 BMW를 비교하며 드림카가 부가티라도 현실적으로는 BMW가 더 적합하니 Java도 나쁘지 않다로 끝맺더군요.
GC튜닝하는 방법, IO성능 향상 방법, DB Connection으로 느려진 성능 커버방법, JDK업데이트 시 고려할 것 등에 대해 설명하며 Java가 나쁘지 않음을 어필했습니다.
이렇게만 쓰면... 어떻게 한다는거야? 며 궁금하실까마 전반적인 세미나 내용이 담긴 링크 첨부합니다.
http://helloworld.naver.com/helloworld/1286587
두번째 세션은 스레드덤프 분석기법과 사례였습니다.
힙덤프 가기전에 거쳐가는 스레드 덤프... 어떻게 분석하느냐에 대해 잘 설명해줬어요.
덤프생성방법, 덤프읽는방법, 트러블 슈팅 사례 등에 대해 설명을 해줬구요, 이건 위에 링크 첨부한것과는 달리 간단히 설명들어 가겠습니다.
- 스레드 덤프 생성
Unix : kill -3
Windows : Ctrl + Break
공통 : jstack [PID]
- 스레드 덤프 읽는 방법
상태에 대해 부연설명하면...
BLOCKED : Synchronied, deadlock
WAITING : wait조건, 이전 로직 등 파악하여 wait하는 객체 notify 코드를 찾아야함
RUNNABLE : RUNNABLE인 경우에도 움직이는지 native확인 필요
이정도 입니다.
개발할 때 스레드덤프 분석을 용이하게 하기 위해 Thread객체 이용하면 setName()사용, ThreadFactory면 Thread할당 시 Runnable에서 변경해서 잘 개발하면 좋겠더라구요.
- 스레드 덤프를 이용한 트러블 슈팅 사례
현상1 : CPU로드가 증가됨 -> Thread leak이 원인
현상2 : 응답시간이 느려짐 : log4j의 %F%L옵션이 lock을 유발하여 해당 옵션 제거
현상3 : 간헐적 CPU 100% 재시작 후 정상 : ps -mo로 CPU 많이 사용하는 lwp획득하여 해당 스레드 덤프 확인하니 commons-beanutils의 BEANUTILS-318버그로 WeakHashMap이 동시 접근하낸 내역 파악
세번째 세션은 Java 애플리케이션 트러블 슈팅 사례였고 역시 사례위주로 공유를 해주었습니다. 트러블 슈팅을 위한 정보로 A, B, C, 트러블 슈팅 사례, 분석 시 추천 도구에대해 설명했습니다.
트러블 슈팅을위한 정보 A는 사용자 현상 파악단계, B는 서버 상태 파악 단계, C는 어플리케이션 정보 파악 단계로 이후 사례정리 시 A, B, C로 나누어 정보를 보여주며 설명했습니다.
문제 해결 유형을 인프라 요소 설정을 변경, 메모리릭, 무한루프 등으로 간당히 정리를 해준 후 개별 사례에 대해 설명을 했는데 설명을 하기 좋게 하기 위해서 간단간단한 것들에 대한 사례를 들었습니다.
- 트러블 슈팅 사례
현상1 : C.CMS GC에서 긴 Stop the world -> Hpjmeter로 확인 시 promotion fail확인 -> GC 시점을 앞당기도록 CMSInitiatingOccupancyFraction값을 70으로 변경
현상2 : 서버 뜨자마자 Full GC 자주 발생 -> B.DB서버 IO가 높고, C.힙덤프 확인 시 com.mysql.jdbc.ByteArrayRow객체가 생겨있고 많은 건수를 조회하는 SQL이 있었음->DBCP설정의 validationQuery가 데이터가 있는 테이블 조회하여(select 0 from users) 해당 쿼리 변경
* 권장 validationQuery설정
Oracle : SELECT 1 FROM DUAL;
MS SQL : SELECT 1
Mysql : SELECT 1
Cubrid : SELECT 1 FROM db_root
* DBCP 2.0에 ValidationQuery 속성 없을 시 Connection.isValid()호출하여 유효성 검사
현상3 : A.특정시간 응답시간이 늘어남 C.GC 수행 중 응답시간이 늘어나며 문제 시간대 GC를 함 -> GC로그 분석결과 점진적으로 메모리 증가되는 그래프 파악 -> 힙덤프 시 메모리의 대다수를 점유하고 있는 객체 발견 -> Spring 프레임워크 내부 객체 Cache로직에서 메
모리릭 발생하여 어플리케이션 코드 수정하여 해결.
http://www.slideshare.net/benelog/ss-35627826의 11페이지 참고.
현상4 : 가끔씩 OOM 발생 -> A.간헐적 503에러, C.장비1대에서OOM에러, 힙을 늘려도 발생->힙덤프 분석결과 LinkedHashMap관련 객체가 대다수 힙을 차지하며 자체 cache모듈의 thread-safety문제로 메모리릭 발생 하여 수정하여 해결.
분석 시 사용하기 좋은 도구를 추천해줬습니다.
-추천 도구
스레드 덤프 : TDA, Thread Logic
힙덤프 : MAT, IBM Heap analyzer
GC로그 : HPJmeter
프로파일러 : Yourkt, JProbe
실행탐지 : Btrace
Pinpoint활용 사례는 다른 APM활용 사례나 별차이 없고, Pinpoint개발기는...음.....음............;;;;;
안보셔도 되지만 궁금하시다면 아래 링크를 보세요.....
http://helloworld.naver.com/helloworld/1286587
네이버에서 개발 관련 책도 내고 오픈 소스 솔루션도 만들어놓고 이런 세미나도 하는걸보니... 우리나라도 이제 덜 폐쇄적이 되어가나 싶기도 하고 신선했어요!!!
Pinpoint가 얼마나 더 좋은 툴이 될까 궁금하기도 하고... 앞으로 또 오픈이 될 다른 APM이랑은 또 어떤 구도를 보일지도 궁금하네요...
