이 장에서는 다음과 같은 문제를 이해하고 해결하는 방법을 설명합니다.
문제가 발생할 경우 설치된 Message QueueTM 소프트웨어의 버전 번호를 확인하는 것이 좋습니다. 버전 번호를 사용하여 사용 중인 설명서 버전이 소프트웨어 버전과 일치하는 지 확인합니다. 문제를 Sun에 보고할 때도 버전 번호가 필요합니다. 버전 번호를 확인하려면 다음 명령을 실행합니다.
imqcmd -v
증상:
클라이언트가 새 연결을 설정할 수 없습니다.
클라이언트가 실패한 연결을 자동으로 다시 연결할 수 없습니다.
가능한 원인:
가능한 원인: 클라이언트 응용 프로그램이 연결을 닫을 수 없어 연결 수가 자원 제한을 초과합니다.
문제의 원인을 확인하는 방법: 브로커에 대한 연결을 모두 나열합니다.
imqcmd list cxn
출력에 모든 연결과 각 연결이 설정된 호스트가 나열되고 특정 클라이언트에 비정상적인 수의 연결이 열려 있는 것으로 표시됩니다.
문제를 해결하는 방법: 문제가 있는 클라이언트를 다시 작성하여 사용되지 않는 연결을 닫습니다.
가능한 원인: 브로커가 실행 중이지 않거나 네트워크 연결에 문제가 있습니다.
문제의 원인을 확인하는 방법:
브로커의 기본 포트(예: 기본값 7676)로 텔넷하고 브로커가 포트 매퍼 출력으로 응답하는지 확인합니다.
브로커 프로세스가 호스트에서 실행 중인지 확인합니다.
문제를 해결하는 방법:
브로커를 시작합니다.
네트워크 연결 문제를 해결합니다.
가능한 원인: 연결 서비스가 비활성 상태이거나 일시 중지되어 있습니다.
문제의 원인을 확인하는 방법: 모든 연결 서비스의 상태를 확인합니다.
imqcmd list svc
연결 서비스 상태가 unknown 또는 paused로 표시되어 있는 경우 클라이언트가 해당 서비스를 사용하여 연결을 설정할 수 없습니다.
문제를 해결하는 방법:
연결 서비스의 상태가 unknown으로 표시되어 있는 경우 해당 연결 서비스가 활성 서비스 목록(imq.service.active)에 없는 것입니다. SSL 기반 서비스의 경우 서비스가 잘못 구성되어 있을 수도 있습니다. 이로 인해 브로커가 브로커 로그에 다음과 같은 항목과
ERROR [B3009]: Unable to start service ssljms: [B4001]: Unable to open protocol tls for ssljms service...
이 예외의 근본 원인에 대한 설명을 포함시키게 됩니다.
SSL 서비스를 올바르게 구성하려면 메시지 암호화를 참조하십시오.
연결 서비스의 상태가 paused로 표시되어 있는 경우 서비스를 다시 시작합니다( 연결 서비스 일시 중지 및 다시 시작 참조).
가능한 원인: 필요한 연결 수에 비해 사용 가능한 스레드 수가 너무 적습니다.
문제의 원인을 확인하는 방법: 브로커 로그에서 다음 항목이 있는지 확인합니다.
WARNING [B3004]: No threads are available to process a new connection on service ... Closing the new connection.
또한 다음 형식 중 하나를 사용하여 연결 서비스의 연결 수와 현재 사용 중인 스레드 수를 확인합니다.
imqcmd query svc -n serviceName imqcmd metrics svc -n serviceName -m cxn
각 연결에는 받는 메시지와 보내는 메시지에 하나씩 두 개의 스레드가 필요합니다( 스레드 풀 관리 참조).
문제를 해결하는 방법:
전용 스레드 풀 모델을 사용하고 있는 경우(imq. serviceName.threadpool_model= dedicated) 최대 연결 수는 스레드 풀의 최대 스레드 수의 반입니다. 따라서 연결 수를 늘리려면 스레드 풀의 크기를 늘리거나(imq. serviceName.max_threads) 공유 스레드 풀 모델로 전환합니다.
공유 스레드 풀 모델을 사용하고 있는 경우(imq. serviceName.threadpool_model=shared) 최대 연결 수는 연결 모니터 제한(imq.serviceName.connectionMonitor_limit )과 최대 스레드 수(imq. serviceName.max_threads)를 곱한 수의 반입니다. 따라서 연결 수를 늘리려면 스레드 풀의 크기를 늘리거나 연결 모니터 제한을 늘립니다.
결국 지원 가능한 연결 수(또는 연결의 처리량)는 입출력 제한에 도달합니다. 그런 경우 다중 브로커 클러스터를 사용하여 클러스터 내의 브로커 인스턴스로 연결을 분산합니다.
가능한 원인: Solaris나 Linux 플랫폼에서 필요한 연결 수에 비해 파일 설명자가 너무 적습니다.
이 문제에 대한 자세한 내용은 파일 설명자 제한 설정을 참조하십시오.
문제의 원인을 확인하는 방법: 브로커 로그에 다음과 유사한 항목이 있는지 확인합니다.
Too many open files
문제를 해결하는 방법: ulimit 설명서 페이지에 설명한 대로 파일 설명자 제한을 늘립니다.
가능한 원인: TCP 백로그가 동시에 설정할 수 있는 새 연결 요청 수를 제한합니다.
TCP 백로그는 포트 매퍼가 추가 요청을 거부하기 전에 시스템 백로그(imq.portmapper.backlog)에 저장할 수 있는 동시 연결 요청 수를 제한합니다(Windows 플랫폼의 경우 하드 코드된 백로그 제한이 있으며 Windows 데스크탑의 경우 5이고 Windows 서버의 경우 200임).
백로그 제한으로 인한 요청 거부는 비정상적으로 많은 동시 연결 요청 수로 인해 발생하는 일시적인 현상입니다.
문제의 원인을 확인하는 방법: 브로커 로그를 검사합니다. 먼저, 브로커가 특정 기간 동안 일부 연결은 수신하고 다른 일부 연결은 거부하는지 여부를 확인합니다. 그런 다음, 거부된 연결을 설명하는 메시지를 확인합니다. 그러한 메시지가 있다면 브로커는 TCP 백로그로 인한 연결 거부를 기록하지 않으므로 TCP 백로그 문제가 아닐 수 있습니다. 일부 성공적인 연결이 기록되어 있고 연결 거부는 기록되어 있지 않은 경우 TCP 백로그에 문제가 있을 수 있습니다.
문제를 해결하는 방법:
클라이언트가 시도했던 연결을 잠시 후에 다시 시도하도록 프로그래밍합니다(이 문제가 본래 임시적이기 때문에 이렇게 하면 대개 제대로 작동됨).
imq.portmapper.backlog 값을 늘립니다.
클라이언트가 너무 자주 연결을 닫은 다음 열고 있지는 않은지 확인합니다.
가능한 원인: 운영 체제가 동시 연결 수를 제한합니다.
Windows 운영 체제 사용권에서는 지원되는 동시 원격 연결 수를 제한합니다.
문제의 원인을 확인하는 방법: 연결에 사용할 수 있는 스레드가 충분한지 확인하고(imqcmd query svc 사용) Windows 사용권 계약 조항을 확인합니다. 로컬 클라이언트에서는 연결할 수 있지만 원격 클라이언트에서는 연결할 수 없는 경우 운영 체제 제한이 문제의 원인일 수 있습니다.
문제를 해결하는 방법:
더 많은 연결을 허용하도록 Windows 사용권을 업그레이드합니다.
다중 브로커 클러스터를 설정하여 연결을 여러 브로커 인스턴스에 분산합니다.
가능한 원인: 사용자의 인증 또는 권한 부여가 실패합니다.
다음과 같은 이유로 인해 인증이 실패할 수 있습니다.
잘못된 비밀번호
사용자 저장소에 사용자 항목 없음
사용자에게 연결 서비스에 대한 액세스 권한이 없음
문제의 원인을 확인하는 방법: 브로커 로그의 항목에 Forbidden 오류 메시지가 있는지 확인합니다. 이 메시지는 인증 오류를 나타낼 뿐 그 원인은 나타내지 않습니다.
파일 기반 사용자 저장소를 사용하는 경우 다음 명령을 입력합니다.
imqusermgr list -i instanceName -u userName
출력에 사용자가 표시되는 경우 잘못된 비밀번호가 제출된 것일 수 있습니다. 출력에 다음과 같은 오류가 표시되는 경우 사용자 저장소에 사용자 항목이 없는 것입니다.
Error [B3048]: User does not exist in the password file
LDAP 서버 사용자 저장소를 사용 중인 경우 적절한 도구를 사용하여 사용자 항목이 있는지 확인합니다.
액세스 제어 등록 정보 파일에 연결 서비스 액세스에 대한 제한이 있는지 확인합니다.
문제를 해결하는 방법:
잘못된 비밀번호가 사용된 경우 올바른 비밀번호를 제공합니다.
사용자 저장소에 사용자 항목이 없는 경우 사용자를 추가합니다( 사용자 저장소 채우기 및 관리 참조).
사용자가 연결 서비스에 대한 액세스 권한이 없는 경우 해당 권한을 허용하도록 액세스 제어 등록 정보 파일을 편집합니다( 연결 서비스에 대한 액세스 제어 참고).
증상:
메시지 처리량이 기대에 미치지 못합니다.
브로커에 대해 지원되는 연결 수가 클라이언트가 연결을 설정할 수 없음에 설명된 대로 제한되는 것이 아니라 메시지 입출력 속도에 의해 제한됩니다.
가능한 원인:
가능한 원인: 네트워크 연결 또는 WAN이 너무 느립니다.
문제의 원인을 확인하는 방법:
네트워크를 핑하여 핑이 반환되는 데 걸리는 시간을 확인한 다음 네트워크 관리자에게 문의합니다.
로컬 클라이언트를 사용하여 메시지를 보내고 받은 다음 이 전달 시간을 네트워크 링크를 사용하는 원격 클라이언트의 전달 시간과 비교할 수 있습니다.
문제를 해결하는 방법: 네트워크 링크를 업그레이드합니다.
가능한 원인: 연결 서비스 프로토콜이 기본적으로 TCP에 비해 느립니다.
예를 들어 SSL 기반 또는 HTTP 기반 프로토콜이 TCP보다 느립니다( 전송 프로토콜 참조).
문제의 원인을 확인하는 방법: SSL 기반 또는 HTTP 기반 프로토콜을 사용하는 경우 TCP를 사용해보고 전달 시간을 비교합니다.
문제를 해결하는 방법: 일반적으로 응용 프로그램 요구 사항에 따라 사용되는 프로토콜이 지정되므로 전송 프로토콜 조정에 설명된 대로 프로토콜을 조정해보는 것 이외에 할 수 있는 작업이 거의 없습니다.
가능한 원인: 연결 서비스 프로토콜이 최적으로 조정되어 있지 않습니다.
문제의 원인을 확인하는 방법: 프로토콜을 조정하여 어떻게 달라지는지 확인합니다.
문제를 해결하는 방법: 전송 프로토콜 조정에 설명된 대로 프로토콜을 조정합니다.
가능한 원인: 메시지가 너무 커서 너무 많은 대역폭을 사용합니다.
문제의 원인을 확인하는 방법: 작은 크기의 메시지를 사용하여 벤치마크를 실행해 봅니다.
문제를 해결하는 방법:
응용 프로그램 개발자에게 응용 프로그램을 수정하여 메시지 압축 기능을 사용하게 합니다. 이 방법에 대해서는 Java 클라이언트용 Message Queue 개발 안내서에 설명되어 있습니다.
메시지를 보낼 데이터의 알림으로 사용하고 데이터는 다른 프로토콜을 사용하여 이동합니다.
가능한 원인: 연결 처리량이 느린 것처럼 보이는 것은 실제로는 메시지 전달 프로세스의 어떤 단계에 병목 현상이 있는 것입니다.
문제의 원인을 확인하는 방법: 위의 원인 중 어떤 것으로도 느린 연결 처리량에 대해 설명할 수 없는 경우 성능에 영향을 미치는 요소를 참조하여 다른 병목 현상이 있을 수 있는지 확인하고 다음 문제와 관련된 증상이 있는지 확인합니다.
문제를 해결하는 방법: 위에 나열된 문제 해결 절에 제공되어 있는 문제 해결 지침을 따릅니다.
증상:
물리적 대상에 대해 메시지 생성자를 만들 수 없기 때문에 클라이언트에서 예외가 발생합니다.
가능한 원인:
가능한 원인: 물리적 대상이 제한된 생성자 수만 허용하도록 구성되었습니다.
물리적 대상에 메시지가 누적되는 것을 방지하는 방법 중 하나는 물리적 대상에서 지원할 수 있는 생성자의 수(maxNumProducers)를 제한하는 것입니다.
문제의 원인을 확인하는 방법: 물리적 대상을 확인합니다.
imqcmd query dst
( 물리적 대상 정보 표시 참조). 출력에 현재 생성자 수와 maxNumProducers 값이 표시됩니다. 두 값이 같은 경우 생성자의 수가 구성된 제한에 도달한 것입니다. 브로커가 새 생성자를 거부할 때 다음과 같은 예외를 반환하고
ResourceAllocationException [C4088]: A JMS destination limit was reached
브로커 로그에 다음 항목을 생성합니다.
[B4183]: Producer can not be added to destination
문제를 해결하는 방법:maxNumProducers 속성 값을 늘립니다( 물리적 대상 등록 정보 업데이트 참조).
가능한 원인: 액세스 제어 등록 정보 파일의 설정으로 인해 사용자가 메시지 생성자를 만들 수 있는 권한이 없습니다.
문제의 원인을 확인하는 방법: 브로커가 새 생성자를 거부할 때 다음과 같은 예외를 반환하고
JMSSecurityException [C4076]: Client does not have permission to create producer on destination
브로커 로그에 다음 항목을 생성합니다.
[B2041]: Producer on destination denied[B4051]: Forbidden guest.
문제를 해결하는 방법: 사용자가 메시지를 생성할 수 있도록 액세스 제어 등록 정보를 변경합니다( 물리적 대상에 대한 액세스 제어 참조).
증상:
지속성 메시지를 보낼 때 send 메소드가 반환되지 않고 클라이언트가 차단됩니다.
지속성 메시지를 보낼 때 클라이언트에 예외가 발생합니다.
생성자 클라이언트가 느려집니다.
가능한 원인:
가능한 원인: 브로커가 백로그되고 느린 메시지 생성자로 응답했습니다.
백로그된 브로커가 브로커 메모리에 메시지를 누적시킵니다. 물리적 대상 메모리의 메시지 수와 메시지 바이트 수가 구성된 제한에 도달하면 브로커가 지정된 제한 동작에 따라 메모리 자원을 절약하려고 합니다. 다음 제한 동작은 메시지 생성자를 느리게 만듭니다.
FLOW_CONTROL: 브로커가 지속성 메시지의 수신을 바로 확인하지 않습니다. 따라서 생성자 클라이언트가 차단됩니다.
REJECT_NEWEST: 브로커가 새 지속성 메시지를 거부합니다.
마찬가지로 모든 물리적 대상의 브로커 전체 메모리에서 메시지 수나 메시지 바이트 수가 구성된 제한에 도달하면 브로커가 최신 메시지를 거부하여 메모리 자원을 절약하려고 합니다. 또한 물리적 대상이나 브로커 전체 제한이 제대로 설정되어 있지 않아 시스템 메모리 제한에 도달하면 브로커는 메모리 과부하를 막기 위해 점점 더 중대한 조치를 취합니다. 이러한 조치로는 메시지 생성자 억제가 있습니다.
문제의 원인을 확인하는 방법: 구성된 메시지 제한으로 인해 브로커가 메시지를 거부할 경우 브로커는 다음과 같은 예외를 반환합니다.
JMSException [C4036]: A server error occurred
브로커 로그에 다음 항목을 생성합니다.
[B2011]: Storing of JMS message from IMQconn failed
이 메시지 다음에는 제한에 도달했음을 나타내는 메시지가 표시됩니다.
[B4120]: Cannot store message on destination destName because capacity of maxNumMsgs would be exceeded.
이는 초과된 메시지 제한이 물리적 대상에 있거나
[B4024]: The maximum number of messages currrently in the system has been exceeded, rejecting message.
제한이 브로커 전체에 해당되는 경우에 표시됩니다.
좀 더 일반적으로 다음과 같은 방법으로 거부가 발생하기 전에 메시지 제한 조건을 확인할 수 있습니다.
물리적 대상과 브로커를 쿼리하여 각각에 구성된 메시지 제한 설정을 검사합니다.
적절한 imqcmd 명령을 사용하여 물리적 대상이나 브로커 전체에서 현재 메시지 수나 메시지 바이트 수를 모니터합니다. 모니터할 수 있는 메트릭 및 해당 메트릭을 가져오는 데 사용하는 명령에 대한 자세한 내용은 18 장, 메트릭 참조을 참조하십시오.
문제를 해결하는 방법:
메모리 자원을 초과하지 않도록 주의하면서 물리적 대상 또는 브로커 전체에 대한 메시지 제한을 수정합니다.
일반적으로는 브로커 전체 메시지 제한에 도달하는 일이 없도록 개별 대상 단위로 메모리를 관리해야 합니다. 자세한 내용은 브로커 조정을 참조하십시오.
메시지 제한에 도달하면 메시지 생성을 느리게 하기보다 메모리에서 메시지를 버리도록 대상의 제한 동작을 변경합니다.
예를 들어, 메모리에 누적되는 메시지를 삭제하는 REMOVE_OLDEST 및 REMOVE_LOW_PRIORITY 제한 동작을 지정할 수 있습니다(표 15–1 참조).
가능한 원인: 브로커가 지속성 메시지를 데이터 저장소에 저장할 수 없습니다.
브로커가 데이터 저장소에 액세스할 수 없거나 지속성 메시지를 데이터 저장소에 기록할 수 없는 경우 생성자 클라이언트가 차단됩니다. 위에 설명되어 있는 대상 또는 브로커 전체 메시지 제한에 도달한 경우에도 이러한 상태가 발생할 수 있습니다.
문제의 원인을 확인하는 방법: 브로커가 데이터 저장소에 기록할 수 없는 경우 브로커는 브로커 로그에 다음 항목 중 하나를 만듭니다.
[B2011]: Storing of JMS message from connectionID failed [B4004]: Failed to persist message messageID
문제를 해결하는 방법:
파일 기반 지속성의 경우 파일 기반 데이터 저장소의 디스크 공간을 늘립니다.
JDBC 호환 데이터 저장소의 경우 JDBC 기반 지속성이 제대로 구성되어 있는지 확인합니다( 영구 데이터 저장소 구성 참조). 제대로 구성되어 있는 경우 데이터베이스 관리자에게 문의하여 다른 데이터베이스 문제를 해결합니다.
가능한 원인: 브로커 확인 시간 제한이 너무 짧습니다.
느린 연결 또는 CPU 사용률이 높거나 메모리 자원이 부족하여 무기력해진 메시지 서버로 인해 브로커가 지속성 메시지의 수신을 확인하는 데 연결 팩토리의 imqAckTimeout 속성 값에서 허용하는 것보다 더 많은 시간이 필요할 수 있습니다.
문제의 원인을 확인하는 방법: imqAckTimeout 값이 초과되면 브로커가 예외를 반환합니다.
JMSException [C4000]: Packet acknowledge failed
문제를 해결하는 방법: imqAckTimeout 연결 팩토리 속성 값을 변경합니다( 안정성 및 흐름 제어 참조).
가능한 원인: 생성자 클라이언트에서 JVM 제한이 발생했습니다.
문제의 원인을 확인하는 방법:
클라이언트 응용 프로그램이 메모리 부족 오류를 수신하는지 확인합니다.
freeMemory, maxMemory 및 totalMemory와 같은 런타임 메서드를 사용하여 JVM 힙에서 사용 가능한 메모리를 확인합니다.
문제를 해결하는 방법: JVM을 조정합니다( Java 가상 머신 조정 참조).
증상:
메시지 생성이 지연되거나 생성된 메시지가 브로커에서 거부됩니다.
메시지가 사용자에게 도달하기까지 비정상적으로 오래 걸립니다.
브로커 또는 특정 대상의 메시지나 메시지 바이트 수가 시간에 따라 꾸준하게 증가합니다.
메시지가 누적되고 있는지 확인하려면 브로커의 메시지나 메시지 바이트 수가 시간에 따라 어떻게 변하는지 확인하고 구성된 제한과 비교합니다. 먼저 구성된 제한을 확인합니다.
imqcmd query bkr
imqcmd metrics bkr 하위 명령은 이 정보를 표시하지 않습니다.
그런 다음 각 대상에서 메시지 누적을 확인합니다.
imqcmd list dst
메시지가 대상이나 브로커 전체에 구성된 제한을 초과했는지 확인하려면 브로커 로그에서 다음 항목을 확인합니다.
[B2011]: Storing of JMS message from … failed.
이 항목 다음에는 초과된 제한에 대해 설명하는 다른 항목이 표시됩니다.
가능한 원인:
가능한 원인: 주제 대상에 비활성 영구 가입이 있습니다.
영구 가입이 비활성 상태인 경우 해당 사용자가 활성화되어 메시지를 사용할 수 있을 때까지 대상에 메시지가 저장됩니다.
문제의 원인을 확인하는 방법: 각 주제 대상에서 영구 가입 상태를 확인합니다.
imqcmd list dur -d destName
문제를 해결하는 방법:
문제가 있는 영구 가입의 모든 메시지를 제거합니다( 영구 가입 관리 참조).
주제에 대해 메시지 제한 및 제한 동작 속성을 지정합니다(표 15–1 참조). 예를 들어, 메모리에 누적되는 메시지를 삭제하는 REMOVE_OLDEST 및 REMOVE_LOW_PRIORITY 제한 동작을 지정할 수 있습니다.
해당 대상에서 모든 메시지를 제거합니다( 물리적 대상 제거 참조).
생성자 클라이언트를 다시 작성하여 각 메시지의 수명 값을 설정함으로써 메시지가 메모리에 남아 있을 수 있는 시간을 제한합니다. imqOverrideJMSExpiration 및 imqJMSExpiration 연결 팩토리 속성을 설정하여 연결을 공유하는 모든 생성자에 대해 이러한 설정을 대체할 수 있습니다( 메시지 헤더 대체 참조).
가능한 원인: 대기열에서 메시지를 사용할 수 있는 사용자 수가 너무 적습니다.
메시지를 전달할 수 있는 활성 사용자의 수가 너무 적은 경우 메시지가 누적될 때 대기열 대상이 백로그될 수 있습니다. 이런 상태는 다음과 같은 이유 중 하나 때문에 발생할 수 있습니다.
대상에 활성 사용자의 수가 너무 적습니다.
사용자 클라이언트가 연결을 설정하지 못했습니다.
대기열의 메시지에 일치하는 선택기를 사용하는 활성 사용자가 없습니다.
문제의 원인을 확인하는 방법: 사용자가 대기열의 메시지를 사용할 수 없는 원인을 확인하려면 대상에서 활성 사용자의 수를 확인합니다.
imqcmd metrics dst - n destName -t q -m con
문제를 해결하는 방법: 사용자가 사용할 수 없는 원인에 따라
추가 사용자 클라이언트를 시작하여 대기열에 대한 활성 사용자를 더 많이 만듭니다.
imq.consumerFlowLimit 브로커 등록 정보를 조정하여 여러 사용자에 대한 대기열 전달을 최적화합니다( 다중 사용자 대기열 성능 참조).
대기열에 대해 메시지 제한 및 제한 동작 속성을 지정합니다(표 15–1 참조). 예를 들어, 메모리에 누적되는 메시지를 삭제하는 REMOVE_OLDEST 및 REMOVE_LOW_PRIOROTY 제한 동작을 지정할 수 있습니다.
해당 대상에서 모든 메시지를 제거합니다( 물리적 대상 제거 참조).
생성자 클라이언트를 다시 작성하여 각 메시지의 수명 값을 설정함으로써 메시지가 메모리에 남아 있을 수 있는 시간을 제한합니다. imqOverrideJMSExpiration 및 imqJMSExpiration 연결 팩토리 속성을 설정하여 연결을 공유하는 모든 생성자에 대해 이러한 설정을 대체할 수 있습니다( 메시지 헤더 대체 참조).
가능한 원인: 메시지 사용자가 너무 느리게 처리하여 메시지 생성자를 따라가지 못합니다.
이 경우 주제 가입자나 대기열 수신자가 메시지를 사용하는 것이 생성자가 메시지를 보내는 것보다 느립니다. 이러한 불균형으로 인해 하나 이상의 대상이 메시지로 백로그됩니다.
문제의 원인을 확인하는 방법:메지지가 브로커에 유입 및 유출되는 속도를 확인합니다.
imqcmd metrics bkr -m rts
그런 다음 개별 대상 각각에 대한 흐름 속도를 확인합니다.
imqcmd metrics bkr -t destType -n destName - m rts
문제를 해결하는 방법:
사용자 클라이언트 코드를 최적화합니다.
대기열 대상의 경우 활성 사용자의 수를 늘립니다( 다중 사용자 대기열 성능 참조).
가능한 원인: 클라이언트 확인 처리가 메시지 사용을 느리게 합니다.
다음과 같은 두 가지 요소가 클라이언트의 확인 처리에 영향을 미칩니다.
상당한 브로커 자원이 클라이언트 확인 처리에 사용될 수 있습니다. 따라서 브로커가 클라이언트 확인을 확인할 때까지 사용자 클라이언트가 차단되는 확인 모드에서는 메시지 사용이 느려질 수 있습니다.
JMS 페이로드 메시지와 Message Queue 제어 메시지(예: 클라이언트 확인)는 같은 연결을 공유합니다. 따라서 JMS 페이로드 메시지에 의해 제어 메시지가 일시적으로 중단되어 메시지 사용이 느려질 수 있습니다.
문제의 원인을 확인하는 방법:
패킷 흐름을 기준으로 메시지 흐름을 확인합니다. 초당 패킷 수와 메시지 수의 비율이 맞지 않으면 클라이언트 확인에 문제가 있을 수 있습니다.
클라이언트가 다음과 같은 예외를 받았는지 확인합니다:
JMSException [C4000]: Packet acknowledge failed
문제를 해결하는 방법:
클라이언트가 사용하는 확인 모드를 수정합니다. 예를 들어, DUPS_OK_ACKNOWLEDGE 또는 CLIENT_ACKNOWLEDGE로 전환합니다.
CLIENT_ACKNOWLEDGE 또는 트랜잭션된 세션을 사용 중인 경우 많은 수의 메시지를 하나의 확인으로 그룹화합니다.
사용자 및 연결 흐름 제어 매개 변수를 조정합니다( 클라이언트 런타임 메시지 흐름 조정 참조).
가능한 원인: 브로커가 메시지 생성 속도를 따라갈 수 없습니다.
이 경우 브로커가 메시지를 라우팅하여 사용자에게 전달하는 것보다 더 빨리 메시지가 브로커로 유입됩니다. 브로커의 지체는 다음 중 하나 또는 모두에 대한 제한 때문일 수 있습니다.
CPU
네트워크 소켓 읽기/쓰기 작업
디스크 읽기/쓰기 작업
메모리 페이징
영구 저장소
JVM 메모리 제한
문제의 원인을 확인하는 방법: 이 문제를 일으키는 다른 원인은 없는지 확인합니다.
문제를 해결하는 방법:
컴퓨터 또는 데이터 저장소의 속도를 업그레이드합니다.
브로커 클러스터를 사용하여 로드를 여러 브로커 인스턴스에 분산합니다.
가능한 원인: 클라이언트 코드에 결함이 있습니다. 사용자가 메시지를 확인하지 않습니다.
메시지는 메시지를 받은 모든 사용자가 확인할 때까지 대상에 보관됩니다. 따라서 클라이언트가 사용된 메시지를 확인하지 않는 경우 메시지는 삭제되지 않고 대상에 누적됩니다.
예를 들어, 클라이언트 코드에 다음 결함이 있을 수 있습니다.
CLIENT_ACKNOWLEDGE 확인 모드 또는 트랜잭션된 세션을 사용하는 사용자가 Session.acknowledge 또는 Session.commit을 정기적으로 호출하고 있지 않을 수 있습니다.
AUTO_ACKNOWLEDGE 확인 모드를 사용하는 사용자가 어떤 이유로 중지되어 있을 수 있습니다.
문제의 원인을 확인하는 방법: 먼저 이 절에 나열된 모든 다른 가능한 원인을 확인하고다음 명령을 사용하여 대상을 나열합니다.
imqcmd list dst
UnAcked 헤더에 나열된 메시지 수가 대상의 메시지 수와 동일한지를 확인합니다. 이 헤더에 있는 메시지가 사용자에게 전송되었지만 확인되지 않았습니다. 이 수가 총 메시지 수와 같은 경우 브로커가 모든 메시지를 전송하고 확인을 대기 중인 것입니다.
문제를 해결하는 방법: 이 문제를 디버깅할 때 응용 프로그램 개발자에게 도움을 요청하십시오.
증상:
메시지 처리량이 산발적으로 떨어지다가 정상 성능을 회복합니다.
가능한 원인:
가능한 원인: 브로커의 메모리 자원이 매우 적습니다.
대상 및 브로커 제한이 제대로 설정되어 있지 않기 때문에 브로커가 메모리 과부하를 막기 위해 점점 더 중대한 조치를 취하게 되어 메시지 백로그를 지울 때까지 브로커가 아주 느려질 수 있습니다.
문제의 원인을 확인하는 방법: 브로커 로그에서 부족한 메모리 상태에 대한 항목 및
[B1089]: In low memory condition, broker is attempting to free up resources
새 메모리 상태와 사용 중인 전체 메모리 양에 대해 설명하는 항목이 있는지 확인합니다. 또한 JVM 힙에서 사용 가능한 메모리를 확인합니다.
imqcmd metrics bkr -m cxn
전체 JVM 메모리의 값이 최대 JVM 메모리 값에 근접한 경우 사용 가능한 메모리가 적습니다.
문제를 해결하는 방법:
JVM을 조정합니다( Java 가상 머신 조정 참조).
시스템 스왑 공간을 늘립니다.
가능한 원인: JVM 메모리 재생 이용(가비지 컬렉션)이 발생합니다.
메모리를 확보하기 위해 메모리 재생 이용이 주기적으로 시스템을 정리합니다. 이럴 경우 모든 스레드가 차단됩니다. 확보할 메모리 양이 크고 JVM 힙 크기가 클수록 메모리 재생 이용으로 인한 지체가 길어집니다.
문제의 원인을 확인하는 방법: 컴퓨터의 CPU 사용을 모니터합니다. 메모리 재생 이용이 발생하면 CPU 사용량이 떨어집니다.
또한 다음 명령줄 옵션을 사용하여 브로커를 시작합니다.
- vmargs -verbose:gc
표준 출력에 메모리 재생 이용이 발생하는 시간이 표시됩니다.
문제를 해결하는 방법: 다중 CPU 컴퓨터에서는 메모리 재생 이용이 병렬로 발생되도록 설정합니다.
-XX:+UseParallelGC=true
가능한 원인: JVM이 성능을 높이기 위해 JIT(Just-In-Time) 컴파일러를 사용하고 있습니다.
문제의 원인을 확인하는 방법: 이 문제를 일으키는 다른 원인은 없는지 확인합니다.
문제를 해결하는 방법: 잠시 동안 시스템이 실행되도록 놓아두면 성능이 향상됩니다.
증상:
생성자가 보낸 메시지를 사용자가 받지 못합니다.
가능한 원인:
가능한 원인: 제한 동작으로 인해 메시지가 브로커에서 삭제됩니다.
대상 메모리의 메시지 수나 메시지 바이트 수가 구성된 제한에 도달하면 브로커는 메모리 자원을 절약하려고 합니다. 이러한 제한에 도달하면 브로커가 수행하는 구성 가능한 동작 중 다음 세 가지 동작으로 인해 메시지가 손실됩니다.
REMOVE_OLDEST: 가장 오래된 메시지를 삭제합니다.
REMOVE_LOW_PRIORITY: 메시지의 보존 기간을 기준으로 우선 순위가 가장 낮은 메시지를 삭제합니다.
REJECT_NEWEST: 새 지속성 메시지를 거부합니다.
문제의 원인을 확인하는 방법: 사용 불능 메시지 대기열에 메시지가 포함되어 있음에서 설명한 대로 사용 불능 메시지 대기열을 확인합니다. 특히, "메시지 수 또는 메시지 크기가 대상 제한을 초과합니다."의 지침을 사용합니다.REMOVE_OLDEST 또는 REMOVE_LOW_PRIORITY 원인을 찾습니다.
문제를 해결하는 방법: 대상 제한을 늘립니다. 예를 들면 다음과 같습니다.
imqcmd update dst -n MyDest - o maxNumMsgs=1000
가능한 원인: 메시지 시간 초과 값이 만료됩니다.
브로커가 시간 초과 값이 만료된 메시지를 삭제합니다. 대상이 충분히 메시지로 백로그된 경우 수명 값이 너무 짧은 메시지는 삭제될 수 있습니다.
문제의 원인을 확인하는 방법:QBrowser 데모 응용 프로그램을 사용하여 사용 불능 메시지 대기열의 내용을 살펴보고 메시지 시간이 초과되었는지 확인합니다. QBrowser 데모의 플랫폼별 위치는 부록 A, 플랫폼별 Message QueueTM 데이터 위치를 참조하십시오. 또한 "예제 응용 프로그램 및 위치" 표를 참조하십시오.
다음은 Windows 플랫폼에서의 호출 예입니다.
cd \MessageQueue3\demo\applications\qbrowser java QBrowser
QBrowser 기본 창이 나타나면 대기열 이름 mq.sys.dmq를 선택한 다음 Browse를 누릅니다. 다음과 같은 목록이 나타납니다.
메시지를 두 번 누르면 해당 메시지에 대한 세부 정보가 표시됩니다.
메시지에 대한 JMS_SUN_DMQ_UNDELIVERED_REASON 등록 정보 값이 EXPIRED인지 확인합니다.
문제를 해결하는 방법: 응용 프로그램 개발자에게 문의하여 수명 값을 늘립니다.
가능한 원인: 클럭이 동기화되지 않습니다.
클럭이 동기화되어 있지 않은 경우 브로커의 메시지 수명 계산 오류로 인해 메시지가 만료 시간을 초과하여 삭제될 수 있습니다.
문제의 원인을 확인하는 방법: 브로커 로그 파일에서 B2102, B2103, B2104 메시지 중 하나가 있는지 확인합니다. 이러한 모든 메시지는 가능한 클럭 스큐가 감지되었음을 보고합니다.
문제를 해결하는 방법: 시스템 자원 준비에 설명된 대로 시간 동기화 프로그램이 실행 중인지 확인합니다.
가능한 원인: 사용자 클라이언트가 연결에서 메시지 전달을 시작하지 못했습니다.
클라이언트 코드가 연결을 설정하고 해당 연결에서 메시지 전달을 시작할 때까지 메시지를 전달할 수 없습니다.
문제의 원인을 확인하는 방법:클라이언트 코드가 연결을 설정하고 메시지 전달을 시작하는지 확인합니다.
문제를 해결하는 방법: 연결을 설정하고 메시지 전달을 시작하도록 클라이언트 코드를 다시 작성합니다.
증상:
대상을 나열하면 사용 불능 메시지 대기열에 메시지가 포함되어 있습니다. 예를 들어, 다음과 같은 명령을 실행합니다.
imqcmd list dst
사용자 이름과 비밀번호를 입력하면 다음과 같은 메시지가 출력됩니다.
Listing all the destinations on the broker specified by: --------------------------------- Host Primary Port --------------------------------- localhost 7676 ---------------------------------------------------------------------- Name Type State Producers Consumers Msgs Total Count UnAck Avg Size ------------------------------------------------- ---------------------- MyDest Queue RUNNING 0 0 5 0 1177.0 mq.sys.dmq Queue RUNNING 0 0 35 0 1422.0 Successfully listed destinations. |
이 예의 사용 불능 메시지 대기열 mq.sys.dmq에는 35개의 메시지가 포함되어 있습니다.
가능한 원인:
가능한 원인: 메시지 수 또는 메시지 크기가 대상 제한을 초과합니다.
문제의 원인을 확인하는 방법: QBrowser 데모 응용 프로그램을 사용하여 사용 불능 메시지 대기열의 내용을 살펴봅니다. QBrowser 데모의 플랫폼별 위치는 부록 A, 플랫폼별 Message QueueTM 데이터 위치를 참조하십시오. 또한 "예제 응용 프로그램 및 위치" 표를 참조하십시오.
다음은 Windows 플랫폼에서의 호출 예입니다.
cd \MessageQueue3\demo\applications\qbrowser java QBrowser
QBrowser 기본 창이 나타나면 대기열 이름 mq.sys.dmq를 선택한 다음 Browse를 누릅니다. "메시지 시간 초과 값이 만료됩니다."에서 이전에 표시된 것과 같은 목록이 나타납니다. "메시지 시간 초과 값이 만료됩니다."에 표시된 것처럼 아무 메시지나 두 번 누르면 해당 메시지에 대한 세부 정보가 표시됩니다
다음 메시지 등록 정보 값을 확인합니다.
JMS_SUN_DMQ_UNDELIVERED_REASON
JMS_SUN_DMQ_UNDELIVERED_COMMENT
JMS_SUN_DMQ_UNDELIVERED_TIMESTAMP
JMS Headers에서 JMSDestination 값을 검토하여 메시지가 사용 불능 상태인 대상을 확인합니다.
문제를 해결하는 방법: 대상 제한을 늘립니다. 예를 들면 다음과 같습니다.
imqcmd update dst - n MyDest -o maxNumMsgs=1000
가능한 원인: 브로커 클럭과 생성자 클럭이 동기화되어 있지 않습니다.
문제의 원인을 확인하는 방법: QBrowser 응용 프로그램을 사용하여 사용 불능 메시지 대기열에 있는 메시지의 세부 정보를 살펴봅니다. JMS_SUN_DMQ_UNDELIVERED_REASON 값을 확인하여 원인이 EXPIRED인 메시지를 찾습니다.
브로커 파일에서 B2102, B2103, B2104 메시지 중 하나가 있는지 확인합니다. 이러한 모든 메시지는 가능한 클럭 스큐가 감지되었음을 보고합니다.
문제를 해결하는 방법: 시스템 자원 준비에 설명된 대로 시간 동기화 프로그램이 실행 중인지 확인합니다.
가능한 원인: 메시지 시간이 초과되기 전에 사용자가 메시지를 받지 못합니다.
문제의 원인을 확인하는 방법: QBrowser 응용 프로그램을 사용하여 사용 불능 메시지 대기열에 있는 메시지의 세부 정보를 살펴봅니다. JMS_SUN_DMQ_UNDELIVERED_REASON 값을 확인하여 원인이 EXPIRED인 메시지를 찾습니다.
대상에 사용자가 있는지 확인합니다. 예를 들면 다음과 같습니다.
imqcmd query dst -t q -n MyDest
Current Number of Active Consumers에 나열된 값을 확인합니다. 활성 사용자가 있는 경우 다음 중 하나에 해당됩니다.
사용자의 연결이 일시 중단되었습니다.
메시지 시간 초과가 사용자의 실행 속도에 비해 너무 짧습니다.
문제를 해결하는 방법: 응용 프로그램 개발자에게 메시지 수명 값을 늘리도록 요청합니다.
가능한 원인: 사용자 수에 비해 생성자가 너무 많습니다.
문제의 원인을 확인하는 방법: QBrowser 응용 프로그램을 사용하여 사용 불능 메시지 대기열에 있는 메시지의 세부 정보를 살펴봅니다. JMS_SUN_DMQ_UNDELIVERED_REASON의 값을 확인합니다. 이유가 REMOVE_OLDEST 또는 REMOVE_LOW_PRIORITY인 경우 imqcmd query dst 명령을 사용하여 대상의 생성자 수와 사용자 수를 확인합니다. 생성자 수가 사용자 수를 초과하는 경우 생성 속도가 사용 속도보다 훨씬 빠를 수 있습니다.
문제를 해결하는 방법: 다음과 같은 명령을 사용하여 사용자 클라이언트를 추가하거나 사용자 제한 동작을 FLOW_CONTROL(사용 속도를 사용하여 생성 속도 제어)로 설정합니다.
imqcmd update dst -n myDst -t q -o consumerFlowLimit=FLOW_CONTROL
가능한 원인: 생성자가 사용자보다 더 빠릅니다.
문제의 원인을 확인하는 방법:사용자가 느리기 때문에 생성자가 느려지는지 확인하려면 다음과 같은 명령을 사용하여 대상 제한 동작을 FLOW_CONTROL(사용 속도를 사용하여 생성 속도 제어)로 설정합니다.
imqcmd update dst -n myDst -t q -o consumerFlowLimit=FLOW_CONTROL
다음 예와 같은 명령을 실행하여 메트릭을 통해 대상 입력과 출력을 검토합니다.
imqcmd metrics dst - n myDst -t q -m rts
메트릭 출력에서 다음 값을 검토합니다.
Msgs/sec Out: 브로커가 제거하는 초 당 메시지 수를 나타냅니다. 브로커는 모든 사용자가 메시지 수신을 확인하면 메시지를 제거하기 때문에 메트릭이 사용 속도에 영향을 줍니다.
Msgs/sec In: 브로커가 생성자로부터 수신하는 초 당 메시지 수를 나타냅니다. 따라서 메트릭이 생성 속도에 영향을 미칩니다.
흐름 제어는 생성을 소비에 맞추므로 생성이 느려지거나 중단되었는지 확인합니다. 그럴 경우 생성자와 사용자의 처리 속도가 일치하지 않는 것입니다. imqcmd list dst 명령을 사용하여 전송되었지만 확인되지 않은(UnAcked) 메시지 수를 확인할 수도 있습니다. 확인되지 않은 메시지 수가 대상 크기보다 작은 경우 대상에 추가 용량이 있기 때문에 클라이언트 흐름 제어에 의해 대상이 다시 보관됩니다.
문제를 해결하는 방법: 생성 속도가 사용 속도보다 일관되게 더 빠를 경우 흐름 제어를 정기적으로 사용하여 시스템을 정렬된 상태로 유지하십시오. 또한 뒤에 나오는 절들을 참조하여 다음과 같은 가능한 요소 각각을 해결해 보십시오.
가능한 원인: 사용자가 너무 느립니다.
문제의 원인을 확인하는 방법: "생성자가 사용자보다 더 빠릅니다."에서 설명한 대로 메트릭을 사용하여 생성 속도와 사용 속도를 확인합니다.
문제를 해결하는 방법:
다음과 같은 명령을 사용하여 대상의 제한 동작을 FLOW_CONTROL로 설정합니다.
imqcmd update dst -n myDst -t q -o consumerFlowLimit=FLOW_CONTROL
흐름 제어의 사용으로 인해 생산 속도가 사용 속도만큼 느려지므로 브로커에 메시지가 누적되지 않습니다. 대상에서 메시지를 처리할 수 있을 때까지 생성자 응용 프로그램이 메시지를 보관하므로 만료될 위험이 적습니다.
응용 프로그램 개발자에게 문의하여 생성자가 메시지를 일정한 속도로 보내는지 주기적으로 많은 메시지를 보내는지 확인합니다. 응용 프로그램이 한 번에 많은 메시지를 보내는 경우 다음 항목에 설명된 것처럼 대상 제한을 늘립니다.
메시지 수나 바이트 수 또는 둘 다를 기반으로 대상 제한을 늘립니다. 대상의 메시지 수를 변경하려면 다음과 같은 형식으로 명령을 입력합니다.
imqcmd update dst - n destName -t {q|t} -o maxNumMsgs=number
대상의 크기를 변경하려면 다음과 같은 형식으로 명령을 입력합니다.
imqcmd update dst -n destName -t {q|t} -o maxTotalMsgBytes=number
제한을 늘리면 브로커가 사용하는 메모리의 양이 증가합니다. 따라서 제한이 너무 높을 경우 메모리가 부족하여 브로커가 메시지를 처리할 수 없게 됩니다.
생산 로드가 높은 기간에 메시지 손실을 허용할 수 있는지 여부를 고려합니다.
가능한 원인: 클라이언트가 메시지를 완결하지 못합니다.
문제의 원인을 확인하는 방법: 응용 프로그램 개발자에게 문의하여 응용 프로그램이 트랜잭션을 사용하는지 여부를 확인합니다. 그럴 경우 다음과 같이 활성 트랜잭션을 나열합니다.
imqcmd list txn
다음은 명령 출력의 예입니다.
---------------------------------------------------------------------- Transaction ID State User name # Msgs/# Acks Creation time ---------------------------------------------------------------------- 6800151593984248832 STARTED guest 3/2 7/19/04 11:03:08 AM |
메시지 수와 확인 수를 확인합니다. 메시지 수가 더 많은 경우 생성자가 개별 메시지를 보내는 중일 수 있지만 트랜잭션을 완결하지 못한 것입니다. 브로커는 완결을 수신할 때까지 해당 트랜잭션에 대한 메시지를 경로 지정 및 전달할 수 없습니다. 확인 수가 더 많은 경우 사용자가 개별 메시지에 대한 확인을 보내는 중일 수 있지만 트랜잭션을 완결하지 못한 것입니다. 브로커는 완결을 수신할 때까지 해당 트랜잭션에 대한 확인을 제거할 수 없습니다.
문제를 해결하는 방법: 코딩 오류를 수정하려면 응용 프로그램 개발자에게 문의하십시오.
가능한 원인: 사용자가 메시지를 확인할 수 없습니다.
문제의 원인을 확인하는 방법: 응용 프로그램 개발자에게 문의하여 응용 프로그램이 시스템 기반 확인을 사용하는지 클라이언트 기반 확인을 사용하는지 확인합니다. 응용 프로그램이 시스템 기반 확인을 사용하는 경우 이 절을 건너뜁니다. 응용 프로그램이 클라이언트 기반 확인을 사용하는 경우(CLIENT_ACKNOWLEDGE) 다음과 같은 명령을 사용하여 먼저 클라이언트에 저장된 메시지 수를 줄입니다.
imqcmd update dst -n myDst -t q -o consumerFlowLimit=1
그런 다음 사용자가 느리기 때문에 브로커가 메시지를 버퍼링하는지 아니면 사용자가 메시지를 빠르게 처리하지만 메시지를 확인하지 않았는지를 확인합니다. 다음 명령을 사용하여 대상을 나열합니다.
imqcmd list dst
사용자 이름과 비밀번호를 입력하면 다음과 같은 메시지가 출력됩니다.
Listing all the destinations on the broker specified by: --------------------------------- Host Primary Port --------------------------------- localhost 7676 ---------------------------------------------------------------------- Name Type State Producers Consumers Msgs Total Count UnAck Avg Size ------------------------------------------------ ----------------------- MyDest Queue RUNNING 0 0 5 200 1177.0 mq.sys.dmq Queue RUNNING 0 0 35 0 1422.0 Successfully listed destinations. |
UnAck 수는 브로커가 보낸 다음 확인을 대기 중인 메시지 수를 나타냅니다. UnAck 수가 높거나 증가하는 경우 브로커가 메시지를 보내고 있는 중이므로 느린 사용자를 기다리지 않습니다. 또한 사용자가 메시지를 확인하지 않고 있음을 알 수 있습니다.
문제를 해결하는 방법:코딩 오류를 수정하려면 응용 프로그램 개발자에게 문의하십시오.
가능한 원인: 영구 사용자가 비활성 상태입니다.
문제의 원인을 확인하는 방법: 다음 명령 형식을 사용하여 주제의 영구 가입자를 확인합니다.
imqcmd list dur -d topicName
문제를 해결하는 방법:
imqcmd purge dur 명령을 사용하여 영구 사용자를 제거합니다.
사용자 응용 프로그램을 다시 시작합니다.
가능한 원인: 예기치 않은 브로커 오류가 발생했습니다.
문제의 원인을 확인하는 방법: "Producers are faster than consumers"에서 설명한 대로 QBrowser를 사용하여 메시지를 확인합니다.JMS_SUN_DMQ_UNDELIVERED_REASON 값이 ERROR이면 브로커 오류가 발생한 것입니다.
문제를 해결하는 방법:
브로커 로그 파일을 검토하여 관련 오류를 확인합니다.
Sun 기술 지원부에 연락하여 브로커 문제를 보고합니다.