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 に 4 ギガバイト (GB) の RAM があり、BizTalk Server プロセスで約 500 メガバイト (MB) の RAM が使用されている場合、リークが発生しない可能性があります。 BizTalk Server プロセスで約 1 GB の RAM を使用している場合は、メモリ リークやメモリの高い状況が発生する可能性があります。 メモリ消費量は、実行時間の長いストアド プロシージャまたはオーケストレーションによって発生する可能性があります。 BizTalk ホストがメモリ リークまたは高いメモリ状態が発生しているかどうかを判断するために通常使用されるメモリの量を確認してください。

大きいメッセージ

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

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

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

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

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

通常、プロセスは 2 GB の仮想アドレス空間にアクセスできます。 /3GB スイッチは、よりアドレス指定可能なメモリを必要とするシステムのオプションです。 このオプションを使用すると、メッセージを処理するためのメモリ使用量が向上する可能性があります。 ただし、 /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 アプリケーション) は、仮想バイト数の値が 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 アプリケーションのパフォーマンスの詳細についてはChapter 17 - .NET アプリケーションパフォーマンスのチューニングを参照してください。

次の表に、この情報を要約し、仮想バイトとプライベート バイトの実際の制限を示します。

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

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

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

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

/3 GB スイッチは、Windows SharePoint Services 2.0 以降のバージョンまたは SharePoint Portal Server 2003 SP2 以降のバージョンを実行しているコンピューターではサポートされていません。 Windows Server 2003 /3GB スイッチは、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) があります。

• ワークステーション (Mscorwks.dll)
• サーバー (Mscorsvr.dll)

BizTalk Server を実行しているコンピューターがマルチプロセッサ システムである場合、.NET Framework はサーバー バージョンの実行エンジンを使用します。 これが既定の動作です。 サーバー ガベージ コレクターは、最大スループット用に設計されています。 さらに、サーバー ガベージ コレクターは、高いパフォーマンスを提供するようにスケーリングします。 このガベージ コレクターはメモリを割り当て、後でメモリを解放して、システムで高いパフォーマンスを提供します。 そのため、BizTalk Server を一部の .NET Framework コンポーネントと共に実行しているコンピューターでは、メモリ リークが発生しているようです。 ただし、このシナリオでは、高いメモリ使用量が予想される動作です。 コンピューターがシステム メモリを使い切った場合、またはアドレス指定可能なメモリが不足しているためにプロセスの動作が停止した場合、メモリ リーク状態が存在する可能性があります。

BizTalk Server を実行しているコンピューターが 1 つのプロセッサ システムである場合、.NET Framework はワークステーション バージョンの実行エンジンを使用します。 これは既定の動作です。 ワークステーション ガベージ コレクターの割り当てアルゴリズムは、スケーリングまたは最大スループット用に設計されていません。 このガベージ コレクターは、同時実行ガベージ コレクター メソッドを使用します。 これらのメソッドは、複雑なユーザー インターフェイスを持つアプリケーション向けに設計されています。 このようなアプリケーションでは、より積極的なガベージ コレクションが必要になる場合があります。

場合によっては、マルチプロセッサ システムで実行エンジンのワークステーション バージョンを実行することが適切な場合があります。 次のレジストリ キーを使用して、実行エンジンのワークステーション バージョンに切り替えることができます。

BizTalk 2006 以降のバージョン

対応する値を使用して、次の CRL Hosting 文字列レジストリ キーを作成します。

• キー: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$BizTalkHostName\CLR Hosting
• 値の名前: Flavor
• 値データ: wks

BizTalk 2004

対応する値を使用して、次の CRL Host 文字列レジストリ キーを作成します。

• キー: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BTSSvc{GUID }\CLR Hosting
• 値の名前: Flavor
• 値データ: wks

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

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

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

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

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

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

脱水調整のしきい値

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

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) の場合は、VirtualMem の OptimalUsage 値を設定しますoryThrottlingCriteria から 6,069 MB (5,784,787,695 * 1.10 = 6,363,266,464.5 バイト)。

VirtualMemoryThrottlingCriteria の MaximalUsage 値を 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 の MaximalUsage 値を 594 MB (479258340 * 1.30 = 623035842) に設定します。

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

これらの値は、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 パフォーマンス モニター カウンターに対して表示される平均値を確認します。

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

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

HeapDeCommitFreeBlockThreshold

既定では、 HeapDeCommitFreeBlockThreshold レジストリ キーの値は 0 です。 値 0 は、ヒープ マネージャーが使用可能になる各 4 KB (KB) ページをコミット解除することを意味します。 コミット解除操作は、仮想メモリの断片化を引き起こす可能性があります。 ヒープ マネージャーの HeapDeCommitFreeBlockThreshold 設定のサイズは、システムが実行している作業の種類によって異なります。 0x00040000のサイズは、推奨される開始値です。

HeapDeCommitFreeBlockThreshold レジストリ キーの値を変更する前に、次の情報を考慮してください。

• この変更は、メモリ断片化の問題にのみ適用されます。
• この変更はシステム全体で行われます。 そのため、ほとんどのプロセスでは起動時により多くのメモリが使用されます。
• この変更は、BizTalk Server を主な使命とするシステムに対してのみ考慮してください。

仮想メモリの断片化を減らすために、ヒープ マネージャーの HeapDeCommitFreeBlockThreshold 設定のサイズを大きくするには、 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Managerの下にある次のレジストリ キーの値を変更します。

• 値の名前: 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 番目の列の Yes は、この functoid がインライン スクリプトとして実装され、 System.Byte[] オブジェクトがメモリに収集されることを意味します。 いいえ は、この functoid がインライン スクリプトとして実装されておらず、 System.Byte[] オブジェクトがメモリ内で収集されないことを意味します。

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 フィールドとAdm_serviceClass テーブルの HighWaterMark フィールドに表示される値に基づいています。 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 ダウンロード センターからダウンロードできます。
   デバッグ診断ツール パッケージを今すぐダウンロードする

   マイクロソフトのサポート ファイルをダウンロードする方法の詳細については、「オンライン サービスからマイクロソフトのサポート ファイルを入手する方法」を参照してください。

   4013443 「更新プログラムの表示または非表示」トラブルシューティング ツール パッケージマイクロソフトでは、アップロード時点の最新のウイルス検査プログラムを使用して、 配布ファイルのウイルス チェックを行っています。 配布ファイルはセキュリティで保護されたサーバー上に置かれており、権限のない第三者が無断でファイルを変更できないようになっています。 配布ファイルはセキュリティで保護されたサーバー上に置かれており、権限のない第三者が無断でファイルを変更できないようになっています。

2. パフォーマンス モニターを使用して、システムのパフォーマンスに関するデータを収集します。 このデータは、BizTalk Server 環境の効率に関する重要なインジケーターを提供する場合があります。 目標は、時間の経過と同時にプロセスのパフォーマンスをキャプチャすることです。 そのため、メモリ リークが発生する前にパフォーマンス モニターログ記録を有効にします。

パフォーマンス モニターログを使用する方法

次のセクションでは、パフォーマンス モニターのログ記録を使用する方法について説明します。

ログに記録するデータを選択する

ログに記録するデータを選択するには、オペレーティング システムに適した方法を使用します。

• Windows Server 2008 および Windows Server 2008 R2 の場合

  1. 管理ツールで、責任とパフォーマンス モニターを開きます。

  2. パフォーマンス モニターを右クリックし、[新規 ] をクリックし、[データ コレクター セット] をクリック。

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

  4. Root ディレクトリをメモし、[次へ] をクリック。

  5. [今すぐこのデータ コレクター セットを開始する]をクリックし、[完了] をクリックします。

  6. [データ コレクター セット 展開、 User Defined を展開し、ファイルを選択します。

  7. System Monitor ログを右クリックし、 Properties をクリックします。

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

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

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

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

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

  10. Sample Interval の値ボックスを 5 秒に変更。

      Note

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

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

データの収集を停止するには、Action メニューの Stop をクリックします。

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

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

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

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

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

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

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

  7. Performance オブジェクト一覧で、次のオブジェクトを選択します。 各オブジェクト 選択した後 [追加]をクリックします。

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

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

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

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

  9. Data サンプリング間隔の値を 5 秒に変更します。

     Note

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

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

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

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

方法 1: 自動

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

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

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

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

4. 構成リークルールページで、次の手順に従います。

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

   2. Configureをクリックし、次の操作を行います。

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

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

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

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

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

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

      Note

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

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

      Note

      ルールの状態が Tracking になりました。 メモリ ダンプが作成されるたびに、Rules タブの Userdump Count 列の値が増加します。既定のメモリ ダンプの場所はC:\Program Files\DebugDiag\Logs。

方法 2: 手動

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

1. デバッグ診断ツール 1.1 を起動します。
2. Processes タブをクリックします。
3. Btsntsvc.exe プロセスを右クリックし、[ Monitor For Leaks] をクリックします。
4. [Debug 診断ツール] ダイアログ ボックスで、[Yes] をクリックし、[OK] をクリック。

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

1. デバッグ診断ツール 1.1 を起動します。
2. Crash を選択し、[次へ] をクリック。
3. 特定のプロセスを選択し、[ 次へ] をクリックします。
4. 同じBtsntsvc.exe プロセスを選択し、[次へ ] をクリック。
5. [ Advanced 構成 (省略可能)] ページで、[次へ ] をクリック。
6. [ダンプの場所と規則の名前の選択 (省略可能)]] ダイアログ ボックスで、[次へ] をクリック。
7. [今すぐルールを有効にする] を選択し[完了]をクリック。

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

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

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

ダンプ ファイルの分析

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

1. [Advanced Analysis] タブをクリックします。
2. [データ ファイル 追加をクリックし、.dmp ファイルを見つけます。
3. Memory Pressure Analysis スクリプトを選択し、[分析の開始] をクリック。

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

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

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

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

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