BizTalk Server プロセスでメモリ リークまたはメモリ不足例外のトラブルシューティングを行う方法

  • [アーティクル]

この記事では、Microsoft BizTalk Server のBizTalk Server プロセスでメモリ リークまたはメモリ不足例外のトラブルシューティングを行う方法について説明します。

元の製品バージョン: BizTalk Server 2010、2009
元の KB 番号: 918643

概要

メモリ リークは一般的な問題です。 Microsoft BizTalk Serverでメモリ リークまたはメモリ不足 (OOM) 例外の特定の原因を見つけるには、いくつかの手順を試す必要があります。 この記事では、メモリ使用量と考えられるメモリ関連の問題を評価する際に考慮すべき重要事項について説明します。 これらの考慮事項には、次のものが含まれます。

  • 物理 RAM
  • 大きなメッセージ処理
  • /3 GB スイッチの使用
  • カスタム コンポーネントの使用
  • システムが実行されている Microsoft .NET Frameworkのバージョン
  • プロセッサ数

BizTalk Server プロセスでは、Microsoft Windows タスク マネージャーのメモリ使用量が物理 RAM の 50% を超えると、メモリ リークが発生している可能性があります。 メモリ リークは、プロセスがシステム メモリを使い切るか、プロセスの機能が停止するまでメモリ使用量が増加すると、メモリ不足例外を引き起こす可能性があります。 この問題については、次の点を考慮してください。

物理 RAM とメモリ使用量

プロセスで物理 RAM の約半分を使用する場合は動作が予想される場合があるため、メモリ使用量をガイドラインとして使用します。 たとえば、BizTalk Serverに 4 ギガバイト (GB) の RAM があり、BizTalk Server プロセスで約 500 MB (MB) の RAM が使用されている場合、リークが発生しない可能性があります。 BizTalk Server プロセスで約 1 GB の RAM が使用されている場合は、メモリ リークや高いメモリ状態が発生する可能性があります。 メモリ消費量は、実行時間の長いストアド プロシージャまたはオーケストレーションによって発生する可能性があります。 BizTalk ホストが通常使用するメモリ量を確認して、メモリ リークまたは高いメモリ状態が発生しているかどうかを判断します。

大きなメッセージ

BizTalk Serverが大きなメッセージを処理すると、システムにメモリ リークが発生しているようです。 ただし、メッセージは大量のメモリを使用している可能性があります。

また、BizTalk Serverが大きなメッセージを処理している場合は、メモリ使用量が多くなる可能性があることを考慮してください。 ハードウェアをアップグレードして、環境内のBizTalk Serverのパフォーマンス要件を満たすことができます。

メモリ リークの再現にかかる時間

メモリ リークは、すぐに発生したり、時間の経過と同時に蓄積したりする可能性があります。 どちらのシナリオも一般的です。

32 ビット コンピューターでの /3 GB スイッチの使用

通常、プロセスは 2 GB の仮想アドレス空間にアクセスできます。 /3 GB スイッチは、よりアドレス可能なメモリを必要とするシステムのオプションです。 このオプションを使用すると、メッセージを処理するためのメモリ使用量が向上する可能性があります。 ただし、 /3 GB スイッチ では、カーネル モードの操作に対して 1 GB のアドレス指定可能なメモリのみが許可されます。 さらに、このスイッチにより、プール メモリが不足するリスクが高まる可能性があります。

32 ビット バージョンの Windows で /3 GB スイッチ が有効になっている場合、プロセスが大きなアドレスに対応している場合、プロセスは 3 GB の仮想アドレス空間にアクセスできます。 実行可能ファイルにイメージ ヘッダーに IMAGE_FILE_LARGE_ADDRESS_AWARE フラグが設定されている場合、プロセスは大きなアドレスで認識されます。 BizTalk プロセスはアドレスが大きいため、BizTalk は /3 GB スイッチの恩恵を受けます。

32 ビットの BizTalk ホスト インスタンスが 64 ビット バージョンの Windows (AMD64) で実行されている場合、BizTalk プロセスは、BizTalk が大きなアドレス対応であるため、4 GB のメモリ アドレス空間の恩恵を受けます。 そのため、メモリの高いアプリケーションを 64 ビット サーバーに移動するのが最適なソリューションになる場合があります。

64 ビット バージョンの Windows (AMD64) 上の 64 ビット BizTalk プロセスには、8 TB のアドレス可能メモリがあります。

また、プロセスで使用される仮想バイトとプライベート バイトも考慮する必要があります。 BizTalk ホスト インスタンス (.NET Framework アプリケーション) は、Virtual Bytes 値が 2 GB に達する前にメモリ不足エラーを受け取る可能性があります。 この状況は、32 ビット バージョンの Windows ( /3 GB スイッチなし) のプロセスでアドレス指定可能な最大メモリが 2 GB である場合でも発生する可能性があります。 この状況が発生する理由については、次の Microsoft Developer Network (MSDN) Web サイトを参照してください。
パフォーマンス監視の ASP.NET と管理者に警告するタイミング

/3 GB スイッチでは、BizTalk プロセスの最大プライベート バイトも 800 MB から 1800 MB に増加します。 /3 GB スイッチを有効に.NET Frameworkアプリケーションのパフォーマンスの詳細については、「第 17 章 - .NET アプリケーション パフォーマンスのチューニング」を参照してください。

次の表は、この情報をまとめたものであり、仮想バイトとプライベート バイトの実際の制限が含まれています。

プロセス Windows アドレス指定可能なメモリ (大きなアドレス対応プロセスを使用) 仮想バイトの実用的な制限 プライベート バイトの実用的な制限
32 ビット 32 ビット 2 GB 1400 MB 800 MB
32 ビット /3 GB の 32 ビット 3 GB 2400 MB 1800 MB
32 ビット 64 ビット 4 GB 3400 MB 2800 MB
64 ビット 64 ビット 8 TB 該当なし 該当なし

32 ビット Windows と 64 ビット Windows のアドレス指定可能メモリの詳細については、「Windows および Windows Server リリースのメモリ制限」を参照してください。

次の表に、さまざまなバージョンのBizTalk Serverに対する PAE と 3 GB のサポートを示します。

製品 Pae 3 GB
BizTalk Server 2004 はい いいえ
BizTalk Server 2006 はい はい
BizTalk Server 2006 R2 はい はい
BizTalk Server 2009 はい はい

BizTalk Serverを実行しているコンピューターのパフォーマンス要件を満たすために /3 GB スイッチを有効にする必要がある場合は、BizTalk グループにサーバーを追加することを検討してください。 これにより、メモリ集約型のホスト インスタンスをスケールアウトできます。

インターネット インフォメーション サービス (IIS) プロセス内で実行される BizTalk コンポーネントは、 /3 GB スイッチ が有効になっている場合にもメリットがあります。

/3 GB スイッチは、2.0 以降Windows SharePoint Servicesバージョンまたは 2003 SP2 以降のバージョンSharePoint Portal Server実行されているコンピューターではサポートされていません。 Windows Server 2003 /3 GB スイッチは、Windows SharePoint Services 2.0 以降のバージョン、または SharePoint Portal Server 2003 Service Pack 2 以降のバージョンではサポートされていません。

カスタム コンポーネントの使用

パイプラインやサービス コンポーネントなどのカスタム コンポーネントを使用する場合は、これらのコンポーネントの機能を把握しておく必要があります。 また、メモリ使用量に対するこれらのコンポーネントの潜在的な影響もわかっている必要があります。 一般的なメモリの問題は、コンポーネントがドキュメントを変換しているときに発生します。 変換操作は、メモリ集約型の操作です。 ドキュメントが変換されると、BizTalk Serverはメッセージ ストリームを BizTalk プロセス内の Microsoft .NET Framework XslTransform クラスに渡します。

もう 1 つの一般的な問題は、集中的な文字列操作がある場合に発生します。 集中的な文字列操作は、多くの思い出を消費する可能性があります。 パフォーマンスを向上させる方法の詳細については、「 マネージド コードのパフォーマンスの向上」を参照してください。

.NET Frameworkのバージョン

Microsoft .NET Framework 2.0 と .NET Framework 1.1 のメモリ動作は異なります。 そのため、結果が異なる場合があります。 .NET Frameworkを使用している場合は、最新の.NET Framework Service Pack 1 がインストールされていることを確認します。 このサービス パックは、いくつかの既知のメモリの問題に対処します。

プロセッサ数

共通言語ランタイム (CLR) には、次のガベージ コレクター (GC) があります。

  • Workstation (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
  • 値名: フレーバー
  • 値データ: wks

BizTalk 2004

次CRL HostのCreate対応する値を持つ文字列レジストリ キー:

  • キー: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BTSSvc{GUID }\CLR Hosting
  • 値名: フレーバー
  • 値データ: wks

詳細については、.NET Frameworkの「Run-Time テクノロジのパフォーマンスに関する考慮事項」を参照してください。

一般的な原因と解決策を次に示します。

プロセスと物理メモリ使用量の調整のしきい値

プロセス メモリ使用量と物理メモリ使用量調整のしきい値は、BizTalk Server 2006 以降のバージョンで変更できます。

  • 既定では、 プロセス メモリ使用量 調整のしきい値は 25 に設定されています。 この値を超え、BizTalk プロセスのメモリ使用量が 300 MB を超える場合は、調整条件が発生する可能性があります。 32 ビット サーバーでは、[プロセス メモリ使用量] の値を 50 に増やすことができます。 64 ビット サーバーでは、この値を 100 に増やすことができます。 これにより、調整が発生する前に BizTalk プロセスによるメモリ消費量を増やすことができます。

  • 物理メモリ使用量調整のしきい値の既定値は 0 です。 このしきい値は、システム メモリの合計を測定します。 したがって、0 以外の値が構成されている場合、BizTalk 以外のプロセスで高いメモリが使用されている場合、調整条件が発生する可能性があります。

脱水調整のしきい値

既定のメモリ退避しきい値は、オーケストレーションが 64 ビット ホストで実行されると、過剰な退避を引き起こす可能性があります。 この問題の詳細については、「 退避の既定のプロパティ」を参照してください。

注:

64 ビット ホストは、BizTalk Server 2006 以降のバージョンでサポートされています。

32 ビット ホスト インスタンス内の同等のハードウェアでは、既定のメモリ脱水調整のしきい値を使用して同じオーケストレーションを実行すると、観察された退避は公称です。

64 ビット アーキテクチャでは拡張メモリ アドレス空間 (4 GB ではなく 16 TB) が提供されるため、64 ビット ホスト インスタンスには 32 ビット ホスト インスタンスよりも多くのメモリが割り当てられます。 これにより、既定のメモリ調整しきい値を超える可能性があります。

この動作を回避するには、BTSNTSvc64.exe.config ファイルの VirtualMemoryThrottlingCriteria と PrivateMemoryThrottlingCriteria の値を変更します。 オーケストレーション インスタンスによって割り当てられているメモリの最大量を決定するには、\Process\Virtual Bytes カウンターと \Process\Private Bytes パフォーマンス モニター カウンターを使用します。

  • 次に基づいて、両方のプロパティの OptimalUsage 値を設定します。

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

  • 両方のプロパティの MaximalUsage を OptimalUsage 値 + 30% に設定します

たとえば、 オーケストレーション インスタンスの \Process\Virtual Byte パフォーマンス モニター カウンター値が 5,784,787,695 バイト (5,517 MB) の場合は、VirtualMemoryThrottlingC の OptimalUsage 値を設定します。 6,069 MB (5,784,787,695 * 1.10 = 6,363,266,464.5 バイト)。

VirtualMemoryThrottlingCriteria の MaxalUsage 値を 7,889 MB (6,363,266,464.5 * 1.30 = 8,272,246,403.85 バイト) に設定します。

\Process\Private Bytes パフォーマンス モニター カウンター値が 435689400 バイト (415 MB) の場合は、PrivateMemoryThrottlingCriteria の OptimalUsage 値を 457 MB (435689400 * 1.10 = 479258340 バイト) に設定します。

PrivateMemoryThrottlingCriteria の MaxalUsage 値を 594 MB (479258340 * 1.30 = 623035842) に設定します。

この例では、調整を減らすために、BTSNTSvc64.exe.config ファイルに次の値を指定します。

パフォーマンス モニター カウンター 割り当てられたメモリ OptimalUsage MaximalUsage
\Process\Virtual Bytes 5,784,787,695 バイト (5517 MB) 6069 7889
\Process\Private Bytes 435,689,400 バイト (415 MB) 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>

オーケストレーションを実行しているホスト インスタンスを特定するには、\BizTalk: Messaging\ID Process カウンターと \Process\ID Process パフォーマンス モニター カウンターから ID プロセスを照合できます。 次に、対応する \Process\Virtual Bytes カウンターと \Process\Private Bytes パフォーマンス モニター カウンターに表示される平均値をチェックします。

注:

スキミングした場合でもユーザーが気付く必要がある情報高い脱水は、データベースが 2008 年SQL Server実行されているときにBizTalkMsgBoxDbパフォーマンスが大幅に低下する可能性があります。

サービス パックと累積的な更新プログラムのBizTalk Server

BizTalk Serverサービス パックと累積的な更新プログラムには、最新の修正プログラムが含まれています。 これには、既知 System.OutOfMemoryException の問題に影響を与えるものが含まれます。

HeapDeCommitFreeBlockThreshold

既定では、レジストリ キーの HeapDeCommitFreeBlockThreshold 値は 0 です。 値 0 は、ヒープ マネージャーが使用可能になる各 4 KB (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 決定します。

2 番目の列の [はい ] は、これが functoid インライン スクリプトとして実装され、オブジェクトがメモリ内で収集されることを System.Byte[] 意味します。 これは インライン スクリプトとして実装されておらず、オブジェクトがメモリ内で収集されないことを意味 functoid しません System.Byte[] 。

Functoid インライン スクリプト?
すべての文字列 Functoid はい
すべての数学 Functoid はい
IsNil を除くすべての論理 Functoid はい
論理 IsNil Functoid いいえ
すべての日付/時刻 Functoid はい
すべての変換 Functoid はい
すべての科学 Functoid はい
すべての累積 Functoid はい
すべてのデータベース Functoid いいえ
Advanced Functoids インライン スクリプト?
ループ Functoid いいえ
Functoid のフラット化を Value-Mapping する いいえ
Assert Functoid いいえ
Table Extractor Functoid いいえ
テーブル ループ Functoid いいえ
インライン C を使用した Functoid のスクリプト化# はい
インライン JScript.NET を使用した Functoid のスクリプト化 はい
インライン Visual Basic .NET を使用した Functoid のスクリプト作成 はい
インライン XSLT を使用した Functoid のスクリプト化 いいえ
インライン XSLT 呼び出しテンプレートを使用した Functoid のスクリプト化 いいえ
外部アセンブリを呼び出す Functoid スクリプト いいえ
Nil Value Functoid いいえ
値マッピング Functoid いいえ
一括コピー Functoid いいえ
イテレーション Functoid いいえ
インデックス Functoid いいえ
レコード数 Functoid いいえ

BizTalk Server 2006 以降のバージョンでは、大規模なドキュメントのメモリ管理が大幅に向上します。 これを行うには、BizTalk Server変換操作中にドキュメントをメモリに読み込むための構成可能なメッセージ サイズのしきい値を実装します。 既定のメッセージ サイズのしきい値は 1 MB です。 TransformThreshold 設定の詳細については、「大きなメッセージを処理BizTalk Server方法」を参照してください。

大きな属性値と大きな要素の値

BizTalk Server XML ドキュメントで受信パイプラインまたは送信パイプラインを実行すると、ドキュメントに次のエンティティが 1 つ以上含まれている場合、ペイロードはメモリ内で処理されます。

  • 大きな属性値
  • 大きな要素の値
  • 大きな属性タグまたは要素タグ

この問題を解決するには、これらのエンティティのサイズを制限します。 このメソッドが不可能な場合は、BizTalk HOST インスタンスがこのような複数のドキュメントを同時に処理しないようにしてください。

カスタム パイプライン コンポーネント

ストリーム全体をメモリに読み込むカスタム パイプライン コンポーネントを使用しています。 変換を除く、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) を処理しようとします。

各メッセージが 50 KB であると仮定した場合、メッセージは 80 MB (1,600 * 50=80,000 KB) になります。

この問題を解決するには、データベースの 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. [OK] をクリックします。

    10. [ サンプル間隔] の値 ボックスを 5 秒に変更します。

      注:

      [サンプル間隔] の値と監視を開始する時間は主観的です。 これらの値は、メモリ リークが再現されるタイミングによって異なります。 ログ ファイルは大きくなる可能性があるため、サーバーを圧倒することなく、必要な情報を取得できる間隔を指定します。

    11. [OK] をクリックします。

データの収集を停止するには、[アクション] メニューの [停止] をクリックします。

  • Windows Server 2003 または Windows XP の場合

    1. [ パフォーマンス ログとアラート] を展開します。

    2. [カウンター ログ] を右クリックし、[新しいログ設定] をクリックします。 [ 新しいログ設定] ダイアログ ボックスが表示されます。

    3. [ 名前 ] ボックスにわかりやすい名前を入力し、[OK] をクリック します。

    4. ログ ファイルの場所をメモします。 ([ ログ ファイル ] タブをクリックし、[ 構成 ] をクリックしてログ ファイルの場所を変更することもできます)。

    5. [ カウンターの追加] をクリックします。

    6. [ すべてのカウンター] と [ すべてのインスタンス] を選択します。

    7. [ パフォーマンス オブジェクト ] の一覧で、次のオブジェクトを選択します。 各オブジェクトを選択した後、[ 追加] をクリックします。

      • .Net CLR の例外
      • .Net CLR メモリ
      • BizTalk: メッセージング
      • BizTalk: TDDS
      • メモリ
      • プロセス
      • プロセッサ
      • XLANG/s オーケストレーション

      SQL Serverがローカルの場合は、次のオブジェクトも追加します。

      • SQLServer: データベース
      • SQLServer: 一般的な統計
      • SQLServer: メモリ マネージャー

    8. [閉じる] をクリックします。

    9. [データ サンプリング間隔] の値を 5 秒に変更します。

      注:

      データ サンプリング間隔の値と監視を開始する時間は主観です。 これらの値は、メモリ リークが再現されるタイミングによって異なります。 ログ ファイルは大きくなる可能性があるため、サーバーを圧倒することなく、必要な情報を取得できる間隔を指定します。

    10. [OK] をクリックします。 データの収集を停止するには、カウンター ログの名前を右クリックし、[ 停止] をクリックします。

ダンプ ファイルを取得する

ダンプ ファイルを取得するには、次のいずれかの方法を使用します。

方法 1: 自動

メモリ ダンプをキャプチャするには、DebugDiag を使用してメモリ リーク ルールとハンドル リーク ルールを作成することをお勧めします。 メモリリークルールとハンドルリークルールは、Leaktrack.dllを自動的にアタッチします。 これは、メモリ割り当てを追跡するために使用されます。 メモリとハンドル リークルールを作成するには、次の手順に従います。

  1. デバッグ診断ツール 1.1 を起動します。

  2. [ メモリ] と [ハンドル リーク] を選択し、[ 次へ] をクリックします。

  3. Btsntsvc.exe プロセスを選択し、[ 次へ] をクリックします。

  4. [ リーク ルールの構成] ページで、次の手順を実行します。

    1. [ルールがアクティブになったときにすぐにメモリ追跡を開始する] ボックスチェック選択します。 それ以外の場合は、 BTSNTSvc.exe プロセスにLeakTrack.dll が挿入されるまでのウォームアップ時間を指定できます。

    2. [ 構成] をクリックし、次の操作を行います。

      • [クラッシュ ルールの自動作成] が選択されていることを確認します。 このオプションを選択すると、BTSNTSvc.exe プロセスが停止すると、メモリ ダンプが自動的に作成されます。

      • [仮想バイトがチェックに達したときにユーザー ダンプを生成する] ボックスをクリックして選択し、既定値は 1024 のままにします。

      • をクリックして、追加の各チェック ボックスを選択し、既定値の 200 のままにします。 仮想バイト到達オプションを選択すると、仮想バイトが 1024 MB を使用すると、メモリ ダンプが自動的に作成されます。 仮想バイトが 200 MB 増加すると、別のメモリ ダンプが自動的に作成されます。

    3. [保存して閉じる] をクリックします。

    4. [次へ] をクリックします。

    5. [ ダンプの場所とルール名の選択 ] ページで、[ 次へ] をクリックします。

      注:

      このページの [ ユーザーダンプの場所 ] ボックスでダンプ ファイルのパスを変更することもできます。

    6. [ 完了] をクリックして、ルールを今すぐアクティブにします。

      注:

      ルールの状態が [追跡] になりました。 メモリ ダンプが作成されるたびに、[ルール] タブの [Userdump Count]\(ユーザーダンプ数\) 列の値が増加します。既定のメモリ ダンプの場所は ですC:\Program Files\DebugDiag\Logs。

方法 2: 手動

Leaktrack.dll を手動でアタッチし、メモリ ダンプ ファイルを手動で取得することもできます。 これにより、メモリ ダンプを作成するタイミングを制御できます。 これを行うには、次の手順を実行します。

  1. デバッグ診断ツール 1.1 を起動します。
  2. [プロセス] タブをクリックします。
  3. Btsntsvc.exe プロセスを右クリックし、[ リークの監視] をクリックします。
  4. [ 診断ツールのデバッグ ] ダイアログ ボックスで、[ はい] をクリックし、[OK] をクリック します。

メモリ ダンプを作成する前にプロセスが停止した場合に備えて、同じ Btsntsvc.exe プロセスを監視するクラッシュ ルールをCreateします。

  1. デバッグ診断ツール 1.1 を起動します。
  2. [ クラッシュ] を選択し、[ 次へ] をクリックします。
  3. 特定のプロセスを選択し、[ 次へ] をクリックします。
  4. 同じ Btsntsvc.exe プロセスを選択し、[ 次へ] をクリックします。
  5. [ 詳細設定 (省略可能)] ページで 、[ 次へ] をクリックします。
  6. [ ダンプの場所と規則名の選択 (省略可能)] ダイアログ ボックスで、[ 次へ] をクリックします。
  7. [ 今すぐルールをアクティブ化する] を選択し、[完了] をクリック します。

プロセスが RAM の 60% から 80% に達したら、Btsntsvc.exe プロセスを右クリックし、[フル ユーザー ダンプのCreate] をクリックします。 ユーザー ダンプを作成する前に BizTalk プロセスが停止した場合、クラッシュ ルールが有効になり、メモリ ダンプが作成されます。

ログのパフォーマンス モニターを停止する

メモリ ダンプをキャプチャし、データをパフォーマンス モニターする場合は、メモリ ダンプが作成されてから約 2 分後にパフォーマンス モニターログ記録を停止します。

ダンプ ファイルを分析する

メモリ リークの原因を特定するために、デバッグ診断ツールを使用してダンプ ファイルを分析できます。 これを行うには、次の手順を実行します。

  1. [ 高度な分析 ] タブをクリックします。
  2. [ データ ファイルの追加] をクリックし、.dmp ファイルを見つけます。
  3. [メモリ圧力分析] スクリプトを選択し、[分析の開始] をクリックします。

既定では、分析が完了すると、分析レポート ファイル (.mht ファイル) がフォルダーに作成 C:\Program Files\DebugDiag\Reports されます。 レポート ファイルはブラウザーにも表示されます。 レポート ファイルには、分析の結果が含まれています。 さらに、レポート ファイルには、メモリ リークを解決する方法に関する推奨事項が含まれている場合があります。

カスタム DLL を使用する場合は、分析のためにカスタム .pdb ファイルのシンボル パスを追加できます。 これを行うには、次の手順を実行します。

  1. デバッグ診断ツールを開きます。
  2. [ ツール ] メニューの [ オプションと設定] をクリックします。
  3. [シンボル Search デバッグ用パス] ボックスに、シンボル パスを入力します。

ダンプ ファイルの分析に関するヘルプが必要な場合は、Microsoft カスタマー サポート サービスにお問い合わせください。 カスタマー サポート サービスの電話番号とサポート コストに関する情報の完全な一覧については、 サポートにお問い合わせください。

カスタマー サポート サービスに問い合わせる前に、ダンプ ファイル、パフォーマンス モニター ログ、分析レポート ファイル、更新されたイベント ログ (.evt ファイル) を圧縮します。 これらのファイルは、BizTalk Server サポート エンジニアに送信する必要がある場合があります。