BizTalk 계층의 병목 상태 확인
BizTalk 계층은 다음과 같은 기능 영역으로 나눌 수 있습니다.
수신
처리
전송
추적
기타
이러한 영역에서 시스템 리소스(CPU, 메모리 및 디스크)가 포화 상태인 것으로 보이는 경우 서버를 업그레이드하십시오. 시스템 리소스가 포화 상태가 아닌 경우에는 이 섹션에 설명된 단계를 수행하십시오.
수신 위치의 병목 상태
수신 위치에 메시지가 쌓이면(예: 파일 수신 폴더가 커지거나 나가는 큐가 빠르게 비워지지 않음) 시스템이 수신 로드에 맞게 빠르게 데이터를 흡수할 수 없다는 것을 알 수 있습니다. 이는 내부 조정 때문일 수 있는데 BizTalk는 가입자가 데이터를 빠르게 처리할 수 없어 데이터베이스 테이블에 백로그가 쌓이는 경우 수신 속도를 줄입니다. 병목 상태가 하드웨어 한계로 인해 발생하는 경우에는 하드웨어를 업그레이드해 보십시오. 수신 핸들러에 매핑된 호스트에 호스트 인스턴스(서버)를 추가하여 로드를 분산할 수도 있습니다. Perfmon을 사용하여 시스템의 리소스 사용률을 모니터링할 수 있습니다. 외부 수신 위치가 병목 상태의 원인이 아님을 확인하는 것이 중요합니다. 예를 들어 디스크 IO가 많아 원격 파일 공유가 포화 상태라거나 나가는 원격 큐를 호스팅하는 서버가 포화 상태가 아니라거나 HTTP/SOAP 로드를 생성하는 데 사용되는 클라이언트가 스레드에서 무한 대기하고 있지 않다거나 하는 것을 확인해야 합니다.
처리 병목 상태
호스트 큐 - 길이 수(아래 Perfmon 카운터 표 참조)의 증가는 오케스트레이션이 충분히 빠르게 완료되지 않는다는 것을 의미합니다. 이 현상은 메모리 경쟁이나 CPU 포화로 인해 발생할 수 있습니다.
오케스트레이션 서버가 병목 상태인 경우 Perfmon을 사용하여 출처를 확인합니다.
서버가 CPU 제약을 더 많이 받는 상태인 경우 다음을 고려하십시오.
워크플로가 복잡한 경우 오케스트레이션을 여러 개의 작은 오케스트레이션으로 분할하는 것을 고려해 보십시오.
참고
오케스트레이션을 여러 개의 워크플로로 분할하면 대기 시간이 늘어나고 복잡성이 증가할 수 있습니다.
복잡한 맵이 사용되는 경우 수신/송신 포트 중 대역폭이 남아 있는 포트를 확인하고 해당 포트로 맵을 이동할 수 있는지 생각해 보십시오.
하드웨어 업그레이드를 고려하거나 가능한 경우 추가 처리 서버를 구성하여 로드를 분산하는 방법을 고려해 보십시오.
전송 병목 상태
전송 서버의 리소스(예: 디스크, 메모리, CPU)가 포화 상태인 경우 서버를 업그레이드하거나 가능한 경우 송신 호스트 서버를 추가하여 로드를 분산하는 방법을 고려해 보십시오. 대상(BizTalk 외부)이 충분히 빠르게 데이터를 수신할 수 없는 경우 송신 계층이 병목 상태가 될 수 있습니다. 이렇게 되면 MessageBox 데이터베이스에 메시지가 쌓이게 됩니다(Application SendHostQ).
엔드포인트가 토폴로지 범위 안에 있는 경우 대상에서 원인을 격리하는 것을 고려해 보세요. 예를 들어 HTTP/SOAP 위치가 최적으로 로드를 수신할 수 있게 구성되어 있는지, 로드를 분산할 수 있는지 고려해 볼 수 있습니다. BizTalk에서 전달하는 출력 메시지가 너무 많아 대상이 증가하고 있지 않은지도 생각해 볼 수 있습니다. 그런 경우 대상 메시지를 보관 및 제거하는 유지 관리 계획을 세울 수 있습니다. 예를 들어 대상 폴더에 파일이 너무 많으면 BizTalk 서비스가 디스크 드라이브에 데이터를 커밋하는 것이 어려워질 수 있습니다.
추적 병목 상태
추적 호스트 인스턴스는 MessageBox 데이터베이스(TrackingData 테이블)에서 BizTalkDTADb 및/또는 BAMPrimaryImport 데이터베이스 테이블로 BAM/추적 메시지 이벤트 및 서비스 인스턴스 데이터를 이동하는 작업을 담당합니다. 여러 개의 MessageBox 데이터베이스가 구성된 경우 추적 호스트 인스턴스는 MessageBox당 4개의 스레드를 사용합니다.
이 호스트 인스턴스는 CPU에 의해 제약을 받게 될 수 있습니다. 이런 경우 서버를 업그레이드하거나 호스트 추적을 사용하는 추가 서버를 구성하여 로드를 분산하는 방법을 고려해 보십시오. 여러 개의 호스트 인스턴스는 구성된 여러 MessageBox의 로드 균형을 자동으로 조정합니다.
MessageBox 데이터베이스의 TrackingData 테이블이 정체되기 시작하는 이유는 대개 BizTalkDTADb 및/또는 BAMPrimaryImport 데이터베이스의 데이터 유지 관리 작업이 구성한 대로 실행되지 않아 BizTalkDTADb 및/또는 BAMPrimaryImport 데이터베이스가 커지기 때문입니다. 이 데이터베이스가 너무 커지면 추적 호스트가 이 테이블에 데이터를 삽입하는 속도가 떨어지므로 MessageBox 데이터베이스 테이블에서 추적된 데이터가 정체하는 현상이 발생합니다. MessageBox-TrackingData> 테이블의 증가로 인해 제한이 시작됩니다.
기타
서로 다른 기능은 각각 격리된 전용 호스트 인스턴스에서 실행되도록 배포 토폴로지를 구성하십시오. 이렇게 하면 각 호스트 인스턴스가 자체 리소스 집합(32비트 시스템, 2GB 가상 메모리 주소 공간, 핸들, 스레드)을 사용할 수 있습니다. 서버가 여러 호스트 인스턴스를 호스팅할 만큼 충분한 성능(충분한 CPU 여유 리소스, 메모리)을 가지고 있는 경우 모든 인스턴스가 물리적으로 동일한 컴퓨터에서 실행되도록 구성할 수 있습니다. 그렇지 않은 경우 각 기능을 전용 서버로 이동하여 쉽게 로드를 분산할 수 있습니다. 여러 서버에서 동일한 기능을 실행하면 고가용성 구성도 구현할 수 있습니다.
BizTalk 시스템 성능 카운터
| Object | 인스턴스 | 카운터 | 모니터링 목적 |
|---|---|---|---|
| 프로세서 | _Total | % Processor Time | 리소스 경쟁 |
| 프로세스 | BTSNTSvc | 가상 바이트 | 메모리 누수/팽창 |
| 프로세스 | BTSNTSvc | 프라이빗 바이트 | 메모리 누수/팽창 |
| 프로세스 | BTSNTSvc | 핸들 개수 | 리소스 경쟁 |
| 프로세스 | BTSNTSvc | 스레드 개수 | 리소스 경쟁 |
| 물리적 디스크 | _Total | % 유휴 시간 | 리소스 경쟁 |
| 물리적 디스크 | _Total | Current Disk Queue Length | 리소스 경쟁 |
CPU 경쟁
프로세스가 포화 상태인 경우 송신 및 오케스트레이션에서 수신을 분리하여 응용 프로그램을 조각화하는 방법을 고려해 보십시오. 이렇게 하려면 별도의 호스트를 만들고 이 호스트를 특정 기능(수신/송신/오케스트레이션/추적)에 매핑한 다음 전용 서버를 이들 호스트에 추가합니다. 오케스트레이션 기능은 일반적으로 CPU를 많이 사용하는 것으로 알려져 있으므로 오케스트레이션이 별도의 전용 서버에서 실행되도록 시스템을 구성하면 전체적인 시스템 처리량이 증가합니다.
여러 개의 오케스트레이션이 배포된 경우 이들을 서로 다른 전용 오케스트레이션 호스트에 등록할 수 있습니다. 서로 다른 물리적 서버를 각각 전용 오케스트레이션 호스트에 매핑하면 오케스트레이션이 서로 격리되므로 동일한 물리적 주소 공간 또는 동일한 서버에서 공유 리소스를 사용하려고 경쟁하지 않게 됩니다.
메모리 부족
처리량이 많은 시나리오에서는 시스템 메모리에 대한 요구가 증가할 수 있습니다. 32비트 프로세스는 소비할 수 있는 메모리 양에 의해 제한되므로 수신/처리/송신 기능을 별도의 호스트 인스턴스로 분리하여 각 호스트가 자체적으로 2GB 주소 공간을 사용할 수 있도록 하는 것이 좋습니다. 또한 물리적으로 동일한 서버에서 여러 개의 호스트 인스턴스가 실행되는 경우에는 4/8GB 메모리로 업그레이드하여 실제 메모리에서 디스크로 데이터가 스와핑되지 않도록 하는 것이 좋습니다. 장기 실행 오케스트레이션은 할당된 메모리를 더 오래 유지하여 메모리 bloat을 유발하여 제한이 시작될 수 있습니다. 메시지가 크면 메모리 사용량이 높아질 수도 있습니다.
특정 호스트에 대한 CPU당 내부 메시지 큐 크기 및 In-process 메시지를 줄임으로써 큰 메시지가 처리될 때 이 메모리 bloat 문제를 해결할 수 있습니다.
디스크 경쟁
디스크가 포화 상태인 경우(예: 파일/MSMQ 전송) 여러 스핀들로 업그레이드하고 RAID 1+0으로 디스크를 스트라이프하는 것이 좋습니다. 또한 FILE 전송을 사용할 때마다 폴더(수신 및 보내기 모두)가 너무 크지 않도록 하는 것이 중요합니다(>파일 50,000개).
아래 설명된 여러 가지 이유로 인해 BizTalk Server에서 시스템으로 들어오는 데이터를 조정하도록 선택한 경우 수신 폴더가 커질 수 있습니다. 송신 폴더가 커지면 BizTalk Server가 추가 데이터를 쓰기가 어려워지므로 이 폴더에서 데이터를 이동하는 것도 중요합니다. 비트랜잭션 MSMQ 큐의 경우 원격으로 수신 큐를 만들어서 BizTalk 서버의 디스크 경쟁이 줄어들게 하는 것이 좋습니다.
이 구성(원격 비트랜잭션 큐)을 사용하면 큐를 호스팅하는 원격 서버를 클러스터링할 수 있으므로 고가용성도 구현할 수 있습니다.
기타 시스템 리소스 경쟁
구성된 전송에 따라 HTTP/SOAP에 대한 IIS와 같은 시스템 리소스를 구성해야 할 수도 있습니다(예: MaxIOThreads, MaxWorkerThreads).
다운스트림 병목 상태
다운스트림 시스템이 BizTalk에서 데이터를 빠르게 수신할 수 없는 경우 이 출력 데이터가 BizTalk 데이터베이스 내부에 정체되어 팽창이 발생하고 이에 따라 조정이 시작되며 수신 파이프가 축소되면서 BizTalk 시스템의 전체 처리량이 감소할 수 있습니다. 이러한 상황은 스풀 증가로 나타납니다.
조정 영향
시스템이 회복할 수 없는 상태에 도달하는 것을 막기 위해 궁극적으로 조정이 시작됩니다. 그러므로 조정은 시스템이 정상적으로 기능하고 있는지 여부를 확인하고 문제의 출처를 발견할 수 있는 지점입니다. 조정 상태에서 병목 상태의 원인이 식별되면 다른 성능 카운터를 분석하여 문제의 출처를 세부적으로 밝혀냅니다.
예를 들어 MessageBox 데이터베이스의 치열한 경쟁은 CPU 사용량이 많아서 발생한 것일 수 있는데 CPU 사용량은 디스크에 대한 과도한 페이징으로 인해 많아진 것일 수 있으며 과도한 페이징은 메모리가 부족하여 발생한 것일 수 있습니다. MessageBox 데이터베이스의 치열한 경쟁은 잠금에 대한 경쟁이 치열하여 발생한 것일 수도 있는데 잠금에 대한 경쟁은 디스크 드라이브 포화로 인해 발생한 것일 수 있습니다.
BizTalk 응용 프로그램 카운터
| Object | 인스턴스 | 카운터 | Description |
|---|---|---|---|
| BizTalk 메시징 | RxHost | Documents Received/Sec | 들어오는 속도 |
| BizTalk 메시징 | TxHost | Documents Processed/Sec | 나가는 속도 |
| XLANG/s 오케스트레이션 | PxHost | Orchestrations Completed/Sec. | 처리 속도 |
| BizTalk: MessageBox: 일반 카운터 | MsgBoxName | Spool Size | 모든 호스트 큐의 누적 크기 |
| BizTalk: MessageBox: 일반 카운터 | MsgBoxName | Tracking Data Size | MessageBox의 TrackingData 테이블 크기 |
| BizTalk:MessageBox:호스트 카운터 | PxHost:MsgBoxName | 호스트 큐 - 길이 | 특정 호스트 큐의 메시지 수 |
| BizTalk:MessageBox:호스트 카운터 | TxHost:MsgBoxName | 호스트 큐 - 길이 | 특정 호스트 큐의 메시지 수 |
| BizTalk:Message Agent | RxHost | 데이터베이스 크기 | 게시(PxHost) 큐의 크기 |
| BizTalk:Message Agent | PxHost | 데이터베이스 크기 | 게시(TxHost) 큐의 크기 |
| BizTalk:Message Agent | HostName | Message Delivery Throttling State | XLANG 및 아웃바운드 전송에 영향을 미칩니다. |
| BizTalk:Message Agent | HostName | Message Publishing Throttling State | XLANG 및 인바운드 전송에 영향을 미칩니다. |
시작 단계
일반적으로 각 호스트 instance 대한 메시지 배달 제한 상태 및 메시지 게시 제한 상태를 모니터링하는 것이 좋습니다. 이러한 카운터의 값이 0이 아닌 경우 BizTalk 시스템 내부에서 조정이 발생하고 있다는 것을 알 수 있으며 병목 상태의 원인에 대한 추가 분석을 수행할 수 있습니다. 다른 성능 카운터에 대한 설명은 성능 병목 상태 식별을 참조하세요.
백로그 축적
1개의 메시지가 수신되면 1개의 메시지가 처리되고 전송되는 1-1 배포 시나리오에서는 나가는 속도가 들어오는 속도와 일치하지 않을 경우 시스템의 어딘가에 백로그가 축적됩니다. 이러한 상황인 경우 Spool Size를 모니터링할 수 있습니다.
스풀이 비례적으로 증가하는 경우 스풀을 증가시키는 응용 프로그램 큐를 확인하여 더 자세하게 원인을 파악할 수 있습니다.
증가하는 응용 프로그램 큐가 없는데 스풀은 계속 커지는 경우 에이전트가 실행되고 있지 않거나 SQL 서버의 다른 시스템 리소스 경쟁으로 인해 제거 작업이 제대로 진행되지 않고 있는 것일 수 있습니다.
응용 프로그램 큐 중 하나가 증가하는 경우에는 그 원인을 진단해야 합니다. 특정 응용 프로그램 큐가 비워지지 않는 시스템의 시스템 자원을 모니터링하십시오. 예를 들어 서버의 CPU 부족으로 인해 오케스트레이션 Host-Q가 증가할 수 있습니다. 특정 호스트 인스턴스의 조정 카운터 값도 확인하십시오.
Delivery/Publishing State가 0이 아닌 경우 해당 값을 확인하여 조정 이유(예: 메모리 임계값 초과, 진행 중인 메시지 수가 너무 많음)를 파악하십시오.
F1 프로파일러
성능 카운터를 사용하면 개략적인 수준에서 병목 상태가 발생한 위치를 빠르게 파악할 수 있습니다. 그러나 범위가 좁혀지면 문제를 해결하기 위해 코드 수준까지 내려가야 할 수도 있습니다. Visual Studio와 함께 제공되는 F1 프로파일러는 코드에서 가장 많은 시간이 소비되는 위치가 어디인지 진단하는 데 도움을 줄 수 있는 도구입니다.
기호를 사용하면 더 의미있는 스택이 만들어집니다(특히 비관리 코드의 경우). 예를 들어 F1-프로파일러를 사용하면 API 호출이 반환되는 데 걸리는 시간 및 호출 수를 찾아낼 수 있습니다. 스택을 더 자세히 검사하면 긴 대기 시간의 내부 원인을 찾아낼 수 있습니다. 이는 데이터베이스 쿼리에 대한 차단 호출일 수도 있고 단순히 이벤트를 대기하는 호출일 수도 있습니다.
L2/L3 캐시
하드웨어 관점에서 가장 큰 이익은 온보드 CPU 캐시를 이용하여 얻을 수 있습니다. CPU 캐시의 성능이 높을수록 캐시 적중률이 높아지므로 시스템에서 메모리와 디스크 간 데이터 페이징이 줄어듭니다.
64비트 성능 병목 상태
64비트 시스템의 성능이 32비트 시스템의 성능보다 낮아 보입니다. 이러한 현상은 몇 가지 이유로 인해 발생할 수 있는데, 가장 중요한 이유는 메모리입니다.
2GB 메모리를 가진 32비트 시스템의 성능을 측정하여 2GB 메모리를 가진 유사한 64비트 시스템의 성능과 비교하는 것은 단순한 문제가 아닙니다. 64비트 시스템은 디스크 IO의 제약(짧은 % 디스크 유휴 시간 & 긴 디스크 큐 길이)과 CPU의 제약(최대 CPU & 많은 컨텍스트 스위칭)을 받는 것으로 보일 것입니다. 하지만 이러한 현상은 64비트 시스템에서 파일 IO를 수행하는 작업이 더 어렵기 때문은 아닙니다.
64비트 시스템에서는 메모리가 더 많이 소비되므로(64비트 주소 지정) 사용 가능한 2GB 메모리의 대부분이 OS에 의해 소비됩니다. 이렇게 되면 대부분의 다른 작업에서 디스크로의 페이징이 발생하므로 파일 하위 시스템이 부담을 받게 됩니다. 시스템은 이제 데이터 및 코드를 메모리에서 페이징하는 데 CPU 주기를 사용할 뿐만 아니라 디스크를 사용하기 위해 오랜 시간을 대기해야 합니다. 결과적으로 디스크 경쟁이 심해지고 CPU 소비가 늘어나게 됩니다.
이 문제를 완화하는 방법은 메모리를 업그레이드하여(권장 8GB) 서버의 성능을 높이는 것입니다. 그러나 메모리 부족으로 인한 CPU 부족이 문제의 원인이 아닌 경우에는 메모리를 추가해도 처리량이 늘어나지 않습니다.
BAM을 사용하여 병목 상태 및 긴 대기 시간 문제 확인
짧은 대기 시간이 중요한 상황에서는 BAM을 사용하여 시스템이 BizTalk 시스템 안에서 각 단계를 완료하는 데 걸리는 시간을 측정할 수 있습니다. 추적된 메시지 이벤트 및 서비스 instance 데이터를 사용하여 메시지 상태를 디버그하고 메시지 라우팅에서 문제의 원인을 진단할 수 있지만 BAM을 사용하여 메시지 흐름을 통해 다양한 지점을 추적할 수 있습니다. 활동 및 Continuation을 정의하는 BAM 추적 프로필을 만들어 시스템의 서로 다른 부분 사이의 대기 시간을 측정하면 워크플로 프로세스에서 가장 시간이 많이 걸리는 단계를 추적할 수 있습니다.