Delen via

Werkstation en server geheugenzorg

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:

  • Werkstationvuilnisophaling (GC), dat is ontworpen voor clienttoepassingen. Het is de standaard GC-type voor zelfstandige apps. Voor gehoste apps, bijvoorbeeld die worden gehost door ASP.NET, bepaalt de host het standaard GC-type.

    Werkstationafvalverzameling kan gelijktijdig of niet-gelijktijdig zijn. Gelijktijdige (of achtergrond) vuilnisophaling zorgt ervoor dat beheerde threads kunnen doorgaan met hun bewerkingen tijdens een vuilnisophaling. Achtergrond-garbagecollectie vervangt gelijktijdige-garbagecollectie in .NET Framework 4 en latere versies.

  • Server-garbagecollection, bedoeld voor serverapplicaties die een hoge doorvoer en schaalbaarheid vereisen.

    • In .NET Core kan garbagecollection op de server niet-concurrent of op de achtergrond zijn.

    • In .NET Framework 4.5 en latere versies kan de garbageverzameling van de server niet-concurrent of op de achtergrond plaatsvinden. 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:

Threads voor garbagecollection van de server

Prestatie-overwegingen

Werkplek GC

Hier volgen threading- en prestatieoverwegingen voor garbagecollection van werkstations:

  • De verzameling wordt uitgevoerd op de gebruikersthread die de afvalverzameling heeft geactiveerd en behoudt 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_HIGHEST prioriteitsniveau.

  • Een heap en een speciale thread voor het uitvoeren van afvalverzameling worden beschikbaar gesteld 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 in verschillende heaps kunnen naar elkaar verwijzen.

  • Omdat meerdere vuilnisophaling-threads samenwerken, is de vuilnisophaling van de server sneller dan die van het werkstation op een even grote heap.

  • De afvalverzameling 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 vuilnisopruimer 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 toevallig tegelijkertijd geheugenopruiming uitvoeren, zouden ze elkaar verstoren, omdat er 12 threads aangestuurd zouden worden door dezelfde logische CPU. Als de processen actief zijn, is het geen goed idee om ze allemaal server GC te laten gebruiken.

Wanneer u honderden exemplaren van een toepassing draait, kunt u overwegen om vuilophaal van werkstations te gebruiken waarbij gelijktijdige vuilophaal is uitgeschakeld. Dit leidt tot minder contextwisselingen, waardoor de prestaties kunnen worden verbeterd.

Zie ook