설명: 프로세스가 비정상 종료되면,
로컬 오류 로그에 항목이 작성되고
오류 또는 z/OS 로그 디렉토리에 덤프 데이터 파일이
작성될 수 있습니다. 이 디렉토리는 바운드되지 않으며, 불필요한 파일을 지우지 않으면
이전의 이상종료 파일에서 많은 공간을 사용했기 때문에 시스템 성능이 저하될 수 있습니다.
해결책:Windows에서
mqsicreatebroker 명령의
-w 매개변수를 사용하여 WebSphere Message Broker 또는 Windows 자체가
포함되지 않은 하드 드라이브 파티션에 오류 디렉토리를 작성하는 것이 좋습니다.
여러 구성요소에 구성 문제가 있음
시나리오: 많은 구성요소에 구성 문제가 발생했습니다.
설명: 구성된 여러 구성요소와 함께 WebSphere Message Broker을
실행하는 경우, 브로커 프로세스의 메모리
풋프린트(특히, DataFlowEngine)가 메모리 한계를 초과할 수 있습니다.
특히, 사용자 프로세스 한계를 초과하거나 주소 공간 한계에
도달할 수 있습니다. 다음이 포함된 브로커를 실행할 때 BIP2106E 오류
메시지와 같은 문제가 발생할 수 있습니다.
다수의 메시지 플로우
다중 데이터베이스
다수의 입력 또는 출력 메시지
해결책: 운영 체제별 도구를 사용하여 실패한 프로세스의
최대 크기를 확인한 후 프로세스 크기에 대한 사용자 제한(적용될 경우) 또는
컴퓨터 제한이 있는지 확인하십시오.
ulimit 명령을 사용하여 Linux 또는
UNIX 시스템에서 사용자 제한을 확인하고 필요하면 늘리십시오.
각 운영 체제에는
최대 프로세스 크기에 대한 하드 제한이 있으며 이를 초과하면 실패하게 됩니다.
운영 체제
최대 프로세스 크기
Windows
2 GB
Solaris
대략 3.75 GB
HP-UX
커널 설정에 따라 대략 3GB
AIX(32비트 시스템)
2 GB
z/OS
2 GB
이러한 값 이상으로 사용자 한계를 증가시켜도 차이가 없습니다.
브로커 프로세스가 정기적으로 이러한 크기에 도달하는 경우, 메시지 플로우를 더 많은 실행 그룹으로 펼쳐서 각 크기를 한계보다 하나 작게 줄이십시오.
AIX, WebSphere Message Broker는
DataFlowEngines을 두 개의 256MB 메모리 세그먼트(즉, 512MB)로 제한합니다.
일반적으로 DataFlowEngine 프로세스에는 512MB 이상의 AIX 주소
공간이 필요하지 않으므로 두 세그먼트의 디폴트 주소 공간이 포함되도록 DataFlowEngine
실행 파일이 링크됩니다. 그러나 256MB 메모리 세그먼트 수를 늘려서 DataFlowEngine
프로세스에서 사용할 수 있는 AIX 주소 공간의
크기를 확장할 수 있습니다. 추가 메모리 세그먼트를 사용하려면 다음 쉘 명령을
사용하여 DataFlowEngine을 패치할 수 있습니다.
그렇게 하면 네 개의 세그먼트(즉, 1GB)를 사용하는 DataFlowEngine의
버전이 작성됩니다.
또는 AIX 5.1
이상에서 ldedit 명령을
사용하여 같은 결과를 얻을 수 있습니다.
ldedit -b maxdata:0x40000000 DataFlowEngine
픽스 팩 유지보수 응용프로그램은
기존 DataFlowEngine을 바꾸므로 위의 프로세스를 사용한 경우에는 픽스 팩을 설치할 때마다 프로세스를 반복하십시오.
위에서 설명한 기술은 소프트 한계만 대체하고 하드 한계는
대체하지 않습니다. 브로커 프로세스가 정기적으로 이러한 크기에 도달하는 경우,
메시지 플로우를 더 많은 실행 그룹으로 펼쳐서 각 크기를 한계보다 하나 작게 줄이십시오.
대형 XML 배열의 WHILE 루프 처리 시간 지연
시나리오: 대형 XML 배열의 WHILE 루프 처리 시간이 오래 걸립니다.
설명: CARDINALITY() 함수를 사용하여 WHILE문의 배열 크기를
판별하고 있을 수 있습니다. 대형 배열에서 요소 수의 판별 비용은 배열 크기에 비례하므로
이 방법이 권장되지 않습니다. CARDINALITY 함수는 WHILE문을 실행할 때마다 호출됩니다.
메시지에 여러 요소가 있으므로 이런 방식으로 루프를 실행하면 상당한 오버헤드가 발생합니다.
해결책: 배열의 요소 수가 동적으로 증가되는 메시지가 없다면,
WHILE 루프를 시작하기 전에 배열 크기를 결정해야 합니다. 다음 예와 유사한 코드를 사용하십시오.
DECLARE i,c INTEGER;
SET i = 1;
SET c=CARDINALITY(OutputRoot.XML.MyMessage.Array[ ]);
WHILE i <= c DO
. . .
. . . loop processing
. . .
END WHILE;
WebSphere MQ Everyplace를 사용한 리모트 waitForMessages 호출 속도가 느림
시나리오: WebSphere MQ Everyplace를 사용한 리모트 waitForMessages 호출 속도가 느림
설명: 이는 리모트 waitForMessages() 호출로 인해
항상 폴링 조치가 수행되기 때문입니다. 클라이언트 큐 관리자는 메시지가
리모트 큐에서 사용 가능하거나 시간 종료에 도달할 때까지 반복하여 메시지를
가져오려고 합니다.
해결책: 브로커의 큐 관리자에서 저장 및 전달 큐를 정의하고
클라이언트에서 홈 서버 큐를 정의하십시오. 그렇게 하면 클라이언트 큐 관리자를
사용할 수 없게 될 때 커플링 해제 레벨이 제공되어 배열이 작동할 수 있습니다.
또는 클라이언트측에서 로컬 GET이 충분히 호출되도록 WebSphere MQ Everyplace 출력
노드에 리모트 큐를 지정하십시오.
저장 프로시저의 성능이 손실됨
시나리오: 결과 세트를 리턴하지 않는 저장 프로시저는 DataDirect
버전 4.1 드라이버를 사용할 때처럼 잘 수행되지 않습니다.
설명: 새 DataDirect 버전 5 Oracle 드라이버는 구성 매개변수
ProcedureRetResults를 사용하여 드라이버가 저장 프로시저에서
결과 세트를 리턴할 수 있도록 합니다. 이 매개변수는 Oracle에만
적용됩니다. 기본적으로 매개변수는 1로 설정되며 결과 세트를 리턴하는 저장 프로시저를
사용할 경우 1이어야 합니다. 이 매개변수가 0으로 설정되면 드라이버가 저장
프로시저에서 결과 세트를 리턴하지 않으므로 성능이 좋아질 수 있습니다.
해결책: 저장 프로시저가 결과 세트를 리턴하지 않으면
ProcedureRetResults 매개변수를 0으로 설정하십시오.
대형 프로젝트에 대한 작업 시 Workbench에서 성능 저하가 발생함
시나리오: 대형 또는 복잡한 프로젝트에 대해 작업할 때 Workbench에서 성능 저하가 발생합니다.
설명: 프로젝트 추가 및 제거 또는 프로젝트 > 정리와
같은 잦은 프로젝트 변경으로 인해 성능 저하가 발생할 경우, 이는 크기, 수 및 파일 간의 연결로 인해 프로젝트 갱신에 대량의 메모리가 소모되기 때문입니다.
해결책: 시스템 메모리를 늘리십시오.
z/OS용 WebSphere MQ에서 보고하는 PutTime과 기타 시간 또는 시간 소인이 일치하지 않음
시나리오: z/OS용 WebSphere MQ에서 보고하는 PutTime과 기타 시간 또는 시간 소인이 일치하지 않습니다.
다음에서 약 20초 가량의 차이가 감지됩니다.
추적(Trace 노드에서 확보되는 추적 포함)
메시지 MQMD 헤더의 MQPUTTIME 시간 소인
ESQL에서 확보되는 시간 소인(예: Compute 노드의 시간 소인)
설명: WebSphere Message Broker가 윤초(leap second)를 반영하지 않는
UTC(Coordinated Universal Time)를 사용하여 시간을 보고합니다. 그러나
z/OS의 경우,
WebSphere MQ의 메시지 MQMD 헤더에서 보고하는 메시지 putTime은
실제로 CVT 필드에서 윤초(leap second) 수에 대해 지정된 값을 사용하는
윤초를 나타냅니다.
다음은 불일치의 원인일 수 있습니다.
디버깅 시 문제점
메시지의 흐름을 제어하기 위해 시간 소인을 사용하는 경우 메시지 플로우 관련 문제점
잘못된 정보
해결책: UTC 윤초 사용에 동의하도록 CVT 필드를 설정하십시오. 또는 오프셋을 추가하여 z/OS 시간 소인 읽기를 조정하십시오. 예를 들어 ESQL의 CURRENT_TIME 가져오기를 시도할 때 20초를 추가하십시오.