Share via


Garbage collection de l'OLTP en mémoire

Une ligne de données est considérée comme obsolète si elle a été supprimée par une transaction qui n'est plus active. Une ligne périmée est éligible à l'opération de garbage collection. Voici les caractéristiques du garbage collection dans In-Memory OLTP :

  • Non bloquant. Le garbage collection est distribué dans le temps avec un impact minimal sur la charge de travail.

  • Coopératif. Les transactions utilisateur participent au garbage collection avec le thread garbage-collection.

  • Efficace. Les transactions détachent les lignes obsolètes dans le chemin d'accès (l'index) utilisé. Cela réduit le travail requis lorsque la ligne est finalement supprimée.

  • Réactif. La pression exercée sur la mémoire déclenche un garbage collection agressif.

  • Évolutif. Après la validation, les transactions utilisateur exécutent une partie du travail du garbage collection. Plus l'activité transactionnelle est importante, plus les transactions détachent de lignes obsolètes.

Le garbage collection est contrôlé par le thread principal du garbage collection. Le thread garbage collection principal s'exécute toutes les minutes, ou lorsque le nombre de transactions validées dépasse un seuil interne. Les tâches du garbage collector sont les suivantes :

  • Identifier les transactions qui ont supprimé ou mis à jour un ensemble de lignes et qui ont été validées avant la transaction active la plus ancienne.

  • Identifier les versions de ligne créées par les anciennes transactions.

  • Grouper les anciennes lignes dans une ou plusieurs unités de 16 lignes chacune. Cela a pour but de distribuer le travail du garbage collector dans de plus petites unités.

  • Déplacer ces unités de travail dans la file d'attente du garbage collection, une pour chaque planificateur. Pour plus d’informations, reportez-vous aux DMV du récupérateur de mémoire : sys.dm_xtp_gc_stats (Transact-SQL),sys.dm_db_xtp_gc_cycle_stats (Transact-SQL) et sys.dm_xtp_gc_queue_stats (Transact-SQL).

Après qu'une transaction utilisateur est validée, elle identifie tous les éléments de la file d'attente associés au planificateur sur lequel elle s'exécute et désalloue la mémoire. Si la file d'attente du garbage collection sur le planificateur est vide, il recherche une file d'attente non vide dans le nœud NUMA actuel. En cas de faible activité transactionnelle et en cas de sollicitation de la mémoire, le thread principal garbage-collection peut accéder aux lignes extraites de n'importe quelle file d'attente pour les nettoyer. S'il n'y a aucune activité transactionnelle, par exemple, après avoir supprimé un grand nombre de lignes et s'il n'y a aucune sollicitation de la mémoire, les lignes supprimées ne sont extraites par le garbage collector que quand l'activité transactionnelle reprend ou quant la mémoire est sollicitée.

Voir aussi

Gestion de la mémoire pour l’OLTP en mémoire