Résoudre les problèmes de performances du Gestionnaire de cache et de mémoire

Avant Windows Server 2012, deux problèmes potentiels principaux entraînaient une augmentation de la taille du cache de fichiers système jusqu’à ce que la mémoire disponible soit quasiment épuisée dans le cadre de certaines charges de travail. Quand cette situation donne lieu à un ralentissement du système, vous pouvez déterminer si le serveur est confronté à l’un de ces problèmes.

Compteurs devant faire l’objet d’un monitoring

• Mémoire\Durée de vie moyenne du cache de secours à long terme < 1 800 secondes

• Mémoire\Disponible (en octets, kilo-octets ou mégaoctets)

• Mémoire\Octets résidants du cache système

Si Mémoire\Mégaoctets disponibles est faible et si Mémoire\Octets résidants du cache système consomme une partie importante de la mémoire physique, vous pouvez utiliser RAMMAP pour déterminer à quoi sert le cache.

Le cache de fichiers système contient des structures de données de métafichier NTFS

Ce problème est indiqué par un nombre élevé de pages de métafichier actives dans la sortie RAMMAP, comme le montre la figure suivante. Ce problème a peut-être été observé sur des serveurs occupés avec des millions de fichiers faisant l’objet d’accès, ce qui a entraîné la mise en cache de données de métafichier NTFS qui n’ont pas été libérées du cache.

Le problème était auparavant atténué par l’outil DynCache. Dans Windows Server 2012+, l’architecture a été repensée, et ce problème ne doit plus exister.

Le cache de fichiers système contient des fichiers mappés en mémoire

Ce problème est indiqué par un nombre élevé de pages de fichiers mappés actives dans la sortie de RAMMAP. Cela indique généralement qu’une application sur le serveur ouvre de nombreux fichiers volumineux via l’API CreateFile avec l’indicateur FILE_FLAG_RANDOM_ACCESS défini.

Ce problème est décrit en détail dans l’article de la Base de connaissances 2549369. L’indicateur FILE_FLAG_RANDOM_ACCESS permet au Gestionnaire de cache de conserver les vues mappées du fichier en mémoire aussi longtemps que possible (jusqu’à ce que le Gestionnaire de mémoire cesse de signaler une insuffisance de mémoire). Dans le même temps, cet indicateur signale au Gestionnaire de cache qu’il doit désactiver la préextraction des données de fichiers.

Cette situation a été atténuée dans une certaine mesure par les améliorations apportées au découpage des plages de travail dans Windows Server 2012+. Toutefois, le problème lui-même doit être principalement résolu par le fournisseur de l’application en évitant d’utiliser FILE_FLAG_RANDOM_ACCESS. Une autre solution pour le fournisseur de l’application consiste à utiliser une priorité mémoire faible au moment de l’accès aux fichiers. Pour ce faire, utilisez l’API SetThreadInformation. Les pages accessibles avec une priorité mémoire faible sont supprimées de la plage de travail de manière plus agressive.

Depuis Windows Server 2016, le Gestionnaire de cache atténue davantage ce problème en ignorant FILE_FLAG_RANDOM_ACCESS au moment de la prise de décisions relatives au découpage. Il est donc traité comme n’importe quel autre fichier ouvert sans l’indicateur FILE_FLAG_RANDOM_ACCESS (le Gestionnaire de cache respecte néanmoins cet indicateur pour désactiver la préextraction des données de fichier). Vous pouvez tout de même provoquer un ballonnement du cache système si vous avez un grand nombre de fichiers ouverts avec cet indicateur, et s’ils sont accessibles de manière vraiment aléatoire. Il est vivement recommandé de ne pas permettre aux applications d’utiliser FILE_FLAG_RANDOM_ACCESS.

Le seuil de pages de modifications de fichiers distantes est systématiquement dépassé

Ce problème est indiqué si un système subit des ralentissements occasionnels durant les écritures à partir d’un client distant. Ce problème peut se produire quand une grande quantité de données est écrite d’un client distant rapide vers un serveur de destination lent.

Avant Windows Server 2016, dans ce genre de scénario, si le seuil de pages de modifications dans le cache était atteint, les écritures suivantes se comportaient comme s’il existait une écriture directe. Cela pouvait entraîner le vidage d’une grande quantité de données sur le disque, ce qui pouvait provoquer de longs retards si le stockage était lent ainsi que des expirations de délai d’attente pour la connexion à distance.

Dans Windows Server 2016 et les versions ultérieures, une mesure d’atténuation a été mise en place pour réduire les risques liés aux expirations de délai. Un seuil de pages de modifications distinct pour les écritures distantes a été implémenté. Un vidage inline est effectué en cas de dépassement. Cela peut entraîner des ralentissements occasionnels durant une activité d’écriture intensive, mais cela élimine le risque d’expiration du délai d’attente dans la plupart des cas. Ce seuil de pages de modifications distantes est de 5 Go par fichier par défaut. Pour certaines configurations et charges de travail, une autre valeur est plus efficace.

Si la taille par défaut de 5 Go ne convient pas à votre configuration, il est recommandé d’essayer d’augmenter la limite par incréments de 256 Mo jusqu’à ce que les performances soient satisfaisantes. Soyez conscient des éléments suivants :

• Un redémarrage est nécessaire pour que les changements apportés à cette clé de Registre prennent effet.

• Les unités de RemoteFileDirtyPageThreshold correspondent au nombre de pages (la taille de la page étant gérée par le Gestionnaire de cache). Cela signifie qu’il doit avoir la taille souhaitée en octets, divisée par 4 096.

• Les valeurs recommandées sont 128 Mo <= N <= 50 % de la mémoire disponible.

• Vous pouvez désactiver complètement ce seuil en lui affectant la valeur -1. Cette opération n’est pas recommandée, car cela peut entraîner des expirations de délais d’attente pour les connexions à distance.

Par exemple, si vous souhaitez définir la limite sur 10GiB qui est de 10 737 418 240 octets / 4096 = 2 621 440 qui est une valeur DWORD décimale de 2621440.

Ce seuil peut être contrôlé en utilisant la valeur de Registre suivante.

• Clé : HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
  • Type : DWORD
  • Nom de la valeur: RemoteFileDirtyPageThreshold
  • Données de valeur : Décimale - nombre de pages (format de page gérée par le Gestionnaire de cache).