다음을 통해 공유

MessageBox 데이터베이스의 병목 상태 확인

  • 아티클

MessageBox 데이터베이스의 병목 상태를 확인하려면 먼저 SQL Server 에이전트 서비스가 시작되었는지 확인합니다. 서버를 다시 시작해도 서비스가 자동으로 다시 시작되도록 서비스 시작 상태를 수동에서 자동으로 변경합니다.

기본적으로 BizTalk 서비스는 스풀, TrackingData 또는 ApplicationQ 테이블이 증가되면 조정됩니다. 이러한 테이블을 자르는 역할을 수행하는 SQL 에이전트 작업이 실행되지 않으면 스풀이 커지므로 데이터베이스에 추가 부담을 주지 않도록 조정이 시작됩니다. 다음 성능 카운터의 상태를 확인합니다.

  • BizTalk:Message Agent (Host Name) Message Delivery Throttling State

  • BizTalk:Message Agent (Host Name) Message Publishing Throttling State

    값 0은 조정되고 있지 않음을 나타냅니다. 값 6은 데이터베이스 증가로 인해 시스템이 조정되고 있음을 나타냅니다. 이러한 카운터의 다른 값을 해석하는 방법은 해당 설명서를 참조하십시오.

스풀 테이블 증가

스풀은 여러 이유로 증가될 수 있습니다. 스풀 증가의 한 가지 원인은 애플리케이션 큐가 증가하는 경우입니다. 응용 프로그램 큐는 다운스트림 병목 및/또는 리소스 경쟁과 같은 다양한 이유로 인해 증가할 수 있습니다.

애플리케이션 큐가 작고 스풀이 크면 제거 작업이 제대로 수행되고 있는지 확인합니다. SQL 에이전트 서비스가 실행되고 있는지, 다음 작업이 성공적으로 완료되고 있는지 확인합니다.

  • MessageBox_Message_Cleanup_BizTalkMessageBoxDb

  • MessageBox_Parts_Cleanup_BizTalkMessageBoxDb

    MessageZeroSum 테이블이 크면 메시지가 처리되고(DeQueue가 성공적으로 완료되고 애플리케이션 큐 테이블에서 데이터가 삭제됨) 삭제할 행에 플래그가 지정되었지만 제거 작업이 미처 데이터를 삭제하지 못하고 있음을 알 수 있습니다. 한 가지 원인은 SQL Server 컴퓨터의 CPU 경쟁이 심각한 경우입니다. 이 경우 CPU 고갈로 인해 제거 작업을 제대로 수행할 수 없습니다.

애플리케이션 큐 테이블 증가

애플리케이션 큐는 처리 중인 전이 데이터를 호스팅하는데 이 데이터는 처리되고 나면 DeQueue에 의해 정리됩니다.

이러한 메시지가 처리된 후 해당 행에 대한 참조를 포함하는 스풀을 정리할 수 있습니다.

예를 들어 RxHostQ는 데이터를 오케스트레이션 PxHostQ에 게시하고 PxHostQ는 다시 데이터를 송신 TxHostQ에 게시하는데 이들은 각각 스풀 테이블의 한 행을 참조합니다. 특정 HostQ의 메시지가 시스템을 통해 성공적으로 처리된 후 DeQueue가 해당 행을 삭제합니다. 행이 삭제되고 나면 제거 작업에서 더 이상 이러한 행이 참조하지 않는 스풀을 정리할 수 있습니다.

애플리케이션 큐 증가는 애플리케이션 큐의 드레이닝을 담당하는 호스트 인스턴스가 들어오는 속도, 즉 메시지가 특정 애플리케이션 큐에 게시되는 속도를 따라갈 수 없음을 나타냅니다.

예를 들어 오케스트레이션 처리를 담당하는 서버가 CPU 제약으로 인해 더 빨리 처리할 수 없어서 오케스트레이션 애플리케이션 큐(PxHostQ)가 증가할 수 있습니다. 그러나 수신 서버의 게시 속도가 오케스트레이션 서버의 처리 속도보다 더 빠른 경우에도 애플리케이션 큐가 증가할 수 있습니다.

오케스트레이션 큐 증가는 메모리 경쟁 때문에 발생할 수도 있는데, 많은 수의 장기 실행 오케스트레이션 인스턴스가 메모리에서 동시에 인스턴스화되면 메모리 팽창이 발생하고 이는 메모리 부담이 줄어들 때까지 스레드 풀이 축소되도록 조정이 발생하는 간접적인 원인이 됩니다. 송신 애플리케이션 큐가 증가할 수 있는 한 가지 원인은 다운스트림 시스템이 BizTalk에서 나가는 메시지를 빨리 받을 수 없는 경우입니다. 이 경우 메시지가 계속 BizTalk 시스템 내에 있으므로 애플리케이션 큐가 증가하고, 궁극적으로 수신 속도를 줄이도록 조정이 시작되어 시스템의 전체 처리량에 영향을 줍니다.

TrackingData 테이블 증가

MessageBox 데이터베이스의 TrackingData 테이블은 인터셉터가 메시지 및 서비스 인스턴스 추적과 BAM 추적에 대한 추적 데이터를 모두 쓰는 전이 테이블입니다. 추적이 해제된 경우 이 테이블은 비어 있어야 합니다. 기본적으로 메시지 및 서비스 인스턴스 추적은 파이프라인 및 오케스트레이션 In/Out 이벤트에 사용할 수 있습니다.

메시지 본문 추적이 설정된 경우 MessageBox 서버(즉, "호스트 추적 허용" 호스트)가 실행되고 있는지 확인합니다. 이 서버는 MessageBox 데이터베이스의 TrackingData 테이블에서 BizTalkDTADb 테이블로 데이터를 이동하므로 병목 상태가 줄어듭니다.

예를 들어 승격된 속성 및 메시지 본문 추적에서 사용자 지정 메시지 및 서비스 instance 추적을 사용하도록 설정하여 사용자 지정 이벤트를 추적할 수 있습니다. 추적 데이터 외에도 이 테이블에는 BAM 데이터가 기록됩니다. MessageBox 데이터베이스에서 BizTalkDTADb 및 BAMPrimaryImport 데이터베이스로 이 데이터를 이동하고, 성공적으로 이동된 경우 이 데이터를 삭제하는 작업은 TDDS(추적이 설정된 호스트)가 수행합니다. 메시지 본문 추적 데이터는 SQL 에이전트 작업 TrackedMessages_Copy_BizTalkMsgBoxDb에 의해 별도로 이동됩니다.

TDDS에서 인터셉터가 TrackingData 테이블에 데이터를 쓰는 속도를 따라갈 수 없는 경우 이 테이블이 증가하여 조정이 시작되고, 궁극적으로 처리량 수준에 영향을 줍니다. 이 문제를 줄이려면 추적이 설정된 호스트가 한 개 이상 실행되고 있는지 확인합니다.

데이터가 여전히 쌓이는 경우 BizTalkDTADb 데이터베이스가 너무 빠르게 증가하고 있지 않은지 확인합니다. 보관 및 제거 작업이 실행되고 있는지, 데이터가 도착하는 속도를 따라갈 수 있는지 확인합니다.

참고

데이터가 보관되어야만 제거 작업이 BizTalkDTADb 테이블에서 해당 데이터를 삭제할 수 있습니다.

TrackingData 테이블이 증가하고 있지 않은지 확인합니다. 추적이 설정된 실행 중인 호스트 인스턴스(TDDS)가 한 개 이상 있는지 확인합니다. BizTalkDTADb 데이터베이스가 너무 커지면 MessageBox 데이터베이스에서 BizTalkDTADb 데이터베이스로 데이터를 이동하는 TDDS 성능이 저하될 수 있습니다.

TrackingData 테이블이 증가하면 조정이 시작되어 런타임 처리량 수준에 영향을 줄 수 있습니다.