Körningskonfigurationsalternativ för skräpinsamling

Den här sidan innehåller information om inställningar för .NET-runtime-skräpinsamlaren (GC). Om du försöker uppnå högsta prestanda för en app som körs kan du överväga att använda de här inställningarna. Standardinställningarna ger dock optimala prestanda för de flesta program i vanliga situationer.

Inställningarna är ordnade i grupper på den här sidan. Inställningarna i varje grupp används ofta tillsammans med varandra för att uppnå ett specifikt resultat.

Sätt att ange konfigurationen

För olika versioner av .NET-körningen finns det olika sätt att ange konfigurationsvärdena. Följande tabell visar en sammanfattning.

¹ Du kan ange ett värde utan prefixet 0x för en app.config-filinställning, men det rekommenderas inte. På .NET Framework 4.8+ tolkas ett värde som angetts utan prefixet 0x som hexadecimalt på grund av en bugg, men i tidigare versioner av .NET Framework tolkas det som decimaltecken. Om du vill undvika att behöva ändra konfigurationen använder du prefixet 0x när du anger ett värde i filen app.config.

Om du till exempel vill ange 12 heaps för GCHeapCount en .NET Framework-app med namnet A.exe lägger du till följande XML i filen A.exe.config .

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

För både .NET (Core) och .NET Framework kan du använda miljövariabler.

I Windows med hjälp av .NET 6 eller en senare version:

SET DOTNET_gcServer=1
SET DOTNET_GCHeapCount=c

I Windows med .NET 5 eller tidigare:

SET COMPlus_gcServer=1
SET COMPlus_GCHeapCount=c

På andra operativsystem:

För .NET 6 eller senare versioner:

export DOTNET_gcServer=1
export DOTNET_GCHeapCount=c

För .NET 5 och tidigare versioner:

export COMPlus_gcServer=1
export COMPlus_GCHeapCount=c

Om du inte använder .NET Framework kan du också ange värdet i filen runtimeconfig.json eller runtimeconfig.template.json .

runtimeconfig.json fil:

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

runtimeconfig.template.json fil:

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

Smaker av skräpinsamling

De två viktigaste smakerna av skräpinsamling är arbetsstation GC och server GC. Mer information om skillnaderna mellan de två finns i Arbetsstation och skräpinsamling för servrar.

Underflavorna för skräpinsamling är bakgrund och icke-samtidiga.

Använd följande inställningar för att välja varianter av skräpinsamling:

• Arbetsstation jämfört med server-GC
• Bakgrunds-GC

Arbetsstation jämfört med server

• Konfigurerar om programmet använder skräpinsamling för arbetsstationer eller skräpinsamling på servern.
• Standard: Skräpinsamling för arbetsstation. Detta motsvarar att ange värdet till false.

Exempel

runtimeconfig.json fil:

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

runtimeconfig.template.json fil:

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

Projektfil:

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

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

</Project>

Bakgrunds-GC

• Konfigurerar om skräpinsamling i bakgrunden (samtidig) är aktiverad.
• Standard: Använd bakgrunds-GC. Detta motsvarar att ange värdet till true.
• Mer information finns i Skräpinsamling i bakgrunden.

Exempel

runtimeconfig.json fil:

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

runtimeconfig.template.json fil:

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

Projektfil:

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

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

</Project>

Fristående GC

Om du vill använda en fristående skräpinsamlare i stället för GC-standardimplementeringen kan du ange antingen sökvägen (i .NET 9 och senare versioner) eller namnet på ett internt GC-bibliotek.

Sökväg

• Anger den fullständiga sökvägen för ett inbyggt GC-bibliotek som körningen läser in i stället för standardimplementeringen av GC. För att vara säker bör den här platsen skyddas från potentiellt skadlig manipulering.

Namn

• Anger namnet på ett inbyggt GC-bibliotek som körningen läser in i stället för GC-standardimplementeringen. Beteendet ändrades i .NET 9 med introduktionen av path-konfigurationen.

  I .NET 8 och tidigare versioner:

  • Om endast ett namn på biblioteket anges måste biblioteket finnas i samma katalog som .NET-körningen (coreclr.dll i Windows, libcoreclr.so i Linux eller libcoreclr.dylib på OSX).
  • Värdet kan också vara en relativ sökväg, till exempel om du anger ".. \clrgc.dll" i Windows läses clrgc.dll in från den överordnade katalogen i .NET-körningskatalogen.

  I .NET 9 och senare versioner anger det här värdet endast ett filnamn (sökvägar tillåts inte):

  • .NET söker efter det namn som du anger i katalogen där sammansättningen som innehåller appens Main metod finns.
  • Om filen inte hittas genomsöks .NET-körningskatalogen.

• Den här konfigurationsinställningen ignoreras om sökvägskonfigurationen har angetts.

LOH-specifika inställningar

Tillåt mycket stora objekt

• Konfigurerar stöd för skräpinsamlare på 64-bitarsplattformar för matriser som är större än 2 GIGABYTE (GB) i total storlek.
• Standard: GC stöder matriser som är större än 2 GB. Detta motsvarar att ange värdet till 1.
• Det här alternativet kan bli föråldrat i en framtida version av .NET.

Tröskelvärde för stora objekts heap

• Anger tröskelvärdets storlek, i byte, som gör att objekt hamnar på den stora objekthögen (LOH).
• Standardtröskelvärdet är 85 000 byte.
• Värdet du anger måste vara större än standardtröskelvärdet.
• Värdet kan begränsas av körningen till den maximala möjliga storleken för den aktuella konfigurationen. Du kan kontrollera värdet som används vid körning via API:et GC.GetConfigurationVariables() .

Den här konfigurationsinställningen har ingen specifik MSBuild-egenskap. Du kan dock lägga till ett RuntimeHostConfigurationOption MSBuild-objekt i stället. Använd runtimeconfig.json inställningsnamnet som värdet för attributetInclude. Ett exempel finns i MSBuild-egenskaper.

Exempel

runtimeconfig.json fil:

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

runtimeconfig.template.json fil:

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

Hantera resursanvändning för alla GC-smaker

Följande inställningar gäller för alla smaker av GC:

• Heap hård gräns
• Heap hård gränsprocent
• Hårda gränser per objekt-heap
• Procent för hård gräns per objekt-heap
• Stora sidor
• Regionintervall
• Regionstorlek
• Hög minnesprocent
• Behålla virtuell dator
• Spara minne

Heap hård gräns

• Den hårda heapgränsen definieras som den maximala incheckningsstorleken, i byte, för GC-heap- och GC-bokföringen.
• Den här inställningen gäller endast för 64-bitars datorer.
• Om den här gränsen inte har konfigurerats men processen körs i en minnesbegränsad miljö, dvs. i en container med en angiven minnesgräns, anges ett standardvärde. Standardvärdet är större än 20 MB eller 75 % av minnesgränsen för containern.
• Den här inställningen ignoreras om de hårda gränserna per objekt-heap har konfigurerats.

Den här konfigurationsinställningen har ingen specifik MSBuild-egenskap. Du kan dock lägga till ett RuntimeHostConfigurationOption MSBuild-objekt i stället. Använd runtimeconfig.json inställningsnamnet som värdet för attributetInclude. Ett exempel finns i MSBuild-egenskaper.

Exempel

runtimeconfig.json fil:

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

runtimeconfig.template.json fil:

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

Heap hård gränsprocent

• Anger den hårda heapgränsen som en procentandel av det totala fysiska minnet. Om processen körs i en minnesbegränsad miljö, dvs. i en container med en angiven minnesgräns, är det totala fysiska minnet minnesgränsen. annars är det det som är tillgängligt på datorn.
• Den här inställningen gäller endast för 64-bitars datorer.
• Den här inställningen ignoreras om de hårda gränserna per objekt-heap har konfigurerats eller om heapens hårda gräns har konfigurerats.

Den här konfigurationsinställningen har ingen specifik MSBuild-egenskap. Du kan dock lägga till ett RuntimeHostConfigurationOption MSBuild-objekt i stället. Använd runtimeconfig.json inställningsnamnet som värdet för attributetInclude. Ett exempel finns i MSBuild-egenskaper.

Exempel

runtimeconfig.json fil:

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

runtimeconfig.template.json fil:

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

Hårda gränser per objekt-heap

Du kan ange GC:s hårda gräns per objekt-heap. De olika heaparna är den stora objekthögen (LOH), den lilla objekthögen (SOH) och den fästa objekthögen (POH).

• Om du anger ett värde för någon av DOTNET_GCHeapHardLimitSOHinställningarna , DOTNET_GCHeapHardLimitLOHeller DOTNET_GCHeapHardLimitPOH måste du också ange ett värde för DOTNET_GCHeapHardLimitSOH och DOTNET_GCHeapHardLimitLOH. Om du inte gör det kan körningen inte initieras.
• Standardvärdet för DOTNET_GCHeapHardLimitPOH är 0. DOTNET_GCHeapHardLimitSOH och DOTNET_GCHeapHardLimitLOH har inte standardvärden.

De här konfigurationsinställningarna har inte specifika MSBuild-egenskaper. Du kan dock lägga till ett RuntimeHostConfigurationOption MSBuild-objekt i stället. Använd runtimeconfig.json inställningsnamnet som värdet för attributetInclude. Ett exempel finns i MSBuild-egenskaper.

Procent för hård gräns per objekt-heap

Du kan ange GC:s hårda gräns per objekt-heap. De olika heaparna är den stora objekthögen (LOH), den lilla objekthögen (SOH) och den fästa objekthögen (POH).

• Om du anger ett värde för någon av DOTNET_GCHeapHardLimitSOHPercentinställningarna , DOTNET_GCHeapHardLimitLOHPercenteller DOTNET_GCHeapHardLimitPOHPercent måste du också ange ett värde för DOTNET_GCHeapHardLimitSOHPercent och DOTNET_GCHeapHardLimitLOHPercent. Om du inte gör det kan körningen inte initieras.
• De här inställningarna ignoreras om DOTNET_GCHeapHardLimitSOH, DOTNET_GCHeapHardLimitLOHoch DOTNET_GCHeapHardLimitPOH anges.
• Värdet 1 innebär att GC använder 1 % av det totala fysiska minnet för objektets heap.
• Varje värde måste vara större än noll och mindre än 100. Dessutom måste summan av de tre procentvärdena vara mindre än 100. Annars kan körningen inte initieras.

De här konfigurationsinställningarna har inte specifika MSBuild-egenskaper. Du kan dock lägga till ett RuntimeHostConfigurationOption MSBuild-objekt i stället. Använd runtimeconfig.json inställningsnamnet som värdet för attributetInclude. Ett exempel finns i MSBuild-egenskaper.

Stora sidor

• Anger om stora sidor ska användas när en heap hård gräns anges.
• Standard: Använd inte stora sidor när en heap hård gräns har angetts. Detta motsvarar att ange värdet till 0.
• Det här är en experimentell inställning.

Regionintervall

Från och med .NET 7 bytte GC-heapen sin fysiska representation från segment till regioner för 64-bitars Windows och Linux. (Mer information finns i Maoni Stephens bloggartikel.) Med den här ändringen reserverar GC en mängd virtuellt minne under initieringen. Observera att detta endast reserverar minne och inte genomför (GC-heapstorleken är incheckat minne). Det är bara ett intervall för att definiera det maximala intervall som GC-heapen kan checka in. De flesta program behöver inte checka in så här mycket.

Om du inte har några andra konfigurationer och inte körs i en minnesbegränsad miljö (vilket skulle göra att vissa GC-konfigurationer anges) är 256 GB som standard reserverat. Om du har mer än 256 GB fysiskt minne tillgängligt blir det dubbelt så mycket.

Om de hårda gränserna per heap anges är reservintervallet detsamma som den totala hårda gränsen. Om en enda hård gränskonfiguration har angetts är det här intervallet fem gånger så mycket.

Det här intervallet begränsas av mängden totalt virtuellt minne. Normalt på 64-bitars är detta aldrig ett problem, men det kan finnas en virtuell minnesgräns inställd på en process. Det här intervallet är begränsat med hälften så mycket. Om du till exempel ställer in konfigurationen HeapHardLimit på 1 GB och har en gräns på 4 GB virtuellt minne inställt på processen är min (5x1GB, 4GB/2)det här intervallet , vilket är 2 GB.

Du kan använda API:et GC.GetConfigurationVariables() för att se värdet för det här intervallet under namnet GCRegionRange. Om du får E_OUTOFMEMORY under körningsinitieringen och vill se om det beror på att det reserverar det här intervallet kan du titta på anropet VirtualAlloc med MEM_RESERVE i Windows eller samtalet med mmap i Linux under GC-initieringen och se om OOM är från det anropetPROT_NONE. Om det här reservanropet misslyckas kan du ändra det via följande konfigurationsinställningar. Rekommendationen för reservationsbeloppet är två till fem gånger den incheckade storleken för din GC-heap. Om ditt scenario inte gör många stora allokeringar (det kan vara allokeringar på UOH eller större än UOH-regionens storlek) bör dubbelt så stor som den incheckade storleken vara säker. Annars kanske du vill göra den större så att du inte får för ofta fullkomprimerande GCs för att göra plats för de större regionerna. Om du inte känner till GC-heapens incheckade storlek kan du ange detta till två gånger så mycket fysiskt minne som är tillgängligt för processen.

Den här konfigurationsinställningen har ingen specifik MSBuild-egenskap. Du kan dock lägga till ett RuntimeHostConfigurationOption MSBuild-objekt i stället. Använd runtimeconfig.json inställningsnamnet som värdet för attributetInclude. Ett exempel finns i MSBuild-egenskaper.

Regionstorlek

Från och med .NET 7 bytte GC-heapen sin fysiska representation från segment till regioner för 64-bitars Windows och Linux. (Mer information finns i Maoni Stephens bloggartikel.) Som standard är varje region 4 MB för SOH. För UOH (LOH och POH) är det åtta gånger så stor som SOH-regionen. Du kan använda den här konfigurationen för att ändra storleken på SOH-regionen och UOH-regionerna justeras därefter.

Regioner allokeras bara när det behövs, så i allmänhet behöver du inte bekymra dig om regionens storlek. Det finns dock två fall där du kanske vill justera den här storleken:

• För processer som har mycket små GC-heaps är det fördelaktigt att ändra regionstorleken till mindre för intern minnesanvändning från GC:s egen bokföring. Rekommendationen är 1 MB.
• Om du behöver minska antalet minnesmappningar i Linux kan du ändra regionstorleken till större, till exempel 32 MB.

Den här konfigurationsinställningen har ingen specifik MSBuild-egenskap. Du kan dock lägga till ett RuntimeHostConfigurationOption MSBuild-objekt i stället. Använd runtimeconfig.json inställningsnamnet som värdet för attributetInclude. Ett exempel finns i MSBuild-egenskaper.

Hög minnesprocent

Minnesbelastning indikeras av procentandelen fysiskt minne som används. När den fysiska minnesbelastningen når 90 % blir skräpinsamlingen som standard mer aggressiv när det gäller att göra fullständiga, komprimera skräpsamlingar för att undvika växling. När minnesbelastningen är lägre än 90 % föredrar GC bakgrundssamlingar för fullständiga skräpsamlingar, som har kortare pauser men inte minskar den totala heapstorleken med mycket. På datorer med en betydande mängd minne (80 GB eller mer) är standardtröskelvärdet för belastning mellan 90 % och 97 %.

Tröskelvärdet för hög minnesbelastning kan justeras med DOTNET_GCHighMemPercent miljövariabeln eller System.GC.HighMemoryPercent JSON-konfigurationsinställningen. Överväg att justera tröskelvärdet om du vill kontrollera heapstorleken. För den dominerande processen på en dator med 64 GB minne är det till exempel rimligt att GC börjar reagera när det finns 10 % tillgängligt minne. Men för mindre processer, till exempel en process som bara förbrukar 1 GB minne, kan GC bekvämt köras med mindre än 10 % tillgängligt minne. För dessa mindre processer bör du överväga att ange tröskelvärdet högre. Å andra sidan, om du vill att större processer ska ha mindre heapstorlekar (även om det finns gott om fysiskt minne tillgängligt), är en sänkning av detta tröskelvärde ett effektivt sätt för GC att reagera tidigare för att komprimera ner heapen.

Den här konfigurationsinställningen har ingen specifik MSBuild-egenskap. Du kan dock lägga till ett RuntimeHostConfigurationOption MSBuild-objekt i stället. Använd runtimeconfig.json inställningsnamnet som värdet för attributetInclude. Ett exempel finns i MSBuild-egenskaper.

Behålla virtuell dator

• Konfigurerar om segment som ska tas bort placeras i en väntelista för framtida användning eller släpps tillbaka till operativsystemet (OS).
• Standard: Versionssegment tillbaka till operativsystemet. Detta motsvarar att ange värdet till false.

Exempel

runtimeconfig.json fil:

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

runtimeconfig.template.json fil:

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

Projektfil:

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

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

</Project>

Spara minne

• Konfigurerar skräpinsamlaren för att spara minne på bekostnad av vanligare skräpsamlingar och eventuellt längre paustider.
• Standardvärdet är 0 – det innebär ingen ändring.
• Förutom standardvärdet 0 är värdena mellan 1 och 9 (inklusive) giltiga. Ju högre värde, desto mer försöker skräpinsamlaren spara minne och därmed hålla högen liten.
• Om värdet inte är noll komprimeras den stora objekthögen automatiskt om den har för mycket fragmentering.

Den här konfigurationsinställningen har ingen specifik MSBuild-egenskap. Du kan dock lägga till ett RuntimeHostConfigurationOption MSBuild-objekt i stället. Använd runtimeconfig.json inställningsnamnet som värdet för attributetInclude. Ett exempel finns i MSBuild-egenskaper.

Exempel på app.config-fil :

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

Hantera resursanvändning för Server GC

Följande inställningar påverkar antalet Server GC-trådar och om/hur de är tillhörighet till kärnor. De har ingen effekt på Arbetsstation GC.

• Antal heap
• Tillhörighet
• Tillhörighetsmask
• Tillhörighetsintervall
• CPU-grupper
• DATA

Mer information om de första 3 inställningarna finns i blogginlägget Middle ground between workstation and server GC (Mellanväg mellan arbetsstation och server GC ).

Antal heap

• Begränsar antalet heaps som skapats av skräpinsamlaren.
• Gäller endast för serverskräpinsamling.
• Om GC-processortillhörighet är aktiverat, vilket är standardinställningen för antal heaps, mappas n GC-heaps/trådar till de första n processorerna. (Använd inställningarna för tillhörighetsmask eller tillhörighetsintervall för att ange exakt vilka processorer som ska mappas.)
• Om GC-processortillhörighet är inaktiverad begränsar den här inställningen antalet GC-heaps.
• Mer information finns i GCHeapCount-kommentarerna.

Den här konfigurationsinställningen har ingen specifik MSBuild-egenskap. Du kan dock lägga till ett RuntimeHostConfigurationOption MSBuild-objekt i stället. Använd runtimeconfig.json inställningsnamnet som värdet för attributetInclude. Ett exempel finns i MSBuild-egenskaper.

Exempel

runtimeconfig.json fil:

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

runtimeconfig.template.json fil:

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

Tillhörighet

• Anger om skräpinsamlingstrådar ska mappas till processorer. Om du vill mappa en GC-tråd innebär det att den bara kan köras på sin specifika CPU. En heap skapas för varje GC-tråd.
• Gäller endast för serverskräpinsamling.
• Standard: Mappa skräpinsamlingstrådar med processorer. Detta motsvarar att ange värdet till false.

Den här konfigurationsinställningen har ingen specifik MSBuild-egenskap. Du kan dock lägga till ett RuntimeHostConfigurationOption MSBuild-objekt i stället. Använd runtimeconfig.json inställningsnamnet som värdet för attributetInclude. Ett exempel finns i MSBuild-egenskaper.

Exempel

runtimeconfig.json fil:

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

runtimeconfig.template.json fil:

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

Tillhörighetsmask

• Anger de exakta processorer som skräpinsamlingstrådar ska använda.
• Om GC-processortillhörighet är inaktiverad ignoreras den här inställningen.
• Gäller endast för serverskräpinsamling.
• Värdet är en bitmask som definierar de processorer som är tillgängliga för processen. Till exempel är ett decimalvärde på 1023 (eller ett hexadecimalt värde på 0x3FF eller 3FF om du använder miljövariabeln) 0011 1111 1111 i binär notation. Detta anger att de första 10 processorerna ska användas. Om du vill ange nästa 10 processorer, dvs. processorer 10–19, anger du ett decimalvärde på 1047552 (eller ett hexadecimalt värde på 0xFFC00 eller FFC00), vilket motsvarar ett binärt värde på 1111 1111 1100 0000 0000.

Den här konfigurationsinställningen har ingen specifik MSBuild-egenskap. Du kan dock lägga till ett RuntimeHostConfigurationOption MSBuild-objekt i stället. Använd runtimeconfig.json inställningsnamnet som värdet för attributetInclude. Ett exempel finns i MSBuild-egenskaper.

Exempel

runtimeconfig.json fil:

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

runtimeconfig.template.json fil:

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

Tillhörighetsintervall

• Anger listan över processorer som ska användas för skräpinsamlingstrådar.
• Den här inställningen liknar System.GC.HeapAffinitizeMask, förutom att du kan ange fler än 64 processorer.
• För Windows-operativsystem prefixar du processornumret eller intervallet med motsvarande CPU-grupp, till exempel "0:1-10,0:12,1:50-52,1:7". Om du inte har fler än 1 CPU-grupp kan du inte använda den här inställningen. Du måste använda inställningen Mappningsmask . Och de tal som du anger finns i den gruppen, vilket innebär att det inte kan vara >= 64.
• För Linux-operativsystem, där cpu-gruppkonceptet inte finns, kan du använda både den här inställningen och inställningen Tillhörighetsmask för att ange samma intervall. Och i stället för "0:1-10" anger du "1–10" eftersom du inte behöver ange ett gruppindex.
• Om GC-processortillhörighet är inaktiverad ignoreras den här inställningen.
• Gäller endast för serverskräpinsamling.
• Mer information finns i Göra CPU-konfigurationen bättre för GC på datorer med > 64 processorer på Maoni Stephens blogg.

Den här konfigurationsinställningen har ingen specifik MSBuild-egenskap. Du kan dock lägga till ett RuntimeHostConfigurationOption MSBuild-objekt i stället. Använd runtimeconfig.json inställningsnamnet som värdet för attributetInclude. Ett exempel finns i MSBuild-egenskaper.

Exempel

runtimeconfig.json fil:

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

runtimeconfig.template.json fil:

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

CPU-grupper

• Konfigurerar om skräpinsamlaren använder CPU-grupper eller inte.

  När en 64-bitars Windows-dator har flera CPU-grupper, det vill sa att det finns fler än 64 processorer, utökar aktiveringen av det här elementet skräpinsamling över alla CPU-grupper. Skräpinsamlaren använder alla kärnor för att skapa och balansera högar.

  Kommentar

  Det här är ett begrepp som endast gäller Windows. I äldre Windows-versioner begränsade Windows en process till en processorgrupp. Därför använde GC bara en CPU-grupp om du inte använde den här inställningen för att aktivera flera CPU-grupper. Den här os-begränsningen hävdes i Windows 11 och Server 2022. Från och med .NET 7 använder GC som standard alla CPU-grupper när de körs på Windows 11 eller Server 2022.

• Gäller endast för serverskräpinsamling på 64-bitars Windows-operativsystem.

• Standard: GC sträcker sig inte över cpu-grupper. Detta motsvarar att ange värdet till 0.

• Mer information finns i Göra CPU-konfigurationen bättre för GC på datorer med > 64 processorer på Maoni Stephens blogg.

Den här konfigurationsinställningen har ingen specifik MSBuild-egenskap. Du kan dock lägga till ett RuntimeHostConfigurationOption MSBuild-objekt i stället. Använd runtimeconfig.json inställningsnamnet som värdet för attributetInclude. Ett exempel finns i MSBuild-egenskaper.

Dynamisk anpassning till programstorlekar (DATAS)

Aktivera eller inaktivera DATAS

• Konfigurerar skräpinsamlaren att använda DATAS. DATAS anpassar sig till kraven på programminne, vilket innebär att appens heapstorlek ska vara ungefär proportionell mot den långlivade datastorleken.
• Aktiverad som standard med början i .NET 9.

Den här konfigurationsinställningen har ingen specifik MSBuild-egenskap. Du kan dock lägga till ett RuntimeHostConfigurationOption MSBuild-objekt i stället. Använd runtimeconfig.json inställningsnamnet som värdet för attributetInclude. Ett exempel finns i MSBuild-egenskaper.

Mål-TCP

DATAS använder TCP (Throughput Cost Percentage) som minneskostnadsmätning för dataflöde. Det tar hänsyn till både GC-pauser och hur mycket allokeringar som måste vänta. Vanligtvis dominerar GC-pauser, så du kan använda "% paustid i GC" för att beräkna den här kostnaden. Det finns två tillfälliga fall där allokeringsväntetiden kan dominera:

• När en process startar börjar DATAS alltid med en heap. Så om det finns tillräckligt med trådar allokering, får de vänta.
• När arbetsbelastningen ändras från lättare till tyngre, till exempel när tider med hög belastning börjar, kan allokering av trådar uppleva väntetider under den tidsperioden. Det beror på att det tar några GCs innan antalet heaps ökar.

DATAS använder 2% som standard-TCP, som du kan justera med den här inställningen. Det är ett heltal som tolkas som en procentandel, till exempel innebär 5 att mål-TCP blir 5%.

Den här konfigurationsinställningen har ingen specifik MSBuild-egenskap. Du kan dock lägga till ett RuntimeHostConfigurationOption MSBuild-objekt i stället. Använd runtimeconfig.json inställningsnamnet som värdet för attributetInclude. Ett exempel finns i MSBuild-egenskaper.

Maxbudgetinställningar för Gen0

Att justera gen0-budgeten är ett av de viktigaste elementen som DATAS använder för att anpassa till programstorlekar. DATAS definierar ett övre tröskelvärde som kallas BCD (budgetberäknad via DATAS) för den totala gen0-budgeten som en funktion av programstorleken. Formeln för att beräkna en multiplikator är följande:

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

Formeln kläms sedan fast med ett högsta och minsta värde innan den tillämpas på programstorleken i MB. Om inställningen spara minne inte har angetts använder DATAS som standard 5. Det maximala och lägsta värdet är som standard 10 respektive 0,1.

Om programstorleken till exempel är 1 GB beräknar (20 - 5) / sqrt (1000) = 0.474formeln . Eftersom det är mellan 10 och 0,1 har klämning ingen effekt. Det innebär att den totala gen0-budgeten är 47,4% på 1 GB, vilket är 474 MB. Om programstorleken är 1 MB beräknar formeln 15 som sedan justeras till 10, vilket innebär att den totala tillåtna gen0-budgeten är 10 MB.

Det finns tre inställningar för att justera vad formeln beräknar och ändra klämvärdena:

• Den procent som ska tillämpas på det som f beräknas.

  	Inställningsnamn	Värden	Version introducerad
  runtimeconfig.json	System.GC.DGen0GrowthPercent	Decimalvärde	.NET 10
  Miljövariabel	DOTNET_GCDGen0GrowthPercent	hexadecimalt värde	.NET 10

  Den här konfigurationsinställningen har ingen specifik MSBuild-egenskap. Du kan dock lägga till ett RuntimeHostConfigurationOption MSBuild-objekt i stället. Använd runtimeconfig.json inställningsnamnet som värdet för attributetInclude. Ett exempel finns i MSBuild-egenskaper.

  Så om f beräknar 0,474 och den här inställningen är 200, blir 0.474 * 200% = 0.948 multiplikatorn innan klämningen tillämpas.

• Det högsta fastspänningsvärdet i permil.

  	Inställningsnamn	Värden	Version introducerad
  runtimeconfig.json	System.GC.DGen0GrowthMaxFactor	Decimalvärde	.NET 10
  Miljövariabel	DOTNET_GCDGen0GrowthMaxFactor	hexadecimalt värde	.NET 10

  Den här konfigurationsinställningen har ingen specifik MSBuild-egenskap. Du kan dock lägga till ett RuntimeHostConfigurationOption MSBuild-objekt i stället. Använd runtimeconfig.json inställningsnamnet som värdet för attributetInclude. Ett exempel finns i MSBuild-egenskaper.

  Om det här värdet är 20000 innebär det att det maximala fastspänningsvärdet är 20000 * 0.001 = 20.

• Minsta fastspänningsvärde i permil.

  	Inställningsnamn	Värden	Version introducerad
  runtimeconfig.json	System.GC.DGen0GrowthMinFactor	Decimalvärde	.NET 10
  Miljövariabel	DOTNET_GCDGen0GrowthMinFactor	hexadecimalt värde	.NET 10

  Den här konfigurationsinställningen har ingen specifik MSBuild-egenskap. Du kan dock lägga till ett RuntimeHostConfigurationOption MSBuild-objekt i stället. Använd runtimeconfig.json inställningsnamnet som värdet för attributetInclude. Ett exempel finns i MSBuild-egenskaper.

  Om det här värdet är 200 är 200 * 0.001 = 0.2det minsta fastspänningsvärdet .