Comprendre le cache SQL Server
J'ai une question délicate et je ne sais pas exactement où trouver les informations pertinentes à ce sujet.
J'ai installé SQL Server 2014 Enterprise sur un serveur de base de données. Sur ce serveur, il existe plusieurs bases de données, certaines nous appartiennent et d'autres appartiennent à d'autres sociétés.
Ma préoccupation concerne la mémoire cache. J'ai une compréhension de base de la façon dont SQL Server utilise la mémoire cache pour récupérer rapidement les pages de données. Vous exécutez une requête, et généralement, les pages de données sont chargées dans le cache et avec des appels répétables, il en obtient les résultats.
Mais ... notre application est très utilisée dans les heures de travail habituelles par nos clients mais la nuit, il y a toujours des tâches de maintenance en cours. Je suppose (veuillez me dire si je me trompe) que pendant la journée, le cache est chargé de pages de données utiles, mais la nuit, il est supprimé en raison des tâches de maintenance, et donc le lendemain, lorsque les clients commencent à faire des transactions, les pages de données doivent d'abord être à nouveau chargées dans le cache, ce qui prend du temps et ralentit beaucoup de choses.
Alors, puis-je prouver en quelque sorte si cela se produit?
Si oui, puis-je le gérer? Tels que dire en quelque sorte à SQL Server de ne pas charger dans le cache?
Je serais reconnaissant pour certains articles spécifiques traitant de ce sujet. Je n'ai pu en trouver, ou mieux dire, je ne sais pas comment nommer ce problème.
mais la nuit, il est supprimé en raison de la tâche de maintenance
Je ne dirais pas supprimé comme plus "écrasé" ou "expulsé". La maintenance peut simplement utiliser la mémoire pour d'autres choses. Pas un gros problème normalement.
et donc le lendemain, lorsque les clients effectuent des transactions, les pages de données doivent à nouveau être chargées dans le cache, ce qui prend du temps et ralentit beaucoup de choses.
Si c'est vraiment le cas le plus brutal, vous avez un cas Edge ou un problème matériel.
Généralement, vous pouvez préconfigurer le cache en exécutant un certain nombre de "requêtes de maintenance" tôt le matin (pour recharger les données dans le cache à 6h00 du matin par exemple) dans le cadre de la maintenance. C'est à dire. vous le terminez en demandant les données que vous souhaitez charger dans le cache. Problème résolu.
Mais généralement, cela ne devrait pas entraîner un ralentissement EXTRÊME - oui, les demandes initiales seront plus lentes, mais cela devrait se réparer assez rapidement car le cache va se remplir à chaque requête. Est-il possible que votre ralentissement expérimenté ne soit pas "cache" mais "pic du matin"? Il existe de nombreux systèmes où, à des moments précis (l'un d'eux le matin lorsque les gens se connectent et vérifient leur travail), la charge est beaucoup plus élevée que plus tard dans la journée. Dans ce cas, vous devez faire évoluer le matériel pour gérer cela. Je serais parmi les premières fois où j'aurais considéré la maintenance comme un problème très important.
Vous recherchez probablement PLE, ou Page Life Expectancy . Le PLE est le nombre de secondes qu'une page de données réside dans le cache en moyenne.
SQL Server renvoie uniquement les valeurs à l'application ou au client une fois qu'elles sont dans le pool de cache/tampon. Vous verrez une pression de mémoire ou un PLE très faible si votre instance n'a pas assez de mémoire/RAM pour effectuer des opérations gourmandes en données. Cela signifie que SQL Server déplace constamment les pages de données dans le cache, puis les pellette pour faire de la place aux autres pages de données dont il a besoin et effectue des lectures physiques (lecture à partir du disque au lieu de la mémoire, ce qui nécessite beaucoup d'E/S).
Pour prouver ce que vous recherchez, commencez à capturer PLE par nœud sur votre instance toutes les 15 minutes pendant une semaine environ. Vous devriez le voir monter et descendre en fonction de l'utilisation globale et des opérations intensives. Si vous le souhaitez, vous pouvez également rechercher des scripts pour capturer des lectures/écritures sur des opérations coûteuses afin de trouver les requêtes de problèmes.
Dans votre exemple spécifique sur les tâches de maintenance quotidiennes, cela pourrait absolument être un problème. Une série de reconstructions d'index pourrait effacer toutes les pages de données utiles que vos applications utilisent pendant la journée, donc la première fois que ces requêtes/procs/instructions préparées s'exécutent le matin, elles doivent vider certaines pages de données pour faire de la place pour celles nécessaires qui a été lu à partir du disque.
Requête volée sur le DBA Stack Exchange:
SELECT [object_name],
[counter_name],
[cntr_value] FROM sys.dm_os_performance_counters -- https://docs.Microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-os-performance-counters-transact-sql
WHERE [counter_name] = 'Page life expectancy' --if multiple NUMA on a server should return multiple Nodes,
OR [counter_name] = 'Free list stalls/sec' -- Number of requests per second that had to wait for a free page https://docs.Microsoft.com/en-us/sql/relational-databases/performance-monitor/sql-server-buffer-manager-object
OR [counter_name] = 'Lazy writes/sec' --Flushes of dirty pages before a checkpoint runs.
OR [counter_name] = 'Buffer cache hit ratio' --percentage of pages found in the buffer cache without having to read from disk you want this ratio to be high
Order by [counter_name] DESC, [object_name];