Werkstation en server garbagecollection
De garbagecollector is zelfafstemming en kan in een groot aantal scenario's werken. U kunt echter het type garbagecollection instellen op basis van de kenmerken van de werkbelasting. De CLR biedt de volgende typen garbagecollection:
Werkstation garbagecollection (GC), dat is ontworpen voor client-apps. Dit is de standaard GC-smaak voor zelfstandige apps. Voor gehoste apps, bijvoorbeeld die worden gehost door ASP.NET, bepaalt de host de standaard GC-smaak.
Garbagecollection van werkstation kan gelijktijdig of niet gelijktijdig zijn. Gelijktijdige (of achtergrond) garbagecollection zorgt ervoor dat beheerde threads bewerkingen kunnen voortzetten tijdens een garbagecollection. De garbagecollection op de achtergrond vervangt gelijktijdige garbagecollection in .NET Framework 4 en latere versies.
Garbagecollection van de server, die is bedoeld voor servertoepassingen die hoge doorvoer en schaalbaarheid nodig hebben.
In .NET Core kan de garbagecollection van de server niet gelijktijdig of achtergrond zijn.
In .NET Framework 4.5 en latere versies kan de garbagecollection van de server niet gelijktijdig of achtergrond zijn. In .NET Framework 4 en eerdere versies is de garbagecollection van de server niet gelijktijdig.
In de volgende afbeelding ziet u de toegewezen threads die de garbagecollection op een server uitvoeren:
Prestatieoverwegingen
Werkstation GC
Hier volgen threading- en prestatieoverwegingen voor garbagecollection van werkstations:
De verzameling vindt plaats op de gebruikersthread die de garbagecollection heeft geactiveerd en blijft dezelfde prioriteit. Omdat gebruikersthreads doorgaans op normale prioriteit worden uitgevoerd, moet de garbagecollector (die wordt uitgevoerd op een normale prioriteitsthread) concurreren met andere threads voor CPU-tijd. (Threads waarop systeemeigen code wordt uitgevoerd, worden niet onderbroken op de server of op het werkstation garbagecollection.)
Garbagecollection van werkstations wordt altijd gebruikt op een computer met slechts één logische CPU, ongeacht de configuratie-instelling.
Server GC
Hier volgen threading- en prestatieoverwegingen voor de garbagecollection van de server:
De verzameling vindt plaats op meerdere toegewezen threads. In Windows worden deze threads uitgevoerd op
THREAD_PRIORITY_HIGHESTprioriteitsniveau.Een heap en een toegewezen thread voor het uitvoeren van garbagecollection worden geleverd voor elke logische CPU en de heaps worden op hetzelfde moment verzameld. Elke heap bevat een kleine object heap en een grote object heap, en alle heaps zijn toegankelijk via gebruikerscode. Objecten op verschillende heaps kunnen naar elkaar verwijzen.
Omdat meerdere garbagecollection-threads samenwerken, is de garbagecollection van de server sneller dan de garbagecollection van het werkstation op dezelfde grootte heap.
De garbagecollection van de server heeft vaak grotere segmenten. Dit is echter alleen een generalisatie: segmentgrootte is implementatiespecifiek en kan worden gewijzigd. Maak geen veronderstellingen over de grootte van segmenten die door de garbagecollector worden toegewezen bij het afstemmen van uw app.
De garbagecollection van de server kan resource-intensief zijn. Stel dat er 12 processen zijn die gebruikmaken van server-GC die worden uitgevoerd op een computer met vier logische CPU's. Als alle processen tegelijkertijd garbagecollection veroorzaken, zouden ze elkaar verstoren, omdat er 12 threads gepland zouden zijn op dezelfde logische CPU. Als de processen actief zijn, is het geen goed idee om ze allemaal server GC te laten gebruiken.
Als u honderden exemplaren van een toepassing uitvoert, kunt u overwegen om garbagecollection van werkstations te gebruiken waarbij gelijktijdige garbagecollection is uitgeschakeld. Dit leidt tot minder contextwisselingen, waardoor de prestaties kunnen worden verbeterd.
