BizTalk Server 프로세스에서 메모리 누수 또는 메모리 부족 예외 문제를 해결하는 방법

  • 아티클

이 문서에서는 Microsoft BizTalk Server BizTalk Server 프로세스에서 메모리 누수 또는 메모리 부족 예외 문제를 해결하는 방법을 설명합니다.

원래 제품 버전: BizTalk Server 2010, 2009
원래 KB 번호: 918643

요약

메모리 누수는 일반적인 문제입니다. Microsoft BizTalk Server 메모리 누수 또는 OOM(메모리 부족) 예외의 특정 원인을 찾기 위해 몇 가지 단계를 시도해야 할 수 있습니다. 이 문서에서는 메모리 사용량 및 가능한 메모리 관련 문제를 평가할 때 고려해야 할 중요한 사항에 대해 설명합니다. 이러한 고려 사항에는 다음과 같은 사항이 포함됩니다.

  • 실제 RAM
  • 대용량 메시지 처리
  • /3GB 스위치 사용
  • 사용자 지정 구성 요소 사용
  • 시스템이 실행 중인 Microsoft .NET Framework 버전
  • 프로세서 수

Microsoft Windows 작업 관리자의 메모리 사용량이 실제 RAM의 50% 이상을 사용하는 경우 BizTalk Server 프로세스에 메모리 누수가 발생할 수 있습니다. 메모리 누수는 프로세스가 시스템 메모리가 부족하거나 프로세스가 작동을 중지할 때까지 메모리 사용량이 증가할 때 메모리 부족 예외가 발생할 수 있습니다. 이 문제의 경우 다음을 고려합니다.

실제 RAM 및 메모리 사용량

프로세스에서 실제 RAM의 약 절반을 사용하는 동작이 예상될 수 있으므로 메모리 사용량을 지침으로 사용합니다. 예를 들어 BizTalk Server RAM이 4GB이고 BizTalk Server 프로세스에서 약 500MB의 RAM을 사용하는 경우 누출이 없을 수 있습니다. BizTalk Server 프로세스에서 약 1GB의 RAM을 사용하는 경우 메모리 누수 또는 높은 메모리 상황이 있을 수 있습니다. 메모리 사용량은 장기 실행 저장 프로시저 또는 오케스트레이션으로 인해 발생할 수 있습니다. BizTalk 호스트가 일반적으로 메모리 누수 또는 높은 메모리 상태가 발생하는지 여부를 확인하는 데 사용하는 메모리 양을 알고 있는지 확인합니다.

큰 메시지

BizTalk Server 큰 메시지를 처리할 때 시스템에 메모리 누수가 있는 것 같습니다. 그러나 메시지는 많은 양의 메모리를 사용할 수 있습니다.

또한 BizTalk Server 대용량 메시지를 처리하는 경우 높은 메모리 사용량이 예상될 수 있습니다. 환경에서 BizTalk Server 성능 요구 사항을 충족하도록 하드웨어를 업그레이드할 수 있습니다.

메모리 누수를 재현하는 데 걸리는 시간

메모리 누수는 즉시 발생하거나 시간이 지남에 따라 누적할 수 있습니다. 두 시나리오 모두 일반적입니다.

32비트 컴퓨터에서 /3GB 스위치 사용

일반적으로 프로세스는 2GB의 가상 주소 공간에 액세스할 수 있습니다. /3GB 스위치는 주소 지정 가능한 메모리가 더 필요한 시스템에 대한 옵션입니다. 이 옵션을 사용하면 메시지 처리에 대한 메모리 사용량이 향상될 수 있습니다. 그러나 /3GB 스위치 는 커널 모드 작업에 1GB의 주소 지정 가능 메모리만 허용합니다. 또한 이 스위치는 풀 메모리 부족의 위험을 증가시킬 수 있습니다.

32비트 버전의 Windows에서 /3GB 스위치 를 사용하도록 설정하면 프로세스가 큰 주소를 인식하는 경우 프로세스에서 3GB의 가상 주소 공간에 액세스할 수 있습니다. 프로세스는 실행 파일에 이미지 헤더에 설정된 IMAGE_FILE_LARGE_ADDRESS_AWARE 플래그가 있는 경우 큰 주소를 인식합니다. BizTalk 프로세스는 큰 주소를 인식하므로 BizTalk는 /3GB 스위치의 이점을 누릴 수 있습니다.

32비트 BizTalk 호스트 instance 64비트 버전의 Windows(AMD64)에서 실행 중인 경우 BizTalk 프로세스는 BizTalk가 큰 주소를 인식하므로 4GB 메모리 주소 공간의 이점을 누릴 수 있습니다. 따라서 높은 메모리 애플리케이션을 64비트 서버로 이동하는 것이 가장 좋은 솔루션일 수 있습니다.

64비트 버전의 Windows(AMD64)의 64비트 BizTalk 프로세스에는 8TB의 주소 지정 가능한 메모리가 있습니다.

또한 가상 바이트 및 프로세스에서 사용하는 프라이빗 바이트를 고려해야 합니다. .NET Framework 애플리케이션인 BizTalk 호스트 instance 가상 바이트 값이 2GB에 도달하기 전에 메모리 부족 오류가 발생할 수 있습니다. 이 상황은 32비트 버전의 Windows( /3GB 스위치 제외)의 프로세스에서 주소 지정 가능한 최대 메모리가 2GB인 경우에도 발생할 수 있습니다. 이러한 상황이 발생할 수 있는 이유에 대한 설명은 다음 MSDN(Microsoft Developer Network) 웹 사이트를 참조하세요.
ASP.NET 성능 모니터링 및 관리자에게 경고하는 시기

/3GB 스위치는 BizTalk 프로세스의 최대 프라이빗 바이트를 800MB에서 1800MB로 증가시킵니다. /3GB 스위치를 사용하도록 설정된 .NET Framework 애플리케이션 성능에 대한 자세한 내용은 챕터 17 — .NET 애플리케이션 성능 튜닝을 참조하세요.

다음 표에는 이 정보가 요약되어 있으며 가상 바이트 및 프라이빗 바이트에 대한 실제 제한이 포함되어 있습니다.

프로세스 Windows 주소 지정 가능한 메모리(큰 주소 인식 프로세스 포함) 가상 바이트에 대한 실제 제한 프라이빗 바이트에 대한 실제 제한
32비트 32비트 2GB 1400MB 800MB
32비트 32비트/3GB 3GB 2400MB 1800MB
32비트 64비트 4 GB 3400MB 2800MB
64비트 64비트 8TB 해당 없음 해당 없음

32비트 및 64비트 Windows의 주소 지정 가능 메모리에 대한 자세한 내용은 Windows 및 Windows Server 릴리스의 메모리 제한을 참조하세요.

다음 표에서는 다양한 버전의 BizTalk Server 대한 PAE 및 3GB 지원 가능성을 나열합니다.

제품 Pae 3GB
BizTalk Server 2004년 예 아니요
BizTalk Server 2006년 예 예
BizTalk Server 2006 R2 예 예
BizTalk Server 2009 예 예

BizTalk Server 실행 중인 컴퓨터의 성능 요구 사항을 충족하기 위해 /3GB 스위치를 사용하도록 설정해야 하는 경우 BizTalk 그룹에 서버를 추가하는 것이 좋습니다. 이렇게 하면 메모리 집약적 호스트 인스턴스를 스케일 아웃할 수 있습니다.

IIS(인터넷 정보 서비스) 프로세스 내에서 실행되는 BizTalk 구성 요소는 /3GB 스위치 를 사용하는 경우에도 도움이 될 수 있습니다.

/3GB 스위치는 Windows SharePoint Services 2.0 이상 버전 또는 SharePoint Portal Server 2003 SP2 이상을 실행하는 컴퓨터에서는 지원되지 않습니다. Windows Server 2003 /3GB 스위치는 Windows SharePoint Services 2.0 이상 버전 또는 SharePoint Portal Server 2003 서비스 팩 2 이상 버전에서는 지원되지 않습니다.

사용자 지정 구성 요소 사용

파이프라인 또는 서비스 구성 요소와 같은 사용자 지정 구성 요소를 사용하는 경우 이러한 구성 요소가 수행하는 작업을 알고 있어야 합니다. 또한 이러한 구성 요소가 메모리 사용량에 미치는 잠재적인 영향을 알고 있어야 합니다. 구성 요소가 문서를 변환할 때 일반적인 메모리 문제가 발생합니다. 변환 작업은 메모리를 많이 사용하는 작업입니다. 문서가 변환되면 BizTalk Server 메시지 스트림을 BizTalk 프로세스 내의 Microsoft .NET Framework XslTransform 클래스에 전달합니다.

또 다른 일반적인 문제는 집약적인 문자열 조작이 있을 때 발생합니다. 집약적인 문자열 조작은 많은 추억을 소비할 수 있습니다. 성능을 개선하는 방법에 대한 자세한 내용은 관리 코드 성능 향상을 참조하세요.

.NET Framework 버전

Microsoft .NET Framework 2.0 및 .NET Framework 1.1에는 다른 메모리 동작이 있습니다. 따라서 그 사이에 다양한 결과가 표시 될 수 있습니다. .NET Framework 사용하는 경우 최신 .NET Framework 서비스 팩 1이 설치되어 있는지 확인합니다. 이 서비스 팩은 알려진 몇 가지 메모리 문제를 해결합니다.

프로세서 수

CLR(공용 언어 런타임)에는 다음과 같은 GC(가비지 수집기)가 있습니다.

  • 워크스테이션(Mscorwks.dll)
  • 서버(Mscorsvr.dll)

BizTalk Server 실행하는 컴퓨터가 다중 프로세서 시스템인 경우 .NET Framework 실행 엔진의 서버 버전을 사용합니다. 이는 기본 동작입니다. 서버 가비지 수집기는 최대 처리량을 위해 설계되었습니다. 또한 서버 가비지 수집기는 확장되어 고성능을 제공합니다. 이 가비지 수집기는 메모리를 할당한 다음 나중에 메모리를 해제하여 시스템에서 고성능을 제공합니다. 따라서 일부 .NET Framework 구성 요소와 함께 BizTalk Server 실행 중인 컴퓨터에 메모리 누수가 있는 것 같습니다. 그러나 이 시나리오에서는 높은 메모리 사용량이 예상되는 동작입니다. 컴퓨터의 시스템 메모리가 부족하거나 주소 지정 가능한 메모리 부족으로 인해 프로세스가 작동하지 않는 경우 메모리 누수 조건이 있을 수 있습니다.

BizTalk Server 실행하는 컴퓨터가 단일 프로세서 시스템인 경우 .NET Framework 실행 엔진의 워크스테이션 버전을 사용합니다. 기본 동작입니다. 워크스테이션 가비지 수집기 할당 알고리즘은 크기 조정 또는 최대 처리량을 위해 설계되지 않았습니다. 이 가비지 수집기는 동시 가비지 수집기 메서드를 사용합니다. 이러한 메서드는 복잡한 사용자 인터페이스가 있는 애플리케이션을 위해 설계되었습니다. 이러한 애플리케이션에는 보다 적극적인 가비지 수집이 필요할 수 있습니다.

중요

이 절, 방법 또는 작업에는 레지스트리를 수정하는 방법에 대한 단계가 포함되어 있습니다. 그러나 레지스트리를 잘못 수정하면 심각한 문제가 발생할 수 있습니다. 따라서 이러한 단계를 신중하게 수행해야 합니다. 추가된 보호를 위해 레지스트리를 수정하기 전에 백업하세요. 그런 다음 문제가 발생할 경우 레지스트리를 복원할 수 있습니다. 레지스트리를 백업 및 복원하는 방법에 대한 자세한 내용은 Windows에서 레지스트리를 백업 및 복원하는 방법을 참조하세요.

경우에 따라 다중 프로세서 시스템에서 실행 엔진의 워크스테이션 버전을 실행하는 것이 적절할 수 있습니다. 다음 레지스트리 키를 사용하여 실행 엔진의 워크스테이션 버전으로 전환할 수 있습니다.

BizTalk 2006 이상 버전

다음 CRL Hosting Create 해당 값이 있는 문자열 레지스트리 키:

  • 키: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$BizTalkHostName\CLR Hosting
  • 값 이름: Flavor
  • 값 데이터: wks

BizTalk 2004

다음 CRL Host Create 해당 값이 있는 문자열 레지스트리 키:

  • 키: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BTSSvc{GUID }\CLR Hosting
  • 값 이름: Flavor
  • 값 데이터: wks

자세한 내용은 .NET Framework Run-Time 기술에 대한 성능 고려 사항을 참조하세요.

일반적인 원인 및 해결 방법은 다음과 같습니다.

프로세스 및 실제 메모리 사용 제한 임계값

프로세스 메모리 사용량 및 실제 메모리 사용량 제한 임계값은 BizTalk Server 2006 이상 버전에서 변경할 수 있습니다.

  • 기본적으로 프로세스 메모리 사용 제한 임계값은 25로 설정됩니다. 이 값을 초과하고 BizTalk 프로세스 메모리 사용량이 300MB를 초과하는 경우 제한 조건이 발생할 수 있습니다. 32비트 서버에서 프로세스 메모리 사용량 값을 50으로 늘릴 수 있습니다. 64비트 서버에서 이 값을 100으로 늘릴 수 있습니다. 이렇게 하면 제한이 발생하기 전에 BizTalk 프로세스에서 메모리를 더 많이 사용할 수 있습니다.

  • 실제 메모리 사용량 제한 임계값의 기본값은 0입니다. 이 임계값은 총 시스템 메모리를 측정합니다. 따라서 0 이외의 값이 구성된 경우 비 BizTalk 프로세스가 높은 메모리를 사용하는 경우 제한 조건이 발생할 수 있습니다.

탈수 제한 임계값

기본 메모리 탈수 임계값은 오케스트레이션이 64비트 호스트에서 실행될 때 너무 많은 탈수를 일으킬 수 있습니다. 이 문제에 대한 자세한 내용은 디하이드레이션 기본 속성을 참조하세요.

참고

64비트 호스트는 BizTalk Server 2006 이상 버전에서 지원됩니다.

32비트 호스트 instance 동일한 하드웨어에서 관찰된 탈수는 기본 메모리 탈수 제한 임계값을 사용하여 동일한 오케스트레이션을 실행할 때 명목상입니다.

64비트 아키텍처는 확장된 메모리 주소 공간(4GB 대신 16TB)을 제공하기 때문에 64비트 호스트 인스턴스는 32비트 호스트 인스턴스보다 더 많은 메모리를 할당합니다. 이로 인해 기본 메모리 제한 임계값이 초과될 수 있습니다.

이 동작을 해결하려면 BTSNTSvc64.exe.config 파일에서 VirtualMemoryThrottlingCriteria 및 PrivateMemoryThrottlingCriteria 값을 변경합니다. \Process\Virtual Bytes 및 \Process\Private Bytes 성능 모니터 카운터를 사용하여 오케스트레이션 instance 할당되는 가장 많은 양의 메모리를 확인합니다.

  • 다음을 기반으로 두 속성 모두에 대해 OptimalUsage 값을 설정합니다.

    • VirtualMemoryThrottlingCriteria: \Process\Virtual Bytes value + 10%
    • PrivateMemoryThrottlingCriteria: \Process\Private Bytes value + 10%

  • 두 속성의 MaximalUsage 를 OptimalUsage 값 + 30%로 설정합니다.

예를 들어 오케스트레이션 instance \Process\Virtual Byte 성능 모니터 카운터 값이 5,784,787,695바이트(5,517MB)인 경우 VirtualMemoryTh에 대한 OptimalUsage 값을 설정합니다.rottlingCriteria to 6,069MB(5,784,787,695 * 1.10 = 6,363,266,464.5바이트).

VirtualMemoryThrottlingCriteria의 MaximalUsage 값을 7,889MB(6,363,266,464.5 * 1.30 = 8,272,246,403.85바이트)로 설정합니다.

\Process\Private Bytes 성능 모니터 카운터 값이 435689400 바이트(415MB)인 경우 PrivateMemoryThrottlingCriteria의 OptimalUsage 값을 457MB(435689400 * 1.10 = 479258340 바이트)로 설정합니다.

PrivateMemoryThrottlingCriteria의 MaximalUsage 값을 594MB(479258340 * 1.30 = 623035842)로 설정합니다.

이 예제에서는 제한을 줄이기 위해 BTSNTSvc64.exe.config 파일에 다음 값을 지정합니다.

성능 모니터 카운터 할당된 메모리 OptimalUsage MaximalUsage
\Process\Virtual Bytes 5,784,787,695바이트(5517MB) 6069 7889
\Process\Private Bytes 435,689,400바이트(415MB) 457 594

그런 다음 이러한 값은 다음과 같이 BTSNTSvc64.exe.config 파일에 표시됩니다.

<xlangs>
    <Configuration>
       <Dehydration>
         <VirtualMemoryThrottlingCriteria OptimalUsage="6069" MaximalUsage="7889" IsActive="true" />
         <PrivateMemoryThrottlingCriteria OptimalUsage="457" MaximalUsage="594" IsActive="true" />
       </Dehydration>
    </Configuration>
</xlangs>

오케스트레이션을 실행하는 호스트 instance 확인하려면 \BizTalk: Messaging\ID 프로세스 및 \Process\ID 프로세스 성능 모니터 카운터의 ID 프로세스와 일치시킬 수 있습니다. 그런 다음 해당 \Process\Virtual Bytes 및 \Process\Private Bytes 성능 모니터 카운터에 대해 표시되는 평균 값을 검사.

참고

사용자가 주의해야 하는 정보SQL Server 2008년 데이터베이스를 실행할 때 BizTalkMsgBoxDb 탈수 상태가 높으면 성능이 크게 저하될 수 있습니다.

BizTalk Server 서비스 팩 및 누적 업데이트

BizTalk Server 서비스 팩 및 누적 업데이트에는 최신 수정 사항이 포함됩니다. 여기에는 알려진 System.OutOfMemoryException 문제에 영향을 미치는 문제가 포함됩니다.

HeapDeCommitFreeBlockThreshold

기본적으로 HeapDeCommitFreeBlockThreshold 레지스트리 키 값은 0입니다. 값이 0이면 힙 관리자가 사용 가능한 4KB(KB) 페이지마다 커밋을 해제합니다. 커밋 해제 작업으로 인해 가상 메모리 조각화가 발생할 수 있습니다. 힙 관리자의 HeapDeCommitFreeBlockThreshold 설정 크기는 시스템이 수행하는 작업의 종류에 따라 달라집니다. 0x00040000 크기는 권장되는 시작 값입니다.

레지스트리 키의 HeapDeCommitFreeBlockThreshold 값을 변경하기 전에 다음 정보를 고려합니다.

  • 이 변경 내용은 메모리 조각화 문제에만 적용됩니다.
  • 이 변경 내용은 시스템 전체입니다. 따라서 대부분의 프로세스는 시작 시 더 많은 메모리를 사용합니다.
  • BizTalk Server 기본 임무로 사용하는 시스템에 대해서만 이 변경을 고려합니다.

가상 메모리 조각화를 줄이기 위해 에서 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager다음 레지스트리 키의 HeapDeCommitFreeBlockThreshold 값을 변경하여 힙 관리자에서 설정의 크기를 늘릴 수 있습니다.

  • 값 이름: HeapDeCommitFreeBlockThreshold
  • 값 형식: REG_DWORD
  • 값 데이터: 0x00040000(권장되는 시작 값입니다.)
  • 기본값: 없음

변환 작업

BizTalk Server 수신 포트, 송신 포트 또는 XLANG의 상당히 큰 메시지에 대해 XML 변환 작업을 수행하면 XSL 변환은 전체 메시지를 메모리에 로드합니다.

이 문제를 해결하려면 다음 방법 중 하나를 사용하십시오.

  • BizTalk Server 동시에 처리하는 메시지 수를 줄입니다.
  • 변환되는 XML 메시지의 크기를 줄입니다.

개체는 System.Policy.Security.Evidence 변환에 자주 사용되며 많은 메모리를 사용할 수 있습니다. 맵에 인라인 C#(또는 다른 인라인 언어)을 사용하는 스크립팅 functoid 이 포함되어 있으면 어셈블리가 메모리에 만들어집니다. 개체는 System.Policy.Security.Evidence 실제 호출 어셈블리의 개체를 사용합니다. 이 경우 BizTalk 서비스가 다시 시작될 때까지 삭제되지 않는 루팅된 개체가 만들어집니다.

대부분의 기본 BizTalk functoids 는 인라인 스크립트로 구현됩니다. 이러한 항목으로 인해 System.Byte[] 개체가 메모리에서 수집될 수 있습니다. 메모리 사용을 최소화하려면 이를 functoids 사용하는 모든 맵을 작은 어셈블리에 배치하는 것이 좋습니다. 그런 다음 해당 어셈블리를 참조합니다. 다음 차트를 사용하여 인라인 스크립트를 사용하는 항목과 인라인 스크립트를 사용하지 않는 스크립트를 functoids 결정 functoids 합니다.

두 번째 열에서 예 는 인 functoid 라인 스크립트로 구현되고 개체가 메모리에서 수집되도록 System.Byte[] 한다는 것을 의미합니다. 아니요 는 인 functoid 라인 스크립트로 구현되지 않으며 개체가 메모리에서 수집되지 않음을 의미합니다 System.Byte[] .

펑 토이 드 인라인 스크립트?
모든 문자열 펑토이드 예
모든 수학 펑토이드 예
IsNil을 제외한 모든 논리 펑토이드 예
논리 IsNil 펑토이드 아니오
모든 날짜/시간 펑토이드 예
모든 변환 펑토이드 예
모든 공학용 펑토이드 예
모든 누적 펑토이드 예
모든 데이터베이스 펑토이드 아니오
고급 펑토이드 인라인 스크립트?
루핑 펑토이드 아니오
펑토이드 평면화 Value-Mapping 아니오
Assert 펑토이드 아니오
테이블 추출기 펑토이드 아니오
테이블 루핑 펑토이드 아니오
인라인 C를 사용하여 펑토이드 스크립팅# 예
인라인 JScript.NET 펑토이드 스크립팅 예
인라인 Visual Basic .NET을 사용하여 펑토이드 스크립팅 예
인라인 XSLT를 사용하여 펑토이드 스크립팅 아니오
인라인 XSLT 호출 템플릿을 사용하여 펑토이드 스크립팅 아니오
외부 어셈블리를 호출하는 펑토이드 스크립팅 아니오
Nil 값 펑토이드 아니오
값 매핑 펑토이드 아니오
매스 카피 펑토이드 아니오
반복 펑토이드 아니오
Index 펑토이드 아니오
레코드 수 펑토이드 아니오

BizTalk Server 2006 이상 버전은 대용량 문서의 메모리 관리를 크게 개선합니다. 이를 위해 BizTalk Server 변환 작업 중에 문서를 메모리에 로드하기 위한 구성 가능한 메시지 크기 임계값을 구현합니다. 기본 메시지 크기 임계값은 1MB입니다. TransformThreshold 설정에 대한 자세한 내용은 BizTalk Server 대용량 메시지를 처리하는 방법을 참조하세요.

큰 특성 값 및 큰 요소 값

BizTalk Server XML 문서에서 수신 파이프라인 또는 송신 파이프라인을 실행하면 문서에 다음 엔터티가 하나 이상 포함된 경우 페이로드가 메모리에서 처리됩니다.

  • 큰 특성 값
  • 큰 요소 값
  • 큰 특성 또는 요소 태그

이 문제를 resolve 하려면 이러한 엔터티의 크기를 제한합니다. 이 메서드를 사용할 수 없는 경우 BizTalk HOST instance 같은 여러 문서를 동시에 처리하지 않는지 확인합니다.

사용자 지정 파이프라인 구성 요소

전체 스트림을 메모리에 로드하는 사용자 지정 파이프라인 구성 요소를 사용하고 있습니다. 변환을 제외한 BizTalk Server 포함된 모든 구성 요소는 스트리밍을 지원합니다. 이러한 구성 요소는 스트리밍 중에 많은 메모리를 사용하지 않습니다. 그러나 사용자 지정 파이프라인 구성 요소는 스트리밍을 지원하지 않을 수 있습니다.

스트레스가 많은 스트리밍

송신 호스트는 스트레스가 많은 상태에서 작동할 때 메모리가 부족합니다. BizTalk Server 파이프라인을 보내고 어댑터에서 스트리밍을 지원합니다. 스트리밍에서 각 구성 요소는 스트림의 작은 조각을 메모리에 로드합니다. 각 메시지에는 중요하거나 작을 수 있는 메시지 컨텍스트와 함께 다른 데이터 구조가 포함되어 있으므로 이 동작은 스트레스가 많은 BizTalk Server 동작에 영향을 줍니다.

엔진이 미리 구성된 메시지 수를 로드하기 때문에 BizTalk Server 동작이 영향을 받습니다. 엔진이 로드하는 메시지 수는 테이블의 LowWaterMark 필드와 HighWaterMark 필드에 표시되는 값을 기반으로 합니다.Adm_serviceClass 테이블은 Adm_serviceClass BizTalk 관리 데이터베이스에 있습니다. 이러한 값은 BizTalk Server 동시에 처리하거나 보내는 메시지 수를 제어합니다.

HighWaterMark 값은 엔진이 동시에 처리하는 총 메시지 수입니다. 기본값은 CPU당 200개 메시지입니다. 따라서 8 프로세서 서버에서 송신 호스트는 동시에 1,600개 메시지(200 * 8)를 처리하려고 시도합니다.

각 메시지가 50KB라고 가정하는 경우 메시지는 80MB(1,600 * 50=80,000KB)와 같습니다.

이 문제를 resolve 위해 데이터베이스에서 HighWaterMark 값과 LowWaterMark 값을 변경할 수 있습니다. 사용하는 값은 메시지의 크기에 따라 달라집니다. BizTalk Server 2006 이상 버전의 경우 기본 호스트 제한 설정을 변경할 수 있습니다.

문제를 단순화해 보세요.

메모리 누수가 확인된 경우 사용자 지정 구성 요소를 제거하거나 맵을 단순화하여 원인을 확인합니다. 또한 간단한 오케스트레이션 또는 간단한 솔루션을 사용하여 문제를 재현해 보세요. 일반적으로 수신 어댑터에 대한 별도의 수신 호스트를 만들어야 합니다. 또한 송신 어댑터에 대한 별도의 송신 호스트를 만들어야 합니다. 이 메서드를 사용하는 경우 각 어댑터는 별도의 프로세스에서 실행할 수 있습니다. 따라서 BizTalk Server 프로세스에 메모리 부족 상태가 발생하는 경우 관련된 구성 요소를 알 수 있습니다.

문제 해결 단계

메모리 부족 상태를 해결하려면 디버그 진단 도구를 사용하여 시간이 지남에 따라 메모리 할당을 모니터링합니다. 디버그 진단 도구는 메모리 누수 덤프 파일(.dmp)을 만들고 분석할 수 있습니다. 메모리 누수 문제를 해결할 때 목표는 높은 메모리 조건이 재현되기 전에 Leaktrack.dll 연결하여 시간이 지남에 따라 메모리 증가를 캡처하는 것입니다. Leaktrack.dll 디버그 진단 도구에 포함되어 있습니다.

  1. 디버그 진단 도구를 설치합니다.

    다음 파일은 Microsoft 다운로드 센터에서 다운로드할 수 있습니다.
    지금 디버그 진단 도구 패키지 다운로드

    Microsoft 지원 파일을 다운로드하는 방법에 대한 자세한 내용은 온라인 서비스 Microsoft 지원 파일을 가져오는 방법을 참조하세요.

    Microsoft는 이 파일에서 바이러스를 검사했습니다. Microsoft는 파일이 게시된 날짜에 사용할 수 있는 최신 바이러스 감지 소프트웨어를 사용했습니다. 파일은 파일에 대한 무단 변경을 방지하는 데 도움이 되는 보안 강화 서버에 저장됩니다.

  2. 성능 모니터 사용하여 시스템 성능에 대한 데이터를 수집합니다. 이 데이터는 BizTalk Server 환경의 효율성에 대한 중요한 지표를 제공할 수 있습니다. 목표는 시간이 지남에 따라 프로세스 성능을 캡처하는 것입니다. 따라서 메모리 누수가 발생하기 전에 성능 모니터 로깅을 사용하도록 설정합니다.

성능 모니터 로깅을 사용하는 방법

다음 섹션에서는 성능 모니터 로깅을 사용하는 방법을 설명합니다.

기록할 데이터 선택

로그할 데이터를 선택하려면 운영 체제에 적합한 메서드를 사용합니다.

  • Windows Server 2008 및 Windows Server 2008 R2의 경우

    1. 관리 도구에서 안정성 및 성능 모니터 엽니다.

    2. 성능 모니터 마우스 오른쪽 단추로 클릭하고 새로 만들기를 클릭한 다음 데이터 수집기 집합을 클릭합니다.

    3. 이름 상자에 설명이 포함된 이름을 입력하고 다음을 클릭합니다.

    4. 루트 디렉터리를 적어 두고 다음을 클릭합니다.

    5. 지금 이 데이터 수집기 집합 시작을 클릭한 다음 마침을 클릭합니다.

    6. 데이터 수집기 집합을 확장하고 사용자 정의 를 확장한 다음 파일을 선택합니다.

    7. 시스템 모니터 로그를 마우스 오른쪽 단추로 클릭한 다음 속성을 클릭합니다.

    8. 성능 카운터 탭에서 추가를 클릭합니다. 다음 개체를 선택한 다음, 각 개체를 선택한 후 추가를 클릭합니다.

      • .Net CLR 예외
      • .Net CLR 메모리
      • BizTalk: 메시징
      • BizTalk: TDDS
      • 메모리
      • 프로세스
      • 프로세서
      • XLANG/s 오케스트레이션

      SQL Server 로컬인 경우 다음 개체도 추가합니다.

      • SQLServer: 데이터베이스
      • SQLServer: 일반 통계
      • SQLServer: 메모리 관리자

    9. 확인을 클릭합니다.

    10. 샘플 간격 값 상자를 5초로 변경합니다.

      참고

      샘플 간격 값과 모니터링을 시작하는 시간은 주관적입니다. 이러한 값은 메모리 누수가 재현되는 시기에 따라 달라집니다. 로그 파일이 클 수 있으므로 서버를 압도하지 않고 필요한 정보를 가져올 수 있는 간격을 지정합니다.

    11. 확인을 클릭합니다.

데이터 수집을 중지하려면 작업 메뉴에서 중지를 클릭합니다.

  • Windows Server 2003 또는 Windows XP의 경우

    1. 성능 로그 및 경고를 확장합니다.

    2. 카운터 로그를 마우스 오른쪽 단추로 클릭한 다음 새 로그 설정을 클릭합니다. 새 로그 설정 대화 상자가 나타납니다.

    3. 이름 상자에 설명이 포함된 이름을 입력한 다음 확인을 클릭합니다.

    4. 로그 파일 위치를 확인합니다. 로그 파일 탭을 클릭한 다음 구성 을 클릭하여 로그 파일 위치를 변경할 수도 있습니다.

    5. 카운터 추가를 클릭합니다.

    6. 모든 카운터 및 모든인스턴스를 선택합니다.

    7. 성능 개체 목록에서 다음 개체를 선택합니다. 각 개체를 선택한 후 추가 를 클릭합니다.

      • .Net CLR 예외
      • .Net CLR 메모리
      • BizTalk: 메시징
      • BizTalk: TDDS
      • 메모리
      • 프로세스
      • 프로세서
      • XLANG/s 오케스트레이션

      SQL Server 로컬인 경우 다음 개체도 추가합니다.

      • SQLServer: 데이터베이스
      • SQLServer: 일반 통계
      • SQLServer: 메모리 관리자

    8. 닫기를 클릭합니다.

    9. 데이터 샘플링 간격의 값을 5초로 변경합니다.

      참고

      데이터 샘플링 간격 값과 모니터링을 시작하는 시간은 주관적입니다. 이러한 값은 메모리 누수가 재현되는 시기에 따라 달라집니다. 로그 파일이 클 수 있으므로 서버를 압도하지 않고 필요한 정보를 가져올 수 있는 간격을 지정합니다.

    10. 확인을 클릭합니다. 데이터 수집을 중지하려면 카운터 로그의 이름을 마우스 오른쪽 단추로 클릭한 다음 중지를 클릭합니다.

덤프 파일 가져오기

덤프 파일을 가져오려면 다음 방법 중 하나를 사용합니다.

방법 1: 자동

DebugDiag를 사용하여 메모리 및 누수 처리 규칙을 만드는 것이 메모리 덤프를 캡처하는 데 권장되는 방법입니다. 메모리 및 핸들 누수 규칙은 Leaktrack.dll자동으로 연결됩니다. 메모리 할당을 추적하는 데 사용됩니다. 메모리 및 누수 처리 규칙을 만들려면 다음 단계를 수행합니다.

  1. 디버그 진단 도구 1.1을 시작합니다.

  2. 메모리 및 누수 처리를 선택하고 다음을 클릭합니다.

  3. Btsntsvc.exe 프로세스를 선택하고 다음을 클릭합니다.

  4. 누수 규칙 구성 페이지에서 다음 단계를 수행합니다.

    1. 규칙을 활성화할 때 즉시 메모리 추적 시작 검사 상자를 클릭하여 선택합니다. 그렇지 않으면 BTSNTSvc.exe 프로세스에 LeakTrack.dll 삽입하기 전에 준비 시간을 지정할 수 있습니다.

    2. 구성을 클릭한 다음 다음을 수행합니다.

      • 충돌 규칙 자동 만들기가 선택되어 있는지 확인합니다. 이 옵션을 선택하면 BTSNTSvc.exe 프로세스가 중지되면 메모리 덤프가 자동으로 만들어집니다.

      • 가상 바이트가 검사 도달하면 사용자덤프 생성 상자를 클릭하고 기본값인 1024를 유지합니다.

      • 및 각 추가 검사 상자를 선택하고 기본값인 200을 유지하려면 클릭합니다. 가상 바이트 도달률 옵션을 선택하면 가상 바이트가 1024MB를 사용할 때 메모리 덤프가 자동으로 만들어집니다. 가상 바이트가 200MB 증가하면 다른 메모리 덤프가 자동으로 만들어집니다.

    3. 저장 후 닫기를 클릭합니다.

    4. 다음을 클릭합니다.

    5. 덤프 위치 및 규칙 이름 선택 페이지에서 다음을 클릭합니다.

      참고

      이 페이지의 Userdump 위치 상자에서 덤프 파일의 경로를 변경할 수도 있습니다.

    6. 마침을 클릭하여 규칙을 지금 활성화합니다.

      참고

      상태 규칙은 이제 추적입니다. 메모리 덤프를 만들 때마다 규칙 탭의 Userdump Count 열에서 값이 증가합니다. 기본 메모리 덤프 위치는 입니다C:\Program Files\DebugDiag\Logs.

방법 2: 수동

Leaktrack.dll 수동으로 연결하고 메모리 덤프 파일을 수동으로 가져올 수도 있습니다. 이렇게 하면 메모리 덤프가 만들어지는 시기를 제어할 수 있습니다. 이렇게 하려면 다음과 같이 하십시오.

  1. 디버그 진단 도구 1.1을 시작합니다.
  2. 프로세스 탭을 클릭합니다.
  3. Btsntsvc.exe 프로세스를 마우스 오른쪽 단추로 클릭한 다음 누출 모니터링을 클릭합니다.
  4. 진단 도구 디버그 대화 상자에서 예를 클릭한 다음 확인을 클릭합니다.

메모리 덤프를 만들기 전에 프로세스가 중지되는 경우 동일한 Btsntsvc.exe 프로세스를 모니터링하도록 크래시 규칙을 Create.

  1. 디버그 진단 도구 1.1을 시작합니다.
  2. 크래시 를 선택한 다음, 다음을 클릭합니다.
  3. 특정 프로세스를 선택하고 다음을 클릭합니다.
  4. 동일한 Btsntsvc.exe 프로세스를 선택하고 다음을 클릭합니다.
  5. 고급 구성(선택 사항) 페이지에서 다음을 클릭합니다.
  6. 덤프 위치 및 규칙 이름 선택(선택 사항) 대화 상자에서 다음을 클릭합니다.
  7. 지금 규칙 활성화를 선택한 다음 마침을 클릭합니다.

프로세스가 RAM의 60%에서 80%에 도달하면 Btsntsvc.exe 프로세스를 마우스 오른쪽 단추로 클릭한 다음 전체 userdump Create 클릭합니다. 사용자 덤프를 만들기 전에 BizTalk 프로세스가 중지되면 크래시 규칙이 적용되어 메모리 덤프를 만들어야 합니다.

성능 모니터 로깅 중지

메모리 덤프를 캡처하고 데이터를 성능 모니터 경우 메모리 덤프를 만든 후 약 2분 후에 성능 모니터 로깅을 중지합니다.

덤프 파일 분석

메모리 누수의 원인을 파악하기 위해 디버그 진단 도구를 사용하여 덤프 파일을 분석할 수 있습니다. 이렇게 하려면 다음과 같이 하십시오.

  1. 고급 분석 탭을 클릭합니다.
  2. 데이터 파일 추가를 클릭한 다음 .dmp 파일을 찾습니다.
  3. 메모리 압력 분석 스크립트를 선택한 다음 분석 시작을 클릭합니다.

기본적으로 분석 보고서 파일(.mht 파일)은 분석이 완료되면 폴더에 C:\Program Files\DebugDiag\Reports 만들어집니다. 보고서 파일도 브라우저에 표시됩니다. 보고서 파일에는 분석 결과가 포함됩니다. 또한 보고서 파일에는 메모리 누수를 resolve 방법에 대한 권장 사항이 포함될 수 있습니다.

사용자 지정 DLL을 사용하는 경우 분석을 위해 사용자 지정 .pdb 파일의 기호 경로를 추가할 수 있습니다. 이렇게 하려면 다음과 같이 하십시오.

  1. 디버그 진단 도구를 엽니다.
  2. 도구 메뉴에서 옵션 및 설정을 클릭합니다.
  3. 디버깅할 기호 Search 경로 상자에 기호 경로를 입력합니다.

덤프 파일을 분석하는 데 도움이 되도록 Microsoft 고객 지원 서비스에 문의하세요. 고객 지원 서비스 전화 번호의 전체 목록과 지원 비용에 대한 정보는 고객 지원에 문의하세요.

고객 지원 서비스에 문의하기 전에 덤프 파일, 성능 모니터 로그, 분석 보고서 파일 및 업데이트된 이벤트 로그(.evt 파일)를 압축합니다. 이러한 파일을 BizTalk Server 지원 엔지니어에게 보내야 할 수 있습니다.