행복한 아빠

운영 중 장애를 접할 때 개발자가 남긴 로그는 참 유용합니다. 하지만 실 운영환경에서는 로그를 debug 레벨로 남기지 않아 장애 원인을 찾기가 어려울 때가 있습니다. 왜 만들었나?이번에 참여한 프로젝트에서는 iBatis를 사용하고 있습니다. 운영팀은 장애가 나면 실제 실행된 SQL 과 파라메터, 반환값을 보고 원인을 찾는다고 합니다.그런데 실 운영환경에서는 로깅 부하 및 로그파일의 증가 때문에 보통 debug 레벨의 상세로그를 남기지 않습니다. 그래서 필요할 때만 iBatis의 SQL 로그를 남기는 장치를 넣으려다 아예 실시간에 모든 로그를 조정하는 장치를 만들어 공개합니다. 해결해야할 문제보통 Log4J 로깅방법 및 로깅레벨은 log4j.properties나 log4j.xml 파일에 설정하고 로깅레벨..

운영 서버에 문제가 발생했습니다. 어떤 요청이 문제를 일으키는 것 같습니다. 이런 경우 여러 가지 방법으로 모니터링을 합니다. 그 중 쓰레드 덤프를 뜨는 경우도 많습니다. 쓰레드 덤프 뜨고 분석하려면 JVM 프로세스에 SIGQUIT 시그널주고 로그 받아와서 사무라이 같은 걸로 분석하고 합니다. (JVM hang 걸렸을 때 thread dump 남기는 법) 계속 이런 식으로 하기 너무 귀찮아서 쉽게 쓰레드 덤프 보는 JSP 만들었습니다. 저처럼 이런 걸로 수고하시는 분들과 공유합니다. (이미지출처) 설치 모니터링 하는 거 하나 설치하려면 대부분 복잡합니다. 저는 이런 거 싫어서 그냥 JSP로 만들었습니다.(날코딩) 그냥 아래 threaddump.jsp를 다운받아 web app에 JSP 실행할 수 있는 디렉..

소프트웨어를 만들고 운영하면서 문제를 찾아 해결해야 하는 일이 일상입니다. 후배들이 문제를 찾는데에 어려움을 느낄 때 가끔 도와주는데 제가 보기에 그닥 좋지 않은 방법으로 문제해결을 하려고 합니다. 제가 문제를 해결하는 방법을 소개하려고 합니다. 문제해결 중 디버깅을 예로 들어 설명해 보겠습니다. 이미지출처 자주 발생하는 상황 디버깅할 때 많이 볼 수 있는 상황은 소스를 작성한 본인이 의심되는 구간을 열심히 살펴보고 테스트하는 경우입니다. 이럴 때 인지부조화 상태에 빠질 가능성이 높습니다. 특히 긴박하거나 압박이 오는 경우에 더하죠. 이런 상태라면 엉뚱한 다리를 긁는 경우가 발생합니다. 분명 고쳤는데 변화가 없지?? 하는 경우죠. 이럴 때 많이 하는 말이 이상하다. 이전에는 잘 되었는데. 처음 보는 현상..

0. 지혜롭게 살자 많은 개발자가 전통적(?)인 방법인 System.out....로 디버깅을 많이 하고 있다. 물론 이것처럼 확실한 방법도 없지만 eclipse나 다른 IDE의 디버그 기능을 이용하면 훨씬 빨리 문제를 찾을 수 있다. 특히 WAS에 배포된 환경에서 이런 방법으로 하려면 확인하기 위한 System.out...을 고칠 때마다 배포해야 하는데 이건 너무 고통스러운 작업이다. 단위 테스트시 에러가 발생했을 때는 eclipse등을 이용해서 디버깅하기가 수월하다. 그러나 WAS에 배포된 후에 에러가 발생했을 때는 약간의 작업이 필요하다. WAS를 eclipse에 embeded한 플러그인을 이용하는 방법도 있지만 WAS와 이클립스를 따로 띄워 원격으로 버그를 찾는 방법을 정리한다. 이럴 경우 서버환경..

개발 중 가끔 클래스를 수정해서 올렸는데 계속 적용이 되지 않는 경우가 있습니다. 그래서 계속 수정해서 올리고 변경이 안되어 쓸데없는 시간을 보내곤 합니다. 여기에서는 지금 구동 중인 java 클래스가 어디에서 로드되는지 알아내는 방법을 소개합니다. 사전지식 JVM의 Classloader 구조를 정확히 이해하고 클래스가 어디에서 어떻게 로드되어 구동되는지 알아야 합니다. 일반적으로 JVM의 클래스로더는 계층(hierarchy)구조를 가지고 있으며 각 클래스 로더는 하나의 부모 클래스 로더를 갖습니다. (물론 루트: boot classloader 제외) 다음은 Tomcat의 클래스로더 구조입니다. (WAS 마다 조금씩 다르지만 거의 비슷합니다.) 클래스 로더의 규칙은 다음과 같습니다. 클래스 로더는 동일한..

jQuery의 ajax API를 이용하여 웹애플리케이션을 구현하던 중 IE에서 이상한 현상을 발견하였습니다. jQuery의 ajax API 중 get 방식을 이용할 경우 IE에서 오직 한번만 서버를 호출합니다. 두번째 호출부터는 데이터가 바뀌어도 첫번째 정보를 주기에 갱신이 되지 않네요. 헐~ 주로 불여우에서 개발하다가 나중에나 발견하는 현상인데 원인을 살펴보니 jQuery의 오류가 아니고 IE의 Caching 이슈이었습니다. 원인 Fire fox에서는 되고 IE에서는 안되니 IE에서 직접 XMLHTTP를 잡아서 호출해보았습니다. 아니나 다를까 fiddler로 잡아보니 서버 호출은 이루어지지 않고 4번째 줄 이벤트로 발생하지 않습니다. 구글링해보니 역시 IE의 caching 이슈가 있었습니다. http:..

HTTP 는 대형 네트워크 시스템 아키텍처를 염두한 프로토콜이기에 단순하면서도 다양한 스펙들이 존재합니다. 대형 네트워크 시스템이다 보니 서로 주고 받는 정보가 많을 것이고 이에 네트워크 부하나 서버 부하가 발생할 소지가 매우 큽니다. 그런 상황을 위해 HTTP에는 단순하면서도 강력한 캐싱 메커니즘을 제공하고 있습니다. 브라우저와 웹서버와의 대화 브라우저는 웹서버에게 이미지, CSS 그리고 동적생성 정보(HTML, XML, JSON... 등 많은 컨텐츠를 요청합니다. 그런데 동일한 리소스(이하 컨텐츠)를 여러번 요청하는 경우가 굉장히 많습니다. 전형적인 예가 이미지나 CSS 같은 정적 컨텐츠인데 이런 것을 요청할 때 브라우저와 웹서버가 어떻게 대화하는지 아래 그림으로 살펴보겠습니다. 1: /AAA 컨텐츠..

느린 사이트는 우리를 참 짜증나게 합니다. 더 힘든 건 그 사이트를 내가 만들었을 때입니다. 튜닝을 할 건 다 했고 그래도 성능이 안 나오면 흥분하는 고객을 진정시키는 건 참 어려운 일입니다. 최후의 수단인 캐싱을 이용한 성능향상 방법을 소개합니다. 미리 만들어 놓기 극단적인 성능 향상 방법이라고해서 뭐 대단한 것은 아닙니다. 바로 캐싱하는 방법입니다. 우리는 알게 모르게 캐싱을 많이 사용하고 있습니다. DB도 그렇고 파일 시스템도 그렇고 웹서버도 사실 캐싱을 사용하고 있습니다. 반복적으로 사용하는 정보는 매번 만들지 않고 한번만 만들어 사용하자는 전략입니다. 웹 애플리케이션은 많은 경로를 지나고 그만큼 많은 캐싱 지점이 있습니다. 그림과 같은 단순한 아키텍처에서도 4개정도의 캐싱 가능한 지점이 있네요...

성능이 안나와 튜닝을 하려고 공짜 profiler를 구하는데 대부분 오래전에 작성한 것이고 잘 돌아가지도 않았습니다. 그중 그나마 최신(?)에 릴리즈되고(2008년 1월) 버전이 높고 간단하게 돌아가는 것을 찾았습니다. 오늘 소개할 것은 JIP이라는 프로파일러 입니다. http://jiprof.sourceforge.net/ 환경 여기서는 다음과 같은 환경으로 사용예를 설명합니다. Java: Java5. JVMPI 를 이용하기 때문에 Java5 이상 버전에서 가능합니다. Tomcat 6.0.14 : WAS마다 설정방법이 다를 수 있습니다. 설치디렉토리는 C:\Tomcat 으로 가정합니다. OS는 Windows로 설명합니다. 다운로드 및 설치 1. JIP을 다운받습니다. http://sourceforge.n..

Java 애플리케이션은 메모리 관리를 자동으로 해주어 개발자를 행복하게 만들었지만 그 반면에 JVM 메모리 문제는 java 애플리케이션 성능에 굉장한 영향을 미칩니다. 특히 대량의 트랜잭션이 발생하는 Java 애플리케이션의 경우 프로그램 만들때도 메모리 사용에 대해 많이 신경을 써야하고 튜닝 시 메모리 설정에 굉장히 신경써야 합니다. 성능에 문제가 발생했을 경우 메모리의 사용패턴을 살펴볼 필요가 있습니다. Full GC라도 하는 경우에는 JVM이 아예 잠시 멈추거나 걷잡을 수 없는 상황(hang...)으로 갈 수도 있습니다. Garbage Collection 기록을 남기자 대부분의 JVM은 GC 기록을 남기는 옵션을 지원합니다. 그 옵션은 -verbose:gc 이고 비표준 옵션은 다음과 같은 것이 있습니..