반응형
| Java on AIX 문제해결: AIX 코어 덤프용 데이터 컬렉션 (한글)
문서 옵션 이 페이지를 이메일로 보내기 제안 및 의견 피드백 난이도 : 초급 IBM Java Support on AIX Technical Team, Technical Support, IBM Roger Leuckie, Previous Team Lead for ISV and UNIX Technical Support for Java, IBM Dawn Patterson, Previous ISV and UNIX Technical Support for Java, IBM Jason Cheng, Technical Support Center, IBM Hong Kong, IBM Rajeev Palanki, Level 3 Java Support, IBM 2006 년 8 월 28 일 Java 프로그래밍시 시간을 절약할 방법을 찾으십니까? 이 글은 IBM AIX 운영 체제 환경에서 Java 프로그래밍시의 문제 해결을 위한 안내서입니다. 저자는 Java 애플리케이션과 관련한 프로세스의 오류 환경을 분석하기 위해 AIX 코어 파일과 다른 관련 파일들을 모으는 방법을 설명합니다. 주 이 글은 사용자의 편의를 위해 제공한다. 이 글의 내용은 현재의 사실만을 근거로 하며 어떤 보증이나 지원도 되지 않는다. 이 글의 내용은 가능한한 주기적으로 업데이트 될 것이다. 다음과 같은 문서와 툴 정보도 참조하기 바란다: IBM Java™ Virtual Machine (JVM) Diagnostic guides Java for AIX® Download and Service page AIX documentation for the snapcore command AIX Installation Guide and Reference 머리말 코어 덤프 문제를 해결하기 위해 데이터를 모으는 방법을 설명하고자 한다. 지원 센터에 연락하기 전에 이 글에서 설명한 단계들을 밟아가면, 이미 데이터가 있기 때문에 빠른 솔루션을 얻을 수 있다. AIX 환경 변수를 설정하여 fullcore dump 실행하기, 자바를 설정하여 JVM 시그널 핸들링을 억제시키기, 코어 파일과 제휴 라이브러리들을 모으기 등이 단계에 포함된다. 올바른 기대 자바 프로세스가 중지되는 이유는 여러 가지이다: 메모리 액세스 문제 잘 못 컴파일 된 원시 코드 그릇된 설정 불량 코드 메모리 제약 아마도 JVM 코드(JIT), AIX(라이브러리), 기타 원시 코드 때문에 생겨나는 문제일 것이다. 정보를 모을 때에는 오류를 여러 번 재현하여 데이터를 모으고 제거하는 과정을 거쳐 문제를 규명하고 해결해야 한다. Javacore 파일이 충분하다면 AIX 코어 파일과 기타 정보를 모으면 된다. 테스트 랩(lab)이나 개발 환경에서 문제들을 재현할 수 없다면 운영 시스템에서 데이터를 모아야 한다. 문제가 되는 시스템에서 데이터가 취합되지 못하면 지원팀은 문제를 해결할 수 없다. 운영 환경에서 데이터를 모으면 애플리케이션의 다운으로 이어질 수 있고, 이는 곧 매출액, 안정성, 고객 인식에 영향을 미칠 수 있다. 따라서 지원팀은 정보를 모으는 작업을 최소한으로 하고 가능한 빨리 문제를 해결해야 한다. 서비스 공지 IBM Developer kits for AIX, Java technology edition에서 AIX Java 서비스 페이지를 반드시 읽어야 한다. 특히, 메인 다운로드 페이지의 "End of Service" 날짜에 유의하고, 다운로드 테이블 밑에 있는 AIX에 대한 자바 지원의 조건도 잘 읽어봐야 한다. Javacore 대 AIX core Javacore 파일은 자바 애플리케이션 종료시의 애플리케이션 상태를 저장한다. 다음과 같은 상황에서 Javacore 파일이 자바 프로세스에 의해 만들어진다. 사용자가 자바 프로세스에서 kill -3 명령어를 실행할 때 중대한 오류/예외 때문에 프로세스가 중지 또는 종료될 때 Javacore 파일에 대한 자세한 내용은 IBM JVM Diagnostic Guide를 참조하라. 어떤 경우에는, 같은 프로세스에서 만들어진 Javacore 파일 모음들이 애플리케이션 작동을 이해하는데 도움이 될 수 있다. 프로세스가 중지하거나 불안정한 상황이 되면 프로세스는 Javacore 파일을 만들지 않을 수도 있다. AIX core는 특정 상황에서 메모리에 있는 프로세스 상태를 바이너리로 저장한 것이다. Javacore 보다 더 많은 정보를 얻을 수 있고 Javacore 파일에서 보고되지 않은 추가 프로세스 정보를 얻을 수 있다. 따라서, 대부분의 지원팀들은 Javacore 파일 보다는 AIX core 파일을 요청한다. 운영 체계 설정하기 기본적으로, 코어 파일은 프로세스의 실행 디렉토리에 만들어 진다. 코어 파일용 디폴트 리파지토리는 사용자가 변경할 수 있다. 코어 파일에 대한 현재 리파지토리를 디스플레이 하려면 다음 명령어를 실행한다. syscorepath -g 이 글에서 설명하고 있는 명령어를 잘 모르겠다면 AIX Documentation library를 참조하라. 명령어를 실행할 때 이탤릭 체로 된 텍스트를 알맞은 값으로 대체하도록 한다. 그렇지 않으면 에러나 예기치 않은 결과가 생긴다. AIX에서 전체 또는 완전한 코어 파일을 만들어 내려면 다음과 같이 한다. 루트 사용자로서 다음 명령어를 실행하여 사용자 프로세스 한계를 무제한으로 설정한다:chuser fsize=-1 data=-1 core=-1 user_id_running_application 여기에서 user_id_running_application은 자바 애플리케이션을 실행하고 있는 사용자의 이름이다. 예를 들어:chuser fsize=-1 data=-1 core=-1 root 이것은 파일 크기(faize), 코어 파일 크기(core), 메모리 크기(data)를 무제한 상태(ulimit)로 변경한다. 이러한 설정에는 위험이 따르기 때문에 정보가 모아지면 원래 설정이 재적용 되어야 한다. 일단 변경되면 로그인, 사용자 프로파일, 시작 스크립트에 있는 ulimit 명령어에 대한 레퍼런스를 제거한다. 애플리케이션을 시작하기에 앞서 사용자로서 다시 한번 로그인 하여 새로운 프로세스에 변경 사항을 적용한다. 사용자가 다시 한번 로그인을 하지 않으면 ulimit의 변경 사항은 프로세스에게 적용되지 않는다. 프로세스가 재시작 되더라도 마찬가지다. 또한 /etc/inittab 파일이나 cron deamon에서 시작되는 애플리케이션은 ulimit 변경 사항을 읽을 수 없다. 따라서 ulimit 명령어로 ulimit -d unlimited 같은 프로세스 시작 스크립트에서 ulimit을 변경하여 데이터 제한을 무제한으로 변경한다. 이렇게 수정함으로서 사용자 ID에 대한 시스템 리소스 사용 제한을 제거할 수 있다. 문제가 해결되면 이전 ulimit 값으로 반드시 복원해야 한다. 자바 애플리케이션을 시작하기 전에 ulimit -a 명령어를 실행하여 변경 사항을 확인한다. 다음 명령어를 루트 사용자 상태에서 실행하여 시스템에 대한 전체 코어 덤프를 실행한다: chdev -l sys0 -a fullcore=true 여기에는 시스템 재부팅이 필요 없다. SMIT 유틸리티에 대해 잘 알고 있다면 smitty chgsys를 실행하고 Enable full CORE dumps에 대한 값을 true로 설정하면 설정이 변경된다. AIX 5.2 또는 이후 버전에서 제공하는 syscorepath 유틸리티로 프로세스들의 모든 코어 파일들이 저장되는 하나의 코어 디렉토리를 지정할 수 있다. 시스템 상의 모든 사용자는 이 디렉토리에 대해 읽기 및 쓰기 권한을 갖고 있다. 사용자가 디렉토리에 쓰기 권한이 없다면 코어 파일이 생성되지 않는다. 이 시스템 중심 디렉토리에 생성된 코어 파일들에는 프로세스 ID와 시간에 근거하여 core.pid.MMddhhmmss 같은 고유 이름이 주어진다. 여기에서 pid는 프로세스 ID이고 MM은 달(month), dd는 날(day), hh는 시간, mm은 분(minute), ss는 초(second)이다. 하지만 이 방식을 권하지는 않겠다. 이 명령어 구문은 다음과 같다: syscorepath -p alternate_directory 다음을 사용하여 코어 파일에 대한 디렉토리, 파일 소유권, 권한을 확인하라:aclget directory_or_file 이 명령어는 애플리케이션을 실행하는 사용자가 목표 디렉토리에 대해 쓰기 권한이 있는지를 확인하는 것이다. 문제가 없다면 사용자 로그인 동안 다음 명령어를 실행한다:touch directory /core Use the chmod 또는 chown 명령어를 사용하여 각각 소유권이나 권한을 수정하거나 smitty user를 실행하여 사용자 계정의 특성을 수정한다. 사용자 계정을 수정할 때에는 수정된 사용자로 다시 로그인 해야 한다. 코어 파일을 저장할 알맞은 디스크 공간이 있는지를 확인한다. 코어 파일은 메모리 상의 프로세스 크기에 비례한다. ps 명령어 아웃풋에서 나온 RSS(process size) 값이 대강의 코어 파일 크기이다. 예를 들어:ps avwwg java_pid 추가 공간이 필요하면 필요 없거나 오래된 파일들을 지워 공간을 확보하거나 해당 파일 시스템의 크기를 늘린다. 아래의 AIX 명령어 세트나 유틸리티는 정보를 모으는데 사용된다. 다음 AIX 파일세트(fileset)를 설치한다: File Fileset -------------------------------------------------- /usr/bin/uudecode bos.net.uucp /usr/bin/syscorepath bos.rte.control /usr/sbin/snapcore bos.rte.serv_aid ( also /usr/bin/truss ) 다음 명령어를 사용하여 모든 파일세트가 올바르게 설치되었는지 확인한다:lslpp -l fileset_name 설치되지 않은 파일 세트는 AIX 설치 미디어로부터 설치할 수 있으며, IBM Fix Central에서 업데이트를 다운로드하여 최신 레벨로 업그레이드할 수 있다. 자바 시그널 핸들링 디스에이블(disable) Javacore 대 AIX core 섹션에서 언급했지만, Javacore 파일이 행(hang) 상황을 해결하는 최상의 툴은 아니다. 바이너리 AIX코어 파일이 더 유용한 정보를 제공하기도 한다. 좋은 AIX코어 파일을 얻기 위해서는, 프로세스로 보내지는 신호를 받을 때 Javacore를 만들지 않도록 JVM이 설치되어야 한다. 시그널 핸들러가 작동한다면 프로세스의 "현재" 상태가 나타나고 이렇게 되면 실제 문제가 감춰진다. 애플리케이션에 SIGILL, SIGFPE, SIGBUS, SIGSEGV를 처리하는 시그널 핸들러가 있다면, 바로 그러한 시그널 핸들러들이 작동하지 못하도록 해야 한다. 애플리케이션이 시작되기 전에, 애플리케이션을 실행하는 환경에서 변경 작업이 이루어져야 한다. 애플리케이션이 WebSphere® 같은 프로세스에 의해 시작되는 상황에서, 이렇게 환경을 설정하면 자바 프로세스에 영향을 미치게 된다. 이 같은 상황에서는 애플리케이션 문서를 참조하여 애플리케이션에 맞는 환경을 설정해야 한다. JVM 시그널 핸들링이 작동하지 않도록 한다(disable). 환경 변수들은 애플리케이션이 재시작 하기 전에 설정되어야 한다. export DISABLE_JAVADUMP=true export IBM_NOSIGHANDLER=true 변경 사항을 적용시키려면 애플리케이션을 재시작 해야 한다. 이렇게 하면, kill -3을 실행중이거나 다른 신호가 와서 프로세스를 종료해야 하는 상황에서, Javacore와 힙덤프 파일이 만들어지지 않는다. 애플리케이션 시그널 핸들링이 작동하지 못하도록 한다. 애플리케이션이 SIGQUIT, SIGILL, SIGFPE, SIGBUS, SIGABRT, SIGSYS, SIGSEGV 등의 시그널을 처리한다면 애플리케이션은 시그널 핸들러들이 작동하지 않도록 해야 한다. 예를 들어, IBM MQ는 기본적으로 SIGILL, SIGFPE, SIGBUS, SIGSEGV를 핸들한다. 좋은 코어 파일을 얻으려면, MQ는 환경 변수를 설정하여 이 같은 시그널 핸들러들이 작동하지 않도록 해야 한다. export MQS_NO_SYNC_SIGNAL_HANDLING=1 주: MQ는 수시로 변하기 때문에 MQ 설정을 반드시 확인해야 한다. 애플리케이션이 시그널 핸들링을 갖고 있다면 이것이 작동하지 않도록 하여 코어 파일을 생성하는 방법을 알아야 한다. 환경 변수를 어디에 설정해야 하는지를 파악한다. 환경 변수는 필요에 따라 많은 장소에 설정될 수 있다: /etc/profile /etc/csh.login $HOME/.profile $HOME/.cshrc $HOME/.kshrc 애플리케이션 시작 스크립트 및 설정 스크립트 /etc/environment 파일에 추가하는 것은 좋지 않다. 애플리케이션 시작 스크립트와 설정 스크립트가 다른 모든 것 위에 쓰여지기 때문이다. 데이터 모으기 문제가 발생하면 문제의 원인을 규명할 수 있을 정도의 충분한 정보를 모아야 한다. 운영 체제 (커널/라이브러리), JVM(또는 JIT), 애플리케이션 Java Native Interface (JNI) 원시 코드, 삼자 JNI 코드 등이 문제가 될 수 있다. 이 섹션에서는 각 영역에서 데이터를 모을 수 있는 명령어를 소개하겠다. 운영 체제 설정 정보 모으기: 코어가 만들어진 후에 다음 명령어를 실행한다: errpt -a > errpt.out lslpp -lc > lslpp.out instfix -i > instfix.out bootinfo -K > bootinfo.out lsattr -El sys0 > lsattr.out lsps -s > lsps.out 다음 명령어를 실행하여 아웃풋 파일을 압축한다: tar -cf - *.out | compress -c > sysinfo.tar.Z 코어 파일을 모으고 라이브러리를 제휴시킨다. 코어 파일이 어디에 있는지 확실히 모르겠다면 errpt -a | pg를 사용하여 LABEL: CORE_DUMP로 시작하는 엔트리를 찾는다. CORE FILE NAME이라고 하는 섹션에서 코어 파일 위치를 알려 줄 것이다. mv core core.001 javaLibsGrabber.sh core.001 compress core.001 javaLibsGrabber.sh 유틸리티를 다운로드 한다. 다음 명령어를 사용하여 javaLibsGrabber.sh가 라이브러리들을 모으는지를 검사한다:uncompress -c < core-libs.tar.Z | tar -tvf - javaLibsGrabber.sh가 잘 작동하지 않으면 다음과 같이 라이브러리를 모은다:snapcore -d save_directory core.001 fullpath_executable 예를 들어:snapcore -d /tmp/savedir core.001 /usr/java131/jre/bin/java 이것은 /tmp/savedir 디렉토리에 아카이브(snapcore_pid.pax.Z)를 만든다. 데이터 패키징 및 IBM 지원팀으로 데이터 보내기 다음 세 단계는 데이터를 패키징 하여 IBM 지원팀에게 보내는 방법이다: xxxxx.byyy.czzz.#.tar로 파일을 압축한다. tar -cf xxxxx.byyy.czzz.#.tar sysinfo.tar.Z core.001.Z core-libs.tar.Z optional-files 또는 tar -cf xxxxx.byyy.czzz.#.tar sysinfo.tar.Z snapcore_pid.pax.Z optional-files 다음과 같은 상황에서 파일의 크기에 주목하라: xxxxx는 PMR 넘버이다. yyy는 브랜치 코드이다. zzz는 국가 코드이다. #는 시퀀스 넘버이거나, testcase 서버에 있는 각 파일이 유일한 것인지를 확인하는데 필요한 데이터이다. 파일을 보내기 전에 각 아카이브 파일이 유효한지, 다음 사항들이 포함되어 있는지를 확인한다: sysinfo.tar.Z core-libs.tar.Z or snapcore_pid.pax.Z core.001.Z 이 파일은 업로딩 된 각 파일에 고유 파일 이름을 지어 IBM testcase server로 보내진다. AIX 지원 팀에서 빠른 응답을 얻으려면 아래 지침을 따르도록 한다. 데이터를 testcase 서버로 연결하거나 데이터를 testcase 서버로 보내는데 문제가 있다면 네트워크의 방화벽과 프록시 설정을 검사해보라. ftp testcase.boulder.ibm.com login: anonymous password: user@host.com > cd /aix/toibm > bin > put xxxxx.byyy.czzz.#.tar > quit IBM 지원 핫라인에 전화하거나 이메일로 문의하여 xxxx.byyy.czzz 형식의 PMR 번호를 확인하도록 한다. 기사의 원문보기 Troubleshooting Java on AIX: Data collection for AIX core dumps 참고자료 교육 IBM developer kits for AIX, Java technology edition IBM JVM Diagnostic Guides AIX documentation library developerWorks technical events and webcasts AIX and UNIX 토론 developerWorks blogs 필자소개 이 글은 Roger Leuckie, Dawn Patterson, Jason Cheng, Rajeev Palanki가 공동으로 집필했다. 현재는 IBM ztrans Java 지원 팀이 관리 및 업데이트를 하고 있다. AIX와 JVM의 변화에 맞춰 업데이트 되고 있다. 제안이나 의견이 있으면 팀 기술 대표나 팀 리더에게 연락하기 바란다. Roger Leuckie는 텍사스 오스틴 소재, ISV와 UNIX 기술 지원 팀에서 근무했다. (*rog@us.ibm.com) Dawn Patterson은 텍사스 오스틴 소재, ISV와 UNIX 기술 지원 팀에서 근무했다. (*dpatter@us.ibm.com) Jason Cheng은 IBM 홍콩 기술 지원 센터 소속이다. AIX, 자바, WebSphere Application Server를 전문으로 하고 있다. 또한 텍사스 오스틴의 ISV와 UNIX 기술 지원 팀을 돕고 있다. (*chengjcy@hk1.ibm.com) Rajeev Palanki는 IBM JVM그룹(인도 방갈로르) 소속 엔지니어이다. 자바 메모리 누수 디버깅을 전문으로 하고 있다. Java Diagnostics guide를 공동 집필 했으며, 수 많은 developerWork 기술자료와 IBM 레드북을 집필했다. http://www-128.ibm.com/developerworks/kr/library/es-javaonaix_core.html |
반응형