ガベージ コレクションの実行時構成オプション

このページには、.NET ランタイム ガベージ コレクター (GC) の設定に関する情報が含まれています。 実行中のアプリのピーク時のパフォーマンスを実現しようとしている場合は、これらの設定の使用を検討してください。 しかし、一般的な状況では、既定値でほとんどのアプリケーションに最適なパフォーマンスが得られます。

このページでは、設定はグループにまとめられます。 各グループ内の設定は一般的に、特定の結果を得るために相互に組み合わせて使用されます。

構成を指定する方法

.NET ランタイムのバージョンが異なると、構成値を指定する方法も異なります。 次の表にその概要を示します。

¹ app.config ファイル設定で、0x プレフィックスを付けずに値を指定できますが、推奨されません。 .NET Framework 4.8 以降では、バグにより、0x プレフィックスを付けずに指定した値は 16 進数として解釈されますが、以前のバージョンの.NET Framework では、10 進数として解釈されます。 構成を変更する必要がないよう、app.config ファイルで値を指定する場合は、0x プレフィックスを使用します。

たとえば、GCHeapCount という名前の .NET Framework アプリに対し、 のヒープを 12 個指定するには、次の XML を A.exe.config ファイルに追加します。

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    ...
    <runtime>
        <gcServer enabled="true"/>
        <GCHeapCount>0xc</GCHeapCount>
    </runtime>
</configuration>

.NET (Core) と .NET Framework の両方で、環境変数を使用できます。

.NET 6 以降を使用する Windows の場合:

SET DOTNET_gcServer=1
SET DOTNET_GCHeapCount=c

.NET 6 以降のバージョンを使用している他のオペレーティング システムでは、次の操作を行います。

export DOTNET_gcServer=1
export DOTNET_GCHeapCount=c

.NET Framework を使用していない場合は、 runtimeconfig.json または runtimeconfig.template.json ファイルで値を設定することもできます。

runtimeconfig.json ファイル:

{
  "runtimeOptions": {
   "configProperties": {
      "System.GC.Server": true,
      "System.GC.HeapCount": 12
   }
  }
}

runtimeconfig.template.json ファイル:

{
  "configProperties": {
    "System.GC.Server": true,
    "System.GC.HeapCount": 12
  }
}

ガベージ コレクションのフレーバー

ガベージ コレクションの主な 2 つのフレーバーは、ワークステーション GC とサーバー GC です。 2 つの間の相違点について詳しくは、「ワークステーションとサーバーのガベージ コレクション」をご覧ください。

ガベージ コレクションのサブフレーバーは、バックグラウンドと非同時実行です。

ガベージ コレクションのフレーバーを選択するには、以下の設定を使用します。

• ワークステーションとサーバーの GC
• バックグラウンド GC

ワークステーションとサーバー

• アプリケーションで、ワークステーション ガベージ コレクションとサーバー ガベージ コレクションのどちらを使用するかを構成します。
• 既定値: ワークステーション ガベージ コレクション。 これは、値を false に設定した場合と同じです。

使用例

runtimeconfig.json ファイル:

{
   "runtimeOptions": {
      "configProperties": {
         "System.GC.Server": true
      }
   }
}

runtimeconfig.template.json ファイル:

{
   "configProperties": {
      "System.GC.Server": true
   }
}

プロジェクト ファイル:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <ServerGarbageCollection>true</ServerGarbageCollection>
  </PropertyGroup>

</Project>

バックグラウンド GC

• バックグラウンド (同時実行) ガベージ コレクションを有効にするかどうかを構成します。
• 既定値: バックグラウンド GC を使用します。 これは、値を true に設定した場合と同じです。
• 詳しくは、「バックグラウンド ガベージ コレクション」をご覧ください。

使用例

runtimeconfig.json ファイル:

{
   "runtimeOptions": {
      "configProperties": {
         "System.GC.Concurrent": false
      }
   }
}

runtimeconfig.template.json ファイル:

{
   "configProperties": {
      "System.GC.Concurrent": false
   }
}

プロジェクト ファイル:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <ConcurrentGarbageCollection>false</ConcurrentGarbageCollection>
  </PropertyGroup>

</Project>

スタンドアロン GC

既定の GC 実装の代わりにスタンドアロン ガベージ コレクターを使用するには、GC ネイティブ ライブラリの path (.NET 9 以降のバージョン) または 名 のいずれかを指定できます。

経路

• 既定の GC 実装の代わりにランタイムが読み込む GC ネイティブ ライブラリの完全パスを指定します。 セキュリティで保護するには、この場所を悪意のある改ざんの可能性から保護する必要があります。

名前

• デフォルトの GC 実装の代わりにランタイムが読み込む GC ネイティブ ライブラリの名前を指定します。 .NET 9 では、 Path 構成の導入により動作が変更されました。

  .NET 8 以前のバージョンでは、次の手順を実行します。

  • ライブラリの名前のみを指定する場合、ライブラリは .NET ランタイムと同じディレクトリに存在する必要があります (Windows 上のcoreclr.dll 、Linux 上の libcoreclr.so 、OSX 上の libcoreclr.dylib )。
  • 値は、たとえば".を指定した場合など、相対パスにすることもできます。Windows の \clrgc.dll" では、 clrgc.dll は .NET ランタイム ディレクトリの親ディレクトリから読み込まれます。

  .NET 9 以降のバージョンでは、この値はファイル名のみを指定します (パスは許可されません)。

  • .NET は、アプリの Main メソッドを含むアセンブリが存在するディレクトリで指定した名前を検索します。
  • ファイルが見つからない場合は、.NET ランタイム ディレクトリが検索されます。

• Path 構成が指定されている場合、この構成設定は無視されます。

LOH 固有の設定

非常に大きなオブジェクトを許可する

• 合計サイズが 2 ギガバイト (GB) を超える配列に対して、64 ビット プラットフォームでのガベージ コレクター サポートを構成します。
• 既定値: GC では、2 GB を超える配列がサポートされます。 これは、値を 1 に設定した場合と同じです。
• このオプションは、将来のバージョンの .NET で廃止される可能性があります。

大きなオブジェクト ヒープのしきい値

• オブジェクトが大きなオブジェクト ヒープ (LOH) に移る原因となる、しきい値のサイズ (バイト単位) を指定します。
• 既定のしきい値は 85,000 バイトです。
• 指定する値は、既定のしきい値より大きくする必要があります。
• この値は、現在の構成で可能な最大サイズまでランタイムによって制限される場合があります。 実行時に使用されている値は、 GC.GetConfigurationVariables() API を使用して調べることができます。

この構成設定には特定の MSBuild プロパティがありません。 ただし、代わりに RuntimeHostConfigurationOption MSBuild 項目を追加することもできます。 属性の値として Include 設定名を使用します。 たとえば、「MSBuild プロパティ」を参照してください。

使用例

runtimeconfig.json ファイル:

{
   "runtimeOptions": {
      "configProperties": {
         "System.GC.LOHThreshold": 120000
      }
   }
}

runtimeconfig.template.json ファイル:

{
   "configProperties": {
      "System.GC.LOHThreshold": 120000
   }
}

すべての GC フレーバーのリソース使用量を管理する

次の設定は、GC のすべてのフレーバーに適用されます。

• ヒープ のハード制限
• ヒープ ハード制限率
• オブジェクトヒープごとのハード制限
• オブジェクトヒープごとのハード制限率
• 大きなページ
• リージョンの範囲
• リージョン サイズ
• 使用率の高いメモリの割合
• VM の保持
• メモリの節約

ヒープ のハード制限

• ヒープ ハード制限は、GC ヒープと GC ブックキーピングの最大コミット サイズ (バイト単位) として定義されます。
• この設定は 64 ビットのコンピューターにのみ該当します。
• メモリ制約のある環境 (コンテナーなど) で実行していて、この値が未設定の場合、既定値は 20 MB または コンテナー制限のヒープ ハード制限の割合 のいずれか大きい方になります。
• Per-object-heap のハード制限が構成されている場合、この設定は無視されます。

この構成設定には特定の MSBuild プロパティがありません。 ただし、代わりに RuntimeHostConfigurationOption MSBuild 項目を追加することもできます。 属性の値として Include 設定名を使用します。 たとえば、「MSBuild プロパティ」を参照してください。

使用例

runtimeconfig.json ファイル:

{
   "runtimeOptions": {
      "configProperties": {
         "System.GC.HeapHardLimit": 209715200
      }
   }
}

runtimeconfig.template.json ファイル:

{
   "configProperties": {
      "System.GC.HeapHardLimit": 209715200
   }
}

ヒープ ハード制限率

• 物理メモリの合計に対する割合としてヒープ ハード制限を指定します。
• プロセスが設定されたメモリ制限 (コンテナーなど) を使用して環境内で実行される場合、その制限は物理メモリの合計として扱われます。 このような環境では、既定値は 75%です。
• この設定は 64 ビットのコンピューターにのみ該当します。
• この設定は、 Per-object-heap のハード制限 が構成されている場合、または heap ハード制限 が構成されている場合は無視されます。

この構成設定には特定の MSBuild プロパティがありません。 ただし、代わりに RuntimeHostConfigurationOption MSBuild 項目を追加することもできます。 属性の値として Include 設定名を使用します。 たとえば、「MSBuild プロパティ」を参照してください。

使用例

runtimeconfig.json ファイル:

{
   "runtimeOptions": {
      "configProperties": {
         "System.GC.HeapHardLimitPercent": 30
      }
   }
}

runtimeconfig.template.json ファイル:

{
   "configProperties": {
      "System.GC.HeapHardLimitPercent": 30
   }
}

オブジェクトヒープごとのハード制限

GC のヒープ ハード制限は、オブジェクト ヒープ単位で指定できます。 ヒープには、大きなオブジェクト ヒープ (LOH)、小さなオブジェクト ヒープ (SOH)、固定オブジェクト ヒープ (POH) があります。

• DOTNET_GCHeapHardLimitSOH、DOTNET_GCHeapHardLimitLOH、DOTNET_GCHeapHardLimitPOH 設定のいずれかの値を指定する場合、DOTNET_GCHeapHardLimitSOH と DOTNET_GCHeapHardLimitLOH の値も指定する必要があります。 そうしないと、ランタイムでの初期化が失敗します。
• DOTNET_GCHeapHardLimitPOH の既定値は 0 です。 DOTNET_GCHeapHardLimitSOH と DOTNET_GCHeapHardLimitLOH には既定値はありません。

これらの構成設定には、特定の MSBuild プロパティがありません。 ただし、代わりに RuntimeHostConfigurationOption MSBuild 項目を追加することもできます。 属性の値として Include 設定名を使用します。 たとえば、「MSBuild プロパティ」を参照してください。

オブジェクトヒープごとのハード制限率

GC のヒープ ハード制限は、オブジェクト ヒープ単位で指定できます。 ヒープには、大きなオブジェクト ヒープ (LOH)、小さなオブジェクト ヒープ (SOH)、固定オブジェクト ヒープ (POH) があります。

• DOTNET_GCHeapHardLimitSOHPercent、DOTNET_GCHeapHardLimitLOHPercent、DOTNET_GCHeapHardLimitPOHPercent 設定のいずれかの値を指定する場合、DOTNET_GCHeapHardLimitSOHPercent と DOTNET_GCHeapHardLimitLOHPercent の値も指定する必要があります。 そうしないと、ランタイムでの初期化が失敗します。
• DOTNET_GCHeapHardLimitSOH、DOTNET_GCHeapHardLimitLOH、および DOTNET_GCHeapHardLimitPOH が指定されている場合、これらの設定は無視されます。
• 値 1 は、GC によって合計物理メモリの 1% がそのオブジェクト ヒープに使用されることを意味します。
• 各値は、ゼロより大きく、100 未満である必要があります。 また、3 つのパーセンテージ値の合計は、100 未満である必要があります。 それ以外の場合、ランタイムでの初期化が失敗します。

これらの構成設定には、特定の MSBuild プロパティがありません。 ただし、代わりに RuntimeHostConfigurationOption MSBuild 項目を追加することもできます。 属性の値として Include 設定名を使用します。 たとえば、「MSBuild プロパティ」を参照してください。

大きいページ

• ヒープのハード制限が設定されている場合に、大きいページを使用する必要があるかどうかを指定します。
• 既定値: ヒープのハード制限が設定されている場合は、大きいページを使用しません。 これは、値を 0 に設定した場合と同じです。
• これは試験段階の設定です。

リージョンの範囲

.NET 7 以降、GC ヒープは、64 ビット Windows および Linux のセグメントからリージョンに物理表現を切り替えました。 (詳細については、 Maoni Stephens のブログ記事を参照してください)。この変更により、GC は初期化中に仮想メモリの範囲を予約します。 これはメモリのみを予約し、コミットしないことに注意してください (GC ヒープ サイズはコミット メモリです)。 GC ヒープがコミットできる最大範囲を定義する範囲にすぎません。 ほとんどのアプリケーションでは、この程度のコミットを行う必要はありません。

他の構成がなく、メモリ制約のある環境 (一部の GC 構成が設定される原因) で実行されていない場合、既定では 256 GB が予約されます。 使用可能な物理メモリが 256 GB を超える場合、その量の 2 倍になります。

ヒープごとのハード制限が設定されている場合、予約範囲は合計ハード制限と同じです。 1 つのハード制限構成が設定されている場合、この範囲はその 5 倍になります。

この範囲は、仮想メモリの合計量によって制限されます。 通常、64 ビットではこれは問題ありませんが、プロセスに仮想メモリの制限が設定されている可能性があります。 この範囲は、その量の半分に制限されます。 たとえば、 HeapHardLimit 構成を 1 GB に設定し、プロセスに 4 GB の仮想メモリ制限が設定されている場合、この範囲は min (5x1GB, 4GB/2) (2 GB) です。

GC.GetConfigurationVariables() API を使用して、GCRegionRangeという名前でこの範囲の値を確認できます。 実行時の初期化中にE_OUTOFMEMORYが発生し、この範囲を予約したことが原因かどうかを確認する場合は、WINDOWS 上のVirtualAllocを使用したMEM_RESERVE呼び出し、または linux 上のmmapでのPROT_NONE呼び出しを調び、OOM がその呼び出しからかどうかを確認します。 この予約呼び出しが失敗した場合は、次の構成設定を使用して変更できます。 予約量の推奨事項は、GC ヒープのコミット済みサイズの 2 ~ 5 倍です。 シナリオで多数の大きな割り当てが行わない場合 (UOH での割り当て、または UOH リージョン サイズより大きい可能性があります)、コミットされたサイズの 2 倍は安全である必要があります。 それ以外の場合は、より大きなリージョンの領域を作るために、あまり頻繁に完全圧縮 GC が発生しないように、サイズを大きくすることをお勧めします。 GC ヒープのコミット済みサイズがわからない場合は、プロセスで使用できる物理メモリの量の 2 倍に設定できます。

この構成設定には特定の MSBuild プロパティがありません。 ただし、代わりに RuntimeHostConfigurationOption MSBuild 項目を追加することもできます。 属性の値として Include 設定名を使用します。 たとえば、「MSBuild プロパティ」を参照してください。

リージョン サイズ

.NET 7 以降、GC ヒープは、64 ビット Windows および Linux のセグメントからリージョンに物理表現を切り替えました。 (詳細については、 Maoni Stephens のブログ記事を参照してください)。既定では、SOH の場合、各リージョンは 4 MB です。 UOH (LOH と POH) の場合、SOH 領域のサイズの 8 倍です。 この構成を使用して SOH リージョンのサイズを変更すると、それに応じて UOH リージョンが調整されます。

リージョンは必要な場合にのみ割り当てられるため、一般にリージョンのサイズについて心配する必要はありません。 ただし、このサイズを調整する場合は 2 つあります。

• GC ヒープが非常に小さいプロセスの場合、領域サイズを小さく変更すると、GC 独自のブックキーピングからのネイティブ メモリ使用量に役立ちます。 推奨は 1 MB です。
• Linux では、メモリ マッピングの数を減らす必要がある場合は、リージョン サイズを 32 MB のように大きく変更できます。

この構成設定には特定の MSBuild プロパティがありません。 ただし、代わりに RuntimeHostConfigurationOption MSBuild 項目を追加することもできます。 属性の値として Include 設定名を使用します。 たとえば、「MSBuild プロパティ」を参照してください。

使用率の高いメモリの割合

メモリの負荷は、使用されている物理メモリの割合によって示されます。 既定では、物理メモリの負荷が 90%に達すると、ガベージコレクションがより積極的に完全に実行され、ガベージ コレクションが圧縮されてページングが回避されるようになります。 メモリの負荷が 90% 未満の場合、GC によって、フル ガベージ コレクションに対するバックグラウンド コレクションが優先されます。一時停止は短くなりますが、ヒープ サイズの合計はそれほど小さくなりません。 大量のメモリ (80 GB 以上) が搭載されたコンピューターでは、負荷のしきい値は 90% から 97% が既定値です。

使用率の高いメモリの負荷のしきい値は、DOTNET_GCHighMemPercent 環境変数、または System.GC.HighMemoryPercent JSON 構成設定によって調整できます。 ヒープ サイズを制御する場合は、しきい値の調整を検討してください。 たとえば、64 GB のメモリを搭載したコンピューター上で最も優先度の高いプロセスでは、使用可能なメモリが 10% あれば、GC が反応を開始するのが妥当です。 ただし、サイズの小さいプロセス、たとえば 1 GB のメモリしか消費しないプロセスでは、使用可能なメモリが 10% 未満でも、GC を快適に実行できます。 このような小さいプロセスでは、しきい値を高く設定することを検討してください。 一方、大きなプロセスでヒープ サイズを小さくする場合は、使用可能な物理メモリが十分にあったとしても、このしきい値を低くすると、GC がすぐに反応してヒープを圧縮できるため、方法としては効率的です。

この構成設定には特定の MSBuild プロパティがありません。 ただし、代わりに RuntimeHostConfigurationOption MSBuild 項目を追加することもできます。 属性の値として Include 設定名を使用します。 たとえば、「MSBuild プロパティ」を参照してください。

VM の保持

• 削除する必要があるセグメントを、後で使用するためにスタンバイ リストに配置するか、解放してオペレーティング システム (OS) に戻すかを構成します。
• 既定値: セグメントを解放してオペレーティング システムに戻します。 これは、値を false に設定した場合と同じです。

使用例

runtimeconfig.json ファイル:

{
   "runtimeOptions": {
      "configProperties": {
         "System.GC.RetainVM": true
      }
   }
}

runtimeconfig.template.json ファイル:

{
   "configProperties": {
      "System.GC.RetainVM": true
   }
}

プロジェクト ファイル:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <RetainVMGarbageCollection>true</RetainVMGarbageCollection>
  </PropertyGroup>

</Project>

メモリを節約する

• メモリを節約するためのガベージ コレクターは、ガベージ コレクションの頻度が高くなり、一時停止時間が長くなる可能性と引き換えに構成されます。
• 既定値は 0 です。これは変更なしを意味します。
• 既定値 0 に加え、1 から 9 (包括) の値が有効です。 値が大きいほど、ガベージ コレクターはメモリを節約しようとするため、ヒープが小さく保たれます。
• 値が 0 以外の場合、断片化が多すぎると、大きなオブジェクト ヒープが自動的に圧縮されます。

この構成設定には特定の MSBuild プロパティがありません。 ただし、代わりに RuntimeHostConfigurationOption MSBuild 項目を追加することもできます。 属性の値として Include 設定名を使用します。 たとえば、「MSBuild プロパティ」を参照してください。

app.config ファイルの例:

<configuration>
  <runtime>
    <GCConserveMemory enabled="5"/>
  </runtime>
</configuration>

サーバー GC のリソース使用量を管理する

次の設定は、サーバー GC スレッドの数と、それらがコアに関連付けられたかどうか/方法に影響します。 ワークステーション GC には影響しません。

• ヒープ数
• 関係付け
• 関係付けマスク
• 関係付け範囲
• CPU グループ
• DATAS

最初の 3 つの設定の詳細については、 ワークステーションとサーバー GC の間の中間グラウンド のブログ エントリを参照してください。

ヒープ数

• ガベージ コレクターによって作成されるヒープの数を制限します。
• サーバー ガベージ コレクションにのみ適用されます。
• GC プロセッサの関係が有効になっている場合 (既定値)、ヒープ数の設定では、最初の n プロセッサに n GC ヒープやスレッドを関連付けます。 (関係付けマスクまたは関係付け範囲の設定を使用して、関係付けるプロセッサを正確に指定します)。
• GC プロセッサの関係が無効になっている場合、この設定によって GC ヒープの数が制限されます。
• 詳細については、GCHeapCount の解説に関する記述を参照してください。

この構成設定には特定の MSBuild プロパティがありません。 ただし、代わりに RuntimeHostConfigurationOption MSBuild 項目を追加することもできます。 属性の値として Include 設定名を使用します。 たとえば、「MSBuild プロパティ」を参照してください。

使用例

runtimeconfig.json ファイル:

{
   "runtimeOptions": {
      "configProperties": {
         "System.GC.HeapCount": 16
      }
   }
}

runtimeconfig.template.json ファイル:

{
   "configProperties": {
      "System.GC.HeapCount": 16
   }
}

関係付け

• ガベージ コレクション スレッドをプロセッサに "関係付ける" かどうかを指定します。 GC スレッドを関係付けることは、その特定の CPU でのみ実行できることを意味します。 各 GC スレッドに対してヒープが作成されます。
• サーバー ガベージ コレクションにのみ適用されます。
• 既定値: ガベージ コレクション スレッドをプロセッサに関係付けます。 これは、値を false に設定した場合と同じです。

この構成設定には特定の MSBuild プロパティがありません。 ただし、代わりに RuntimeHostConfigurationOption MSBuild 項目を追加することもできます。 属性の値として Include 設定名を使用します。 たとえば、「MSBuild プロパティ」を参照してください。

使用例

runtimeconfig.json ファイル:

{
   "runtimeOptions": {
      "configProperties": {
         "System.GC.NoAffinitize": true
      }
   }
}

runtimeconfig.template.json ファイル:

{
   "configProperties": {
      "System.GC.NoAffinitize": true
   }
}

関係付けマスク

• ガベージ コレクター スレッドで使用する必要がある正確なプロセッサを指定します。
• GC プロセッサの関係が無効になっている場合、この設定は無視されます。
• サーバー ガベージ コレクションにのみ適用されます。
• この値は、プロセスで使用できるプロセッサを定義するビット マスクです。 たとえば、10 進値の 1023 (環境変数を使用する場合は、16 進値の 0x3FF または 3FF) は、バイナリ表記では 0011 1111 1111 となります。 これにより、最初の 10 プロセッサが使用されることが指定されます。 次の 10 プロセッサ (つまり、10 から 19 プロセッサ) を指定するには、10 進値の 1047552 (または 16 進値の 0xFFC00 または FFC00) を指定します。これは、バイナリ値の 1111 1111 1100 0000 0000 に相当します。

この構成設定には特定の MSBuild プロパティがありません。 ただし、代わりに RuntimeHostConfigurationOption MSBuild 項目を追加することもできます。 属性の値として Include 設定名を使用します。 たとえば、「MSBuild プロパティ」を参照してください。

使用例

runtimeconfig.json ファイル:

{
   "runtimeOptions": {
      "configProperties": {
         "System.GC.HeapAffinitizeMask": 1023
      }
   }
}

runtimeconfig.template.json ファイル:

{
   "configProperties": {
      "System.GC.HeapAffinitizeMask": 1023
   }
}

関係付け範囲

• ガベージ コレクター スレッドに使用するプロセッサのリストを指定します。
• この設定は System.GC.HeapAffinitizeMask に似ていますが、64 を超えるプロセッサを指定できる点が異なります。
• Windows オペレーティング システムの場合、プロセッサの番号または範囲の前に、対応する CPU グループを付けます。たとえば、"0:1-10,0:12,1:50-52,1:7" となります。 実際に １を超える CPU グループをお持ちでない場合は、この設定を使用できません。 Affinitize マスクの設定を使用する必要があります。 指定した数値はそのグループ内にあります。つまり、>= 64 にすることはできません。
• CPU グループの概念が存在しない Linux オペレーティング システムでは、この設定と Affinitize マスク設定の両方を使用して、同じ範囲を指定できます。 また、グループ インデックスを指定する必要がないため、"0:1-10" の代わりに "1- 10" を指定します。
• GC プロセッサの関係が無効になっている場合、この設定は無視されます。
• サーバー ガベージ コレクションにのみ適用されます。
• 詳細については、Maoni Stephens のブログの「>」を参照してください。

この構成設定には特定の MSBuild プロパティがありません。 ただし、代わりに RuntimeHostConfigurationOption MSBuild 項目を追加することもできます。 属性の値として Include 設定名を使用します。 たとえば、「MSBuild プロパティ」を参照してください。

使用例

runtimeconfig.json ファイル:

{
   "runtimeOptions": {
      "configProperties": {
         "System.GC.HeapAffinitizeRanges": "0:1-10,0:12,1:50-52,1:7"
      }
   }
}

runtimeconfig.template.json ファイル:

{
   "configProperties": {
      "System.GC.HeapAffinitizeRanges": "0:1-10,0:12,1:50-52,1:7"
   }
}

CPU グループ

• ガベージ コレクターで CPU グループを使用するかどうかを構成します。

  64 ビットの Windows コンピューターに複数の CPU グループがある (つまり、64 を超えるプロセッサがある) 場合、この要素を有効にすると、すべての CPU グループ全体にガベージ コレクションが拡張されます。 ガベージ コレクターではすべてのコアを使用し、ヒープを作成して分散させます。

  メモ

  これは Windows のみに該当する概念です。 以前のバージョンの Windows では、Windows によりプロセスが 1 つの CPU グループに制限されていました。 したがって、この設定を使用して複数の CPU グループを有効にしない限り、GC では 1 つの CPU グループのみが使用されました。 この OS の制限は、Windows 11 および Server 2022 で解除されました。 また、.NET 7 以降では、Windows 11 または Server 2022 で実行されている場合、GC は既定ですべての CPU グループを使用します。

• 64 ビット Windows オペレーティング システムのみのサーバー ガベージ コレクションに適用されます。

• 既定値: GC は複数の CPU グループに拡張されません。 これは、値を 0 に設定した場合と同じです。

• 詳細については、Maoni Stephens のブログの「>」を参照してください。

この構成設定には特定の MSBuild プロパティがありません。 ただし、代わりに RuntimeHostConfigurationOption MSBuild 項目を追加することもできます。 属性の値として Include 設定名を使用します。 たとえば、「MSBuild プロパティ」を参照してください。

アプリケーションサイズへの動的適応 (DATAS)

DATAS の有効化または無効化

• DATAS を使用するようにガベージ コレクターを構成します。 DATAS はアプリケーション のメモリ要件に適応します。つまり、アプリ ヒープ サイズは、有効期間の長いデータ サイズにほぼ比例する必要があります。
• .NET 9 以降では、既定で有効になっています。

ターゲット TCP

DATAS では、スループットのメモリ コスト測定としてスループット コストの割合 (TCP) が使用されます。 GC の一時停止と、待機する必要がある割り当ての量の両方が考慮されます。 通常、GC の一時停止が優勢であるため、"gc の% 一時停止時間" を使用して、このコストを概算できます。 割り当て待機時間が大きな影響を受ける可能性がある一時的なケースは 2 つあります。

• プロセスが開始されると、DATAS は常に 1 つのヒープで始まります。 そのため、十分なスレッドが割り当てられている場合は、待機が発生します。
• ワークロードが軽いものから重いものに変わる場合 (ピーク時の開始時など)、スレッドを割り当てると、その期間中に待機が発生する可能性があります。 これは、ヒープの数が増える前に、いくつかの VC を要するためです。

DATAS では、既定の TCP として 2% が使用されます。この設定で調整できます。 これはパーセンテージとして解釈される整数です。たとえば、5 はターゲット TCP が 5%されることを意味します。

この構成設定には特定の MSBuild プロパティがありません。 ただし、代わりに RuntimeHostConfigurationOption MSBuild 項目を追加することもできます。 属性の値として Include 設定名を使用します。 たとえば、「MSBuild プロパティ」を参照してください。

Gen0 の最大予算設定

gen0 予算の調整は、DATAS がアプリケーション サイズに適応するために使用する重要な要素の 1 つです。 DATAS は、アプリケーション サイズの関数として gen0 予算の合計に対して BCD (DATAS を使用して計算された予算) と呼ばれる上限しきい値を定義します。 乗数を計算する数式は次のとおりです。

$$ f(\text{application_size_in_MB}) = \frac{20 - \text{conserve_memory}}{\sqrt{\text{application_size_in_MB}}} $$

その後、数式は、アプリケーション サイズ (MB) に適用される前に、最大値と最小値で固定されます。 メモリ節約設定が指定されていない場合、DATAS では既定で 5 が使用されます。 最大値と最小値の既定値はそれぞれ 10 と 0.1 です。

たとえば、アプリケーション サイズが 1 GB の場合、数式は (20 - 5) / sqrt (1000) = 0.474を計算します。 10 から 0.1 の間なので、クランプは効果がありません。 つまり、gen0 の合計予算は 47.4% 1 GB (474 MB) です。 アプリケーション サイズが 1 MB の場合、数式では 15 が計算され、10 に調整されます。つまり、許可される gen0 予算の合計は 10 MB です。

数式の計算内容を調整し、クランプ値を変更するための 3 つの設定が用意されています。

• f計算に適用される割合。

  	設定の名前	値	導入されたバージョン
  runtimeconfig.json	System.GC.DGen0GrowthPercent	"10 進値"	.NET 10
  環境変数	DOTNET_GCDGen0GrowthPercent	"16 進値"	.NET 10

  この構成設定には特定の MSBuild プロパティがありません。 ただし、代わりに RuntimeHostConfigurationOption MSBuild 項目を追加することもできます。 属性の値として Include 設定名を使用します。 たとえば、「MSBuild プロパティ」を参照してください。

  したがって、 f が 0.474 を計算し、この設定が 200 の場合、クランプが適用される前に乗数が 0.474 * 200% = 0.948 になります。

• permil の最大クランプ値。

  	設定の名前	値	導入されたバージョン
  runtimeconfig.json	System.GC.DGen0GrowthMaxFactor	"10 進値"	.NET 10
  環境変数	DOTNET_GCDGen0GrowthMaxFactor	"16 進値"	.NET 10

  この構成設定には特定の MSBuild プロパティがありません。 ただし、代わりに RuntimeHostConfigurationOption MSBuild 項目を追加することもできます。 属性の値として Include 設定名を使用します。 たとえば、「MSBuild プロパティ」を参照してください。

  この値が 20000 の場合は、最大クランプ値が 20000 * 0.001 = 20であることを意味します。

• パーミル単位の最小クランプ値。

  	設定の名前	値	導入されたバージョン
  runtimeconfig.json	System.GC.DGen0GrowthMinFactor	"10 進値"	.NET 10
  環境変数	DOTNET_GCDGen0GrowthMinFactor	"16 進値"	.NET 10

  この構成設定には特定の MSBuild プロパティがありません。 ただし、代わりに RuntimeHostConfigurationOption MSBuild 項目を追加することもできます。 属性の値として Include 設定名を使用します。 たとえば、「MSBuild プロパティ」を参照してください。

  この値が 200 の場合、最小クランプ値は 200 * 0.001 = 0.2。