Types de collecte de déchets dans .Net Core

La gestion de la mémoire dans les langages modernes est souvent une réflexion après coup. À toutes fins utiles, nous écrivons des logiciels sans jamais penser à la mémoire. Cela nous sert bien mais il y a toujours des exceptions…

En Californie, il existe des exigences étendues de rapports financiers pour les Agences d’Éducation Locales (LEA), une LEA peut être un comté, un district, une école à charte ou une école unique. La plupart des LEA créent leurs propres rapports financiers qui sont généralement centrés autour d’Excel, il n’est pas surprenant que chaque rapport soit différent. Pour résoudre ce problème, le Conseil d’Éducation de Californie a commandé un logiciel pour générer des rapports financiers.

J’ai fait partie de l’équipe de développement.

Mon premier arrêt a été les journaux de test, les journaux d’Ed-Pro pointaient vers une utilisation élevée de la mémoire, peut-être y avait-il une fuite de mémoire ? Un ingénieur a observé que les calculs d’Ed-Pro utilisaient une grande quantité de mémoire de courte durée. Si la mémoire n’était pas nettoyée rapidement, cela pourrait ressembler à une fuite de mémoire.

Ed-Pro est construit sur .Net Core, le framework multi-plateforme de Microsoft. Dans .Net Core, la mémoire est divisée en trois catégories : Courte durée (Gen0), durée moyenne (Gen1), et longue durée (Gen2). Gen0 est pour les données de courte durée qui sortent rapidement de la portée, Gen1 est pour la mémoire de durée moyenne qui reste un peu plus longtemps, elle finit aussi par sortir de la portée et Gen2 est la mémoire de longue durée qui peut vivre pendant toute la durée de l’application. La mémoire Gen0 est constamment récupérée, Gen1 est récupérée moins fréquemment que Gen0, et Gen2 est récupérée encore moins fréquemment que Gen1.

La seule façon sûre de comprendre l’utilisation de la mémoire d’Ed-Pro était de la profiler, ci-dessous une capture d’écran utilisant dotMemory de JetBrains.

Comme suspecté, nous avons trouvé de grandes quantités de mémoire Gen0 (le bleu), tellement que la Collecte de Déchets ne semblait pas pouvoir suivre. Une stratégie pour compenser une grande quantité de mémoire a causé une oscillation de la Collecte de Déchets entre l’augmentation de l’espace mémoire (ajout de plus de mémoire pour l’utilisation de l’application) et son nettoyage. Pendant les cycles de nettoyage, l’application ne répond plus.

Au début, nous étions perplexes, le but du GC n’est-il pas de maintenir la mémoire propre ? Deux articles ont été instrumentaux dans notre compréhension du fonctionnement de la Collecte de Déchets dans .Net : l’article de Mark Vincze Dépannage de l’utilisation élevée de la mémoire avec ASP.Net Core sur Kubernetes et Fondamentaux de la Collecte de Déchets par Microsoft. Les deux sont d’excellentes lectures et ont apporté de la clarté à l’utilisation de la mémoire dans Ed-Pro.

Voici un résumé de ce que nous avons appris, il y a deux types de Collecte de Déchets dans .Net : la Collecte de Déchets Serveur et la Collecte de Déchets Station de Travail.

La Collecte de Déchets Serveur fait quelques suppositions : Premièrement, il y a amplement de mémoire disponible et deuxièmement, les processeurs sont multi-cœurs et sont rapides. Les deux peuvent être vraies, mais nous vivons dans un monde de machines virtuelles et Docker où il est plus probable que les deux suppositions soient fausses.

La Collecte de Déchets Serveur permet à la mémoire de s’accumuler, à un certain point, elle fait l’une de deux choses : soit elle augmente l’espace mémoire permettant à la mémoire de croître, soit elle libère la mémoire orpheline. Quand elle choisit de libérer la mémoire, la Collecte de Déchets démarre le processus sur un thread de haute priorité. Le thread de haute priorité a une priorité plus élevée que l’application ; si la machine est rapide, le nettoyage ne devrait pas être remarqué. Cependant, si elle ne l’est pas, cela causera l’arrêt de l’application jusqu’à ce que le nettoyage soit terminé.

La Collecte de Déchets Station de Travail fonctionne différemment. Elle fonctionne continuellement en récupérant la mémoire sur un thread avec la même priorité que l’application. Cela signifie qu’elle est aussi en compétition pour les ressources avec l’application, ce qui peut causer un ralentissement de l’application. L’avantage est que l’utilisation de la mémoire de l’application peut rester assez faible, principalement quand elle utilise de grandes quantités de Gen0.

Par défaut, si .Net Core détecte un serveur, il exécute le type Collecte de Déchets Serveur, ce qui était le cas avec notre application. Pour exécuter le type Collecte de Déchets Station de Travail, ajoutez l’extrait suivant à votre fichier projet :

  <PropertyGroup> 
    <ServerGarbageCollection>false</ServerGarbageCollection>
  </PropertyGroup>

Nous avons fait ce changement de configuration à Ed-Pro, en utilisant dotMemory, nous avons profilé la mémoire d’Ed-Pro avec la Collecte de Déchets Station de Travail activée et chargé les mêmes écrans que dans le test précédent. Voici les résultats :

L’utilisation de la mémoire est significativement diminuée. Les allocations Gen0 sont virtuellement inexistantes. Au-delà des différences dans le graphique, l’utilisation de la mémoire de la Collecte de Déchets Serveur a atteint 1 giga tandis que la Collecte de Déchets Station de Travail a culminé à environ 200 mégas.

Chaque application est différente. Notre application utilisait une tonne de données temporaires et utilise donc une tonne de mémoire Gen0. Votre application peut exploiter de la mémoire de plus longue durée comme Gen1 ou Gen2 dans laquelle la Collecte de Déchets Serveur a beaucoup de sens. Mon conseil est de profiler votre mémoire sous différentes conditions pour avoir une idée de comment la mémoire est utilisée et ensuite décider quel mode est le meilleur pour votre application.