본 글은 고객 편의를 도모하고자 계획되었습니다. 본 내용은 보증이나 지원이 되지 않습니다. 본 글의 내용은 시간이 허락하는 한 최선을 다해 업데이트 할 예정입니다.
다음 링크를 통해서 지원 문서와 툴에 대한 상세한 정보를 받아보실 수 있습니다.
- IBM Java™ Virtual Machine (JVM) Diagnostic guides
- Java for AIX® Download and Service page
-
AIX documentation for the
snapcorecommand - AIX Installation Guide and Reference
이 글에서는 코어 덤프 문제를 해결하기 위해 데이터를 수집하는 방법을 설명한다. 지원 센터로 연락하기 전에, 이 글에서 설명한 단계를 따라가보면 여러분에게는 이미 데이터가 수집될 것이기 때문에 문제 해결도 할 수 있을 것이다. 본 기사는AIX 환경 변수를 설정하여 fullcore 덤프를 실행하는 방법, JVM 시그널 핸들링이 되지 않도록 자바를 설정하는 방법, 코어 파일과 제휴 라이브러리를 수집하는 방법을 설명한다.
자바 프로세스가 중지되는 이유는 여러 가지이다.
- 메모리 액세스 문제
- 잘못 컴파일 된 네이티브 코드
- 무효 설정
- 잘못된 코드
- 메모리 제약
정보 수집에는 문제를 여러 번 재생산 하여 문제를 규명하고 해결하는데 필요한 정보를 모아서 추려내는 것이 필요하다. Javacore 파일만으로도 충분하고, 여기에는 AIX core 파일과 기타 정보가 포함되어 있을 수도 있다. 해당 문제 현상이 테스트 환경이나 연구실 또는 개발 환경에서 재현 될 수 없다면 실행 시스템에서 데이터가 수집되어야 한다. 데이터가 문제가 발생한 시스템에서 수집될 수 없다면, 지원 팀도 그 문제를 해결할 수 없다.
실행 환경에서 데이터를 모은다면 애플리케이션의 중지될 수 있고, 이는 매출, 안정성, 고객 인지도에도 영향을 미칠 수 있다. 지원 팀은 최선의 노력을 다해 정보를 모으는 반복 회수를 최소한으로 줄이고 가능한 신속하게 문제를 해결하여야만 한다.
AIX용 자바 지원에 대한 중요한 정보는 IBM Developer kits for AIX, Java technology edition에 들어있다. 특히, 메인 다운로드 페이지의 End Of Service 날짜를 주지하고, 다운로드 테이블 밑에 있는 AIX용 자바 지원의 조건을 주의해서 읽기 바란다.
Javacore 파일은 자바 애플리케이션의 텍스트 표현이다. Javacore 파일은 다음과 같은 때에 자바 프로세스에 의해 생성된다.
- 사용자가 자바 프로세스에서
kill -3명령을 실행할 때 - 치명적인 에러/예외 때문에 프로세스가 중지 또는 종료될 때
어떤 경우에는, 같은 프로세스에서 생성된 Javacore 파일들이 애플리케이션의 작동 방법을 이해하는데 도움이 될 수 있다. 프로세스가 중지하거나 불안정한 상태에 놓이게 되면, 프로세스는 Javacore 파일을 생성할 수 없다.
AIX core는 메모리에 있는 프로세스의 바이너리 표현이다. 이 코어에서 Javacore에 기록된 더 많은 정보를 얻을 수 있고, Javacore 파일에 기록되지 않은 부가적인 프로세스 정보도 얻을 수 있다. 이와 같은 이유 때문에, 대부분의 경우 지원팀은 Javacore 파일 보다는 AIX core 파일을 요청한다.
기본적으로, 코어 파일은 코어가 덤핑되는 프로세스의 실행 디렉토리에서 생성된다. 하지만, 코어 파일의 기본 디렉토리는 사용자가 변경할 수 있다. 코어 파일에 대한 현재 저장소를 디스플레이 하려면, 다음 명령을 실행한다.
syscorepath -g |
이 글에서 사용된 명령어에 익숙하지 않다면, AIX Documentation library를 참조하라.
명령어를 실행할 때 이탤릭 체로 된 텍스트를 해당 값으로 바꾼다. 그렇지 않으면, 에러와 예상치 못한 결과를 얻게 된다.
AIX OS에서 전체 코어 파일들을 생성하려면 다음과 같이 한다.
- 루트 사용자로서 다음 명령어를 실행하여 사용자 프로세스 한계를 무제한(unlimited)으로 설정한다.
chuser fsize=-1 data=-1 core=-1 user_id_running_application
여기에서 user_id_running_application은 자바 애플리케이션을 실행하는 사용자의 이름이다. 예를 들어,chuser fsize=-1 data=-1 core=-1 root
이것은 파일 크기(fsize), 코어 파일 크기(core), 메모리 크기(data)의 제한을 무제한으로 바꾼다. 이러한 설정을 사용할 때 위험 부담이 있기 때문에, 정보를 수집했다면 원래 설정으로 돌아가야 한다. 변경된 후에는 로그인, 사용자 프로파일, 시작 스크립트에서
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 유틸리티는 프로세스의 모든 코어 파일들이 저장될 단일 시스템 중심의 디렉토리를 지정한다. 이 디렉토리에 대해서 시스템에 있는 모든 사용자들은 읽기 및 쓰기 권한이 있다. 사용자가 이 디렉토리에 대한 쓰기 권한이 없다면, 코어 파일이 생성되지 않는다. 이 시스템 디렉토리에서 생성된 코어 파일들에는 core.pid.MMddhhmmss와 같이 프로세스 ID와 시간에 기반하여 고유한 이름들이 주어진다. 여기에서 pid는 프로세스 ID이고, MM은 월, dd는 요일, hh는 24 시간 단위로 나타난 시간, mm은 분, ss는 초이다. 그러나 필자는 이 방식의 사용에 대하여 별로 권장하지는 않는다. 이 명령어에 대한 신택스는 다음과 같다.
syscorepath -p alternate_directory
- 다음을 사용하여 디렉토리, 파일 소유권, 코어 파일에 대한 권한을 확인한다.
aclget directory_or_file
이 명령어는 애플리케이션을 실행하는 사용자가 대상 디렉토리에 대한 쓰기 권한을 갖고 있는지를 확인한다. 의심할 여지가 없다면 애플리케이션을 실행하는 사용자로서 로그인 하면서 아래 명령어를 실행한다.touch directory/core
chmod또는chown명령어를 사용하여 소유권 또는 권한을 수정하거나,smitty user를 실행하여 사용자 계정의 내용을 수정한다. 사용자 계정을 수정할 경우 사용자로서의 재로그인이 필요하다. - 코어 파일을 저장할 수 있는 적절한 디스크 공간이 있는지를 확인하라. 코어 파일은 메모리에 있는 프로세스의 크기만 하다.
ps명령어 아웃풋의 RSS(프로세스 크기) 필드는 코어 파일에 대한 대략적인 크기를 제공한다. 예를 들어,ps avwwg java_pid
추가 공간이 필요하면, 필요 없는 파일이나 오래된 파일을 삭제하여 공간을 만들거나, 대상 파일 시스템의 크기를 늘린다.
- AIX 명령어 또는 유틸리티는 정보를 모으는데 사용될 수 있다. 다음의 AIX 파일 세트들이 반드시 설치되어야 한다.
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을 사용하여 최신 레벨로 업그레이드 되어야 한다.
Javacore versus AIX core에서 설명한 대로, Javacore 파일들이 언제나 행 상황을 디버깅 하는 최상의 툴은 아니다. 바이너리 AIX core 파일이 더 유용한 정보를 제공할 수도 있다. 좋은 AIX core 파일을 얻으려면, 프로세스로 보내진 신호를 받을 때 Javacore를 생성하지 않도록 JVM을 설정해야 한다. 다음과 같은 변경 사항들이 애플리케이션이 시작되기 전에, 애플리케이션을 실행하는 환경에서 이루어져야 한다.
시그널 핸들러가 작동되면, 프로세스는 시그널 핸들링의 "현재" 상태를 나타낸다. 이것은 실제 문제를 숨긴다. 애플리케이션이 SIGILL, SIGFPE, SIGBUS, SIGSEGV를 핸들하는 시그널 핸들러를 갖고 있다면, 그러한 시그널 핸들러는 작동되지 않도록 해야 한다. 애플리케이션이 시작되기 전에, 애플리케이션을 실행하는 환경에서 변경을 해야 한다.
WebSphere® 같은 또 다른 프로세스에 의해 애플리케이션이 시작되는 상황에서, 이러한 환경을 설정하면 모든 자바 프로세스에 영향을 미칠 수 있다. 그러한 경우에, 해당 애플리케이션 전용의 환경 설정을 다룬 애플리케이션 문서를 참조해야 한다.
- JVM 시그널 핸들링을 실행 불가로 하기.
이러한 환경 변수들은 애플리케이션이 재시작 되기 전에 설정되어야 한다.
export DISABLE_JAVADUMP=true export IBM_NOSIGHANDLER=true
변경 사항이 적용되려면 애플리케이션이 재시작 되어야 한다. 이렇게 하면
kill -3를 실행할 때나 다른 시그널이 발생해서 프로세스가 종료되도록 할 때 Javacore와 heapdump 파일이 생성되는 것을 방지한다. - 애플리케이션 시그널 핸들링을 실행 불가로 하기.
애플리케이션이 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 파일에 추가하는 것은 좋지 않다. 애플리케이션 시작 및 구성 스크립트는 다른 모든 것을 오버라이트(overwrite)한다.
문제 상황이 발생하면, 문제의 원인을 규명할 수 있는 충분한 정보를 모으거나, 원인을 이해할 수 있는 방향을 제시해야 한다. 문제는 OS(커널/라이브러리), JVM(또는 JIT), 애플리케이션 Java Native Interface (JNI) 네이티브 코드, 서드 파티 JNI 코드 등이 될 수 있다. 이 섹션에서는 각 영역에서 데이터를 모으는 명령어들을 소개하겠다. 대부분의 명령어들은 루트 유저로서 실행되어야 한다.
OS 설정 모으기:
- 코어가 생성된 후에, 다음 명령어를 실행한다.
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 -
자바 빌드가 Java 142 SR5 이거나 SR 5 for Java 142 보다 새로운 빌드라면, javaLibsGrabber.sh 대신 snapcore를 사용하여 라이브러리들을 모을 수 있다.
snapcore -d save_directory core.001 fullpath_executable
예를 들어,
snapcore -d /tmp/savedir core.001 /usr/java14/jre/bin/java
이것은 /tmp/savedir 디렉토리에 압축 파일(snapcore_pid.pax.Z)을 만든다.
아래 세 단계를 거쳐 데이터를 패키징 하여 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 서버로 보내진다. AIX 지원팀에서 제때에 응답을 받으려면, 아래 지시를 따라야 한다. testcase 서버로 연결하거나 데이터를 보내는데 문제가 있다면, 네트워크의 방화벽과 프록시 설정을 체크해 보라.
ftp testcase.boulder.ibm.com login: anonymous password: user@host.com > cd /aix/toibm > bin > put xxxxx.byyy.czzz.#.tar > quit
IBM 지원팀 핫라인에 이메일 또는 전화하여 xxxxx.byyy.czzz에 대한 PMR 넘버를 획득해야 한다.
교육
-
IBM developer kits for AIX, Java technology edition
-
IBM JVM Diagnostic Guides
-
AIX documentation library
-
developerWorks 기술 이벤트와 웹캐스트
-
AIX and UNIX: AIX와 UNIX 애플리케이션 개발과 시스템 관리 방법에 대해 설명한다. 기술자료, 튜토리얼, 팁, 다운로드, 툴을 제공한다.
토론
-
developerWorks 블로그와 developerWorks 커뮤니티 참여하기.