DA0018: 32 ビット アプリケーションがプロセスのマネージ メモリ制限で実行されていますDA0018: 32-bit Application running at process managed memory limits

規則 IDRule Id DA0018DA0018
カテゴリCategory プロファイリング ツールの使用Profiling Tools Usage
プロファイル方法Profiling method サンプリングSampling
メッセージMessage マネージ メモリの割り当てが、32 ビット プロセスの既定の制限に近づいています。Managed memory allocations approaching the default limit for a 32-bit process. アプリケーションがメモリにより制限されている可能性があります。Your application could be memory-bound.
規則の種類Rule type 警告Warning

サンプリング、.NET メモリ、またはリソース競合メソッドを使用してプロファイリングを行うときは、この規則を呼び出すためのサンプルを少なくとも 10 個収集する必要があります。When you profile by using the sampling, .NET memory, or resource contention methods, you must collect at least 10 samples to trigger this rule.

原因Cause

プロファイリングの実行中に収集されたシステム データで、.NET Framework のメモリ ヒープが、32 ビット プロセスでマネージ ヒープが到達可能な最大サイズに近づいたことが示されています。System data collected during the profiling run indicates the .NET Framework memory heaps approached the maximum size that the managed heaps can reach in a 32-bit process. この最大サイズは既定値です。This maximum size is a default value. この値は、プライベート バイトに割り当てることのできるプロセス アドレス空間の総量に基づいて決まります。It is based on the total amount of the process address space that can be allocated for private bytes. 報告される値は、プロファイリング中のプロセスがアクティブな状態にあったときに測定されたヒープの最大値です。The value reported is the maximum observed value of the heaps while the profiled process was active. .NET メモリ プロファイル方法を使って再度プロファイリングを行い、アプリケーションによるマネージ リソースの使用を最適化することを検討してください。Consider profiling again using the .NET memory profiling method and optimizing the use of managed resources by the application.

マネージ ヒープのサイズが既定の制限値に達すると、自動ガベージ コレクション プロセスのより頻繁な呼び出しが必要になる場合があります。When the size of the managed Heaps approach the default limit, the automatic garbage collection process might have to be invoked more frequently. これにより、メモリ管理のオーバーヘッドが増加します。This increases the overhead of memory management.

この規則は、32 ビット コンピューター上で実行している 32 ビット アプリケーションに対してのみ適用されます。The Rule only fires for 32-bit applications running on 32-bit machines.

規則の説明Rule Description

Microsoft .NET 共通言語ランタイム (CLR: Common Language Runtime) は、自動メモリ管理メカニズムを備えています。このメカニズムでは、ガベージ コレクターを使用して、アプリケーションが使用しなくなったオブジェクトのメモリを解放します。The Microsoft .NET common language run-time (CLR) provides an automatic memory management mechanism that uses a garbage collector to reclaim memory from objects that the application no longer uses. ガベージ コレクターはジェネレーション指向です。これは、多くの割り当てが短時間で終了することを前提としています。The garbage collector is generation-oriented, based on the assumption that many allocations are short-lived. たとえば、ローカル変数の有効期間は短時間です。Local variables, for example, should be short-lived. 新しく作成されたオブジェクトはジェネレーション 0 (gen 0) から始まり、ガベージ コレクションの実行中に破棄されなければジェネレーション 1 に昇格します。その後もアプリケーションによって引き続き使用されていれば、最後はジェネレーション 2 に昇格します。Newly created objects start in generation 0 (gen 0), and then they progress to generation 1 when they survive a garbage collection run, and finally transition to generation 2 if the application still uses them.

85 KB より大きいマネージ オブジェクトは、小さいオブジェクトと比較し、ガベージ コレクションや圧縮が行われる頻度が少ない、大きなオブジェクト ヒープに割り当てられます。Managed objects that are larger than 85 KB are allocated on the Large Object Heap, where they are subject to less frequent garbage collection and compaction than smaller objects. 大きいオブジェクトは、より永続的であると想定されており、ヒープが悪い状態で断片化されないよう、頻繁に割り当てが行われる小さいオブジェクトと永続的な大きなオブジェクトは一緒にせず、別々に管理します。large objects are managed separately because it is assumed that they are more persistent and because mixing persistent and large objects with frequently allocated smaller objects can produce worst-cast fragmentation of the heap.

マネージ ヒープの合計サイズが既定の制限値に近づくと、通常、メモリ管理のオーバーヘッドが増加し、アプリケーションの応答性とスケーラビリティに影響するようになります。As the total size of the managed heaps approach the default limit, the overhead of memory management usually increases to the point where it can start to impact the responsiveness and scalability of the application.

警告の調査方法How to Investigate a Warning

[エラー一覧] ウィンドウに表示されたメッセージをダブルクリックして、[マーク] ビューに移動します。Double-click the message in the Error List window to navigate to the Marks view. .NET CLR Memory\# Bytes in all Heaps 列および # Total committed bytes 列を探します。Find the .NET CLR Memory\# Bytes in all Heaps and # Total committed bytes columns. マネージ メモリの割り当てが他のフェーズよりも多い特定のプログラム実行フェーズがあるかどうかを確認します。Determine if there are specific phases of program execution where managed memory allocation is heavier than other phases. # Bytes in all Heaps 列の値を、.NET CLR Memory\# of Gen 0 Collections.NET CLR Memory\# of Gen 1 Collections.NET CLR Memory\# of Gen 2 Collections の各列で報告されたガベージ コレクションの割合と比較し、マネージ メモリ割り当てのパターンがガベージ コレクションの割合に影響を与えるかどうかを確認します。Compare the values of the # Bytes in all Heaps column to the rate of garbage collection reported in the .NET CLR Memory\# of Gen 0 Collections, .NET CLR Memory\# of Gen 1 Collections, and .NET CLR Memory\# of Gen 2 Collections columns to determine if the pattern of managed memory allocations is affecting the rate of garbage collection.

.NET Framework アプリケーションでは、共通言語ランタイムによって、マネージ ヒープの合計サイズが、プロセス アドレス空間のプライベート領域部分の最大サイズの半分よりわずかに小さいサイズに制限されます。In a .NET Framework application, the common language runtime limits the total size of the managed heaps to slightly less than one-half of the maximum size of the private area portion of a process address space. 32 ビット コンピューター上で実行している 32 ビット プロセスの場合、プロセスのアドレス空間のプライベート領域の上限は 2 GB です。For a 32-bit processes running on a 32-bit machine, 2 GB represents the upper limit of the private portion of the process address space. マネージ ヒープの合計サイズがその既定の制限値に近づくと、マネージ メモリのオーバーヘッドが増加し、アプリケーションのパフォーマンスが低下する可能性があります。As the total size of the managed Heaps begins to approach its default limit, the overhead of managing memory might increase and application performance can decrease.

マネージ メモリの過剰なオーバーヘッドが問題になる場合は、次のいずれかの方法の実行を検討します。If excessive managed memory overhead is a problem, consider either of these options:

  • マネージ メモリ リソースのアプリケーションによる使用を最適化するoptimizing the application's usage of managed memory resources

    または-or-

  • 32 ビット プロセスの仮想メモリの最大サイズに関するアーキテクチャ上の制約を解除する手順を実行するtaking steps to relieve the architectural constraints on the maximum size of virtual memory for a 32-bit process

    マネージ メモリ リソースのアプリケーションによる使用を最適化するには、.NET メモリ割り当てのプロファイリングを実行して、マネージ メモリ割り当てデータを収集します。To optimize the application's usage of managed memory resources, gather managed memory allocation data in a .NET Memory Allocation profiling run. .NET メモリのデータ ビュー レポートを確認して、メモリ割り当てに関するアプリケーションのパターンを把握します。Review the .NET Memory Data Views reports to understand the application's pattern of memory allocation.

    オブジェクトの有効期間ビューを使用して、ジェネレーションに残っており、その後そこから解放される、プログラムのデータ オブジェクトを確認します。Use the Object Lifetime View to determine which of the program's data objects are surviving into generation and then being reclaimed from there.

    割り当てビューを使用して、これらの割り当てが行われた実行パスを判断します。Use the Allocations View to determine the execution path that resulted in these allocations.

    ガベージ コレクションのパフォーマンスを向上する方法の詳細については、Microsoft Web サイトの .NET Framework の技術記事、「ガベージ コレクタの基本とパフォーマンスのヒント」を参照してください。For more information about how to improve garbage collection performance, see .NET Framework technical article, Garbage Collector Basics and Performance Hints on the MSDN Web site.

    プロセス アドレス空間のプライベート部分のサイズに関する仮想メモリのアーキテクチャ上の制約を解除するには、64 ビット コンピューター上でこの 32 ビット プロセスを実行してみてください。To gain architectural relief from the virtual memory constraints on the size of the private portion of a process address space, try running this 32-bit process on a 64-bit machine. 64 ビット コンピューター上で実行されている 32 ビット プロセスの場合、最大 4 GB のプライベート仮想メモリを取得できます。A 32-bit process on a 64-bit machine can acquire up to 4 GB of private virtual memory.

    64 ビット コンピューター上で実行されている 64 ビット プロセスの場合、最大 8 TB のプライベート仮想メモリを取得できます。A 64-bit process running on a 64-bit machine can acquire up to 8 TB of virtual memory. アプリケーションを再コンパイルし、ネイティブの 64 ビット アプリケーションとして実行することを検討してください。Consider re-compiling the application to execute as a native 64-bit application. この規則は情報提供用であるため、是正措置は必要ない場合があります。This rule is for information only, and might not require corrective action.