웹 모듈 또는 애플리케이션 서버가 요청 처리 중지
애플리케이션 서버의 프로세스가 임의로 닫히거나 해당 웹 모듈이 새 요청에 대한 응답을 중지시키는 경우, 이러한 중지가 발생하는 이유를 신속하게 판별해야 합니다. 다음 기술을 사용하여 이러한 문제점이 웹 모듈 문제점인지 또는 애플리케이션 서버 환경 문제점인지 여부를 판별할 수 있습니다.
애플리케이션 서버의 프로세스가 임의로 닫히거나 애플리케이션 서버에서 실행 중인 웹 모듈이
새 요청에 대한 응답을 중지시키는 경우:
- 가능한 경우, 다른 서버에 웹 모듈을 설치하여 문제점을 분리하십시오.
제품 디렉토리 구조에서 javacore[number].txt 같은 이름의 파일을 확인하십시오. 이 파일은 Java™ 스레드 덤프 파일로서 애플리케이션 서버 프로세스가 임의로 닫히는 경우 JVM에서 작성하는 파일입니다.
애플리케이션 서버의 프로세스가 임의로 닫히는 경우에는 SDUMP를 분석해야 합니다.
- Tivoli® Performance Viewer를
사용하여 Java 힙과 같은 애플리케이션 서버 자원이나 데이터베이스 연결이 최대 용량에 도달했는지 확인하십시오. 자원 문제점이 있는 경우에는 애플리케이션 코드를 검토하여 가능한 원인을 확인하십시오.
- 데이터베이스 연결이 요청에 지정되었으나 요청이 처리를 완료할 때 해제되지 않을 경우, 애플리케이션 코드가 finally{} 블록 내의 열려 있는 모든 Connection 오브젝트에 대한 close()를 수행하는지 확인하십시오.
- 사용 중인 서블릿 엔진 스레드가 일정하게 증가하는 경우, 가능한 교착 상태 조건에 대해 애플리케이션 동기화 코드 블록을 검토하십시오.
- JVM 힙 크기가 일정하게 증가하는 경우, 오브젝트가 절대로 가비지 콜렉트되지 않게 만들 수 있는 메모리 누출 가능성(예: 정적(클래스 레벨) 콜렉션)에 대해 애플리케이션 코드를 검토하십시오.
- 애플리케이션 서버에서 자세한 가비지 콜렉션을 사용 가능하게 하여
메모리 누수 문제점이 있는지 판별하십시오. 이 기능은 사용 가능한 메모리 양과
사용 중인 메모리 양에 대한 자세한 내용을 JVM 오류 로그 파일에 추가합니다. 자세한 가비지 콜렉션을 사용 가능으로 설정하려면 다음을 수행하십시오.
관리 콘솔에서 server_name을 클릭하십시오. 그러면 서버 인프라에서 을 클릭한 후 상세 가비지 콜렉션을 선택하십시오.
관리 콘솔에서 server_name을 클릭하십시오. 그런 다음 서버 인프라 섹션에서 을 클릭한 후 상세 가비지 콜렉션을 선택하십시오.
- 애플리케이션 서버를 중지했다가 다시 시작하십시오.
- 주기적으로 가비지 콜렉션 내용에 대해 로그 파일을 찾아보십시오. "allocation failure"로 시작하는 문장을 찾으십시오. 이 문자열은 메모리 할당을 위한 필요성이 JVM 가비지 콜렉션을 트리거하여 사용하지 않은 메모리를 해제했음을 표시합니다. 할당 실패는 정상적이며 문제점을 표시하는 데 필요하지 않습니다. 할당 실패 문장 뒤에 필요한 바이트 수와 할당된 바이트 수를 표시하는 문장이 표시됩니다. 필요한 이 바이트 수 문장에 JVM이 사용하기 위해 추가 메모리를 계속 할당하거나 JVM이 필요한 만큼 메모리를 할당할 수 없음이 표시되는 경우, 메모리 누출이 있을 수 있습니다.
또한 Tivoli Performance Viewer를 사용하여 메모리 누수 문제점을 발견할 수 있습니다.
애플리케이션 서버 메모리가 부족한지 여부를 판별하십시오. 애플리케이션 서버 메모리가 부족한 것을 판별하는 경우 다음 상황 중 하나가 발생할 수 있습니다.
- 사용자가 주소지정해야 하는 애플리케이션
코드에서 메모리 누출이 있습니다. 메모리 누수의 원인을 정확하게 파악하려면, 관리 콘솔의
JVM(Java Virtual Machine) 페이지에서 RunHProf 특성을 사용 가능하게 하십시오. server_name은
문제 애플리케이션 서버의 이름입니다. RunHProf 특성을 사용으로
설정한 후에는 다음을 수행해야 합니다.
- HProf 인수 필드를 depth=20,file=heapdmp.txt와 유사한 값으로 설정하십시오. 이 값은 최대 20 레벨까지 예외 스택을 표시하고, heapdump 출력을 app_server_root/bin/heapdmp.txt 파일에 저장합니다.
- 설정을 저장하십시오.
- 애플리케이션 서버를 중지했다가 다시 시작하십시오.
- 가능한 경우, 시나리오를 재현하거나 애플리케이션 서버 프로세스를 임의로 닫히게 하거나 해당 웹 모듈이 새 요청에 응답하는 것을 중지시킨 자원에 액세스하십시오. 그런 다음, 애플리케이션 서버를 중지하십시오. 시나리오를 재현하거나 자원에 액세스할 수 없는 경우 문제점이 재발할 때까지 기다린 후 애플리케이션 서버를 중지하십시오.
- 힙 덤프가 저장된 파일을 검사하십시오. 예를 들어,
app_server_root/bin/heapdmp.txt 파일을 조사하십시오.
- 문자열 "SITES BEGIN"을 검색하십시오. 이 검색은 메모리에서 Java 오브젝트 목록의 위치를 찾으며, 이것이 오브젝트에 할당된 메모리 양을 표시합니다.
- Java 오브젝트 목록은 JVM에서 메모리 할당이 있을 때마다 발생합니다. 메모리가 인스턴스화한 오브젝트의 유형과 할당을 수행한 Java 메소드를 표시하며 덤프 어딘가에 나열되는 추적 스택의 ID 레코드가 있습니다.
- Java 오브젝트 목록은 할당된 바이트 수에 따른 내림차순입니다. 누출 특성에 따라 문제점 클래스가 목록 처음 근처를 표시해야 하지만, 이것이 항상 해당하는 것은 아닙니다. 많은 양의 메모리 또는 인스턴스화되는 동일한 클래스의 빈번한 인스턴스가 있는 목록을 철저히 조사하십시오. 후자의 경우에 추적 스택 열의 ID를 사용하여 동일한 클래스 및 메소드에서 반복적으로 발생하는 할당을 식별하십시오.
- 메모리 누출 가능성에 대해 관련 추적 스택에 표시된 소스 코드를 검사하십시오.
- JVM에서 허용되는 최대 힙 크기를 사용 중입니다. 여기서는 사용 가능한 저장영역이 충분한 경우 애플리케이션 서버에 대한 최대 힙 크기 설정을 늘려야 합니다.
- 서버 런타임에 문제점이 있습니다. 서버 런타임에 문제점이 있는지 판별하려면 먼저 해당 제품에 대한 모든 서비스 업데이트를 적용했는지 확인하십시오. 모든 서비스 업데이트를 적용한 후에도 문제점이 지속되면 IBM® Support에 문의하십시오.
- 사용자가 주소지정해야 하는 애플리케이션
코드에서 메모리 누출이 있습니다. 메모리 누수의 원인을 정확하게 파악하려면, 관리 콘솔의
JVM(Java Virtual Machine) 페이지에서 RunHProf 특성을 사용 가능하게 하십시오. server_name은
문제 애플리케이션 서버의 이름입니다. RunHProf 특성을 사용으로
설정한 후에는 다음을 수행해야 합니다.
단서가 있는지 스레드 덤프를 찾아보십시오.
JVM에서는 애플리케이션 서버 프로세스가 임의로 닫힐 때마다 스레드 덤프를 작성합니다. 애플리케이션이 스레드 덤프를 작성하게 할 수 있습니다. 덤프가 작성되면 이를 확인하여 새 요청이 처리되지 않는 이유에 대한 단서를 찾으십시오.
스레드 덤프를 강제 실행하려면 다음을 수행하십시오.
- wsadmin 명령 프롬프트를 사용하여 문제 애플리케이션 서버에 대한 핸들을
확보하십시오.
wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=server_name,*]
여기서, server_name은 서버의 이름입니다.
- 스레드 덤프를 생성하십시오.
wsadmin>$AdminControl invoke $jvm dumpThreads
참고: dumpThreads 명령은 -Xdumps 설정에 따라 다른 유형의 덤프 파일을 작성합니다. 덤프 출력은 플랫폼에 따라 다양하며 시스템 코어 파일, 힙, 스냅 덤프를 포함할 수 있습니다. profile_root/logs 디렉토리에서 javacore.jobnum.jobuser.jobname.timestamp.txt와 유사한 이름을 갖는 출력 파일을 찾으십시오.
제품의 설치 루트 디렉토리에서 javacore.date.time.id.txt와 유사한 이름의 출력 파일을 찾으십시오.
애플리케이션에서 덤프를 작성한 후에는 다음 단서를 확인할 수 있습니다.
파일 시작 부분에 있는 "Error" 또는 "exception information" 문자열. 이들 문자열은 애플리케이션 서버 프로세스가 자동적으로 중지하도록 한 스레드를 표시합니다. 덤프를 강제 실행한 경우에는 이러한 문제점이 표시되지 않습니다.
현재 힙 크기가 지나치게 큰지 확인하십시오. 스레드 덤프는 현재 Java 힙 크기에 대한 정보와 최소 및 최대 힙 크기 설정을 보여줍니다.
프로세스 내 각 스레드의 스냅샷을 보십시오. 스레드 덤프에는 "전체 스레드 덤프" 섹션에서 시작하는 프로세스 내 각 스레드의 스냅샷이 포함되어 있습니다.
- 설명에 "state:R"이 포함된 스레드를 찾으십시오. 이런 스레드는 덤프가 강제 실행될 때 또는 프로세스가 종료할 때 활성이고 실행 중입니다.
- 동일한 Java 애플리케이션 코드 소스 위치에서 다중 스레드를 찾으십시오. 동일한 위치의 다중 스레드는 교착 상태 조건(다중 스레드가 모니터를 대기 중) 또는 무한 루프를 표시할 수 있으며, 문제가 있는 애플리케이션 코드를 식별하는 데 도움이 됩니다.
프로세스 내 각 스레드의 스냅샷을 보십시오. 스레드 덤프에는 "스레드 정보" 섹션에서 시작하는 프로세스 내 각 스레드의 스냅샷이 포함되어 있습니다.
- 다른 스레드가 보유하는 잠금에서 대기 중인 스레드를 찾아보십시오.
- 동일한 Java 애플리케이션 코드 소스 위치에서 다중 스레드를 찾으십시오.
동일한 위치의 다중 스레드는 교착 상태 조건(다중 스레드가 모니터를
대기 중) 또는 무한 루프를 표시할 수 있으며, 문제가 있는 애플리케이션 코드를
식별하는 데 도움이 됩니다.
제품 런타임의 특정 컴포넌트가 동일한 Java 코드 소스 위치에 특정 유형의 스레드를 가지고 있는 것은 정상입니다. 이러한 컴포넌트에는 웹 컨테이너, EJB 컨테이너 및 ORB 스레드 풀이 포함됩니다.
- wsadmin 명령 프롬프트를 사용하여 문제 애플리케이션 서버에 대한 핸들을
확보하십시오.
IBM 지원에는 문제점 해결에 필요한
정보를 수집하는 시간을 줄일 수 있는 문서와 도구가 있습니다. 문제점 보고서를
열기 전에 다음 지원 페이지를 참조하십시오.