SQL Server devient plus lent au fil du temps jusqu'à ce que nous devions le redémarrer

Nous avons une base de données avec une charge de travail mixte OLAP / OLTP. Les requêtes sont assez ponctuelles et sont créées dynamiquement dans le serveur d'applications de niveau intermédiaire. Lorsque nous démarrons le serveur, les performances sont tout à fait acceptables, mais la consommation de mémoire augmente de plus en plus jusqu'à ce que toute la mémoire disponible (30 Go) soit épuisée. Après cela, le système devient de plus en plus lent.

Les commandes comme Dbcc freeproccachen'ont aucun effet.

Il n'y a pas beaucoup de transactions select * from sys.dm_tran_session_transactions(pas plus que lorsque le système fonctionne bien), cette liste est parfois vide.

Le premier résultat dbcc memorystatusest -

VM Reserved               42136628
VM Committed               1487176
Locked Pages Allocated    24994048
Reserved Memory               1024
Reserved Memory In Use           0

Un redémarrage de SQL Server résout le problème pendant un certain temps.

1. Qu'est-ce qui cause ce comportement? comment ca peut etre evite?
2. Si une véritable solution à la cause est trop difficile, existe-t-il une commande qui force SQL Server à libérer toute la mémoire sans redémarrage complet du SGBD?

Le serveur fonctionne sur du matériel dédié (pas une VM). Nous avions des emplois programmés, mais nous les avons désactivés pendant un certain temps, sans changement. Il existe d'autres applications de niveau intermédiaire exécutées sur le même serveur, mais elles n'utilisent pas plus de 2 Go de mémoire, un processeur négligeable et presque aucune E / S. Nous avons redémarré toutes ces applications sans changement.

Je suggérerais de collecter des mesures de performances sur ce serveur, afin que vous puissiez éliminer les conjectures de dépannage de ces types de problèmes. Consultez cet article pour un guide plus complet si vous ne savez pas par où commencer.

En particulier, je voudrais vérifier les compteurs de performances Memory\Available MByteset Paging File(_Total)\% Usageparce que vous avez dit que les problèmes ne se produisent que lorsque le pool de tampons est plein. Les chiffres que vous obtenez de ces compteurs peuvent indiquer que le paramètre de mémoire maximale du serveur doit être ajusté (vers le haut ou vers le bas) pour la quantité de mémoire physique allouée au serveur. Comme je l'ai mentionné ici , je ne recommande pas de baser le paramètre de mémoire maximale sur la quantité de mémoire physique, sauf comme supposition éclairée pour un point de départ . Mesurez toujours le résultat et ajustez à partir de là.

Si la quantité de mémoire libre est trop faible (<500) ou si l'utilisation du fichier d'échange est supérieure à zéro , cela peut indiquer que l'instance SQL Server est surchargée: sur SQL Server 2008 R2, le paramètre de mémoire maximale du serveur contrôle uniquement la taille du pool de mémoire tampon , et non pas une autre utilisation de la mémoire telle que le cache de plan. SQL Server ne se soucie pas non plus des autres applications que vous pourriez avoir en cours d'exécution sur le système. Cette utilisation supplémentaire de la mémoire peut exercer une pression sur la mémoire de Windows - ou des autres applications - pouvant entraîner un échange de disque. C'est quelque chose que vous voulez éviter à tout prix, en particulier si le fichier d'échange existe sur un volume soutenu par un simple miroir RAID 1. Mon sentiment est que c'est le problème, et la suppression du paramètre de mémoire maximale du serveur devrait résoudre le problème.

Si la quantité de mémoire libre est élevée (> 1000) et que l'utilisation du fichier d'échange est nulle, vous pouvez probablement augmenter légèrement la mémoire maximale du serveur (par incréments de 256 Mo) pour maximiser l'utilisation de la mémoire du serveur. Cela ne résoudra probablement pas le problème, cependant, et vous devrez regarder ailleurs, probablement sur les compteurs de disques physiques et l'espérance de vie de la page du pool de mémoire tampon. Si les requêtes détruisent le pool de mémoire tampon, vous ne pouvez rien faire sauf améliorer les performances du disque, augmenter la quantité de mémoire physique disponible pour le serveur afin que toutes les pages de données puissent tenir en mémoire en même temps ou modifier la base de données pour ne pas en prendre autant l'espace physique (peut-être en utilisant la compression de lignes ou de pages, ou en reconstruisant les index avec un plus élevé FILLFACTOR).

J'ai publié un article sur ce sujet ici qui va plus en profondeur sur cette question et comment le résoudre.

En général, la tendance à la lenteur dans le temps devrait être inversée, car à mesure que les pages de bases de données se déplacent dans le cache, les performances devraient s'améliorer (l'espérance de vie des pages et le taux de réussite du tampon augmentent avec le temps), avez-vous défini votre mémoire maximale sur (total_physical_mem - 2 Go)?

Il semble que quelques-unes de vos requêtes entraînent la sortie et la mise en page de SQL Server dans beaucoup de choses. Vous pouvez essayer le gouverneur de ressources pour limiter la consommation de mémoire des grandes requêtes et des requêtes moyennes, afin que les requêtes d'application disposent toujours de suffisamment de mémoire tampon.