Page d'espérance de vie fluide fluctuante sauvagement

Question

Pour des mois maintenant, le PLE sur l'un de nos serveurs a survolé les 2 millions de secondes. S'il est légèrement varié de jour en jour, mais était assez stable là-bas.

Ce dernier week-end, nous avons ajouté 12 Go de RAM virtuel et 1 noyau de CPU virtuel au serveur. Nous n'avons pas changé la RAM maximale utilisée dans SQL Server pour correspondre à la nouvelle RAM, ni nous attribuons le nouveau noyau CPU à SQL Server.

Comme cela a été fait, notre Ple a fluctué sauvagement, allant entre 50 et 4 millions de secondes toutes les 10-30 minutes. Les changements ne sont pas une hausse ou une chute lente. Les métriques vont directement de très bas à très haut et vice versa en moins d'une minute.

Nos temps d'attente globaux pour le serveur vont bien. Les loquets sont normaux. Tampon et planifiez les tailles de cache n'ont pas changé. Il ne semble pas y avoir de schéma cohérent d'une requête ou d'une requête spécifique drainant les ressources.

Je n'ai jamais vu PLE faire cela auparavant. Quelqu'un peut-il me dire ce que je peux manquer ou avoir besoin de regarder plus profondément?

---

Informations supplémentaires des commentaires:

• Nous sommes à 5 processeurs totaux mais qu'utilisez seulement 3 (nous étions à 4 en utilisant 3).
• Notre mémoire totale est de 49 Go et max de SQL est de 28 Go.
• Nous utilisons VMware avec un système d'exploitation X64 (Windows 2008).
• Il y a 14 bases de données utilisateur sur le serveur avec le principal étant d'environ 250 Go.
• Le ratio de cache tampon de tampon est resté environ 98 +% puisque tout cela a commencé.
• Le plan d'alimentation du serveur est défini sur équilibré (pas de performances élevées); Cependant, cela n'a pas changé en plusieurs années. Avec cela dit, je suis tout à fait d'accord, cela devrait être une performance élevée.
• Ni les journaux d'erreur SQL Server NOR Windows Windows indiquent quelque chose de sortir de l'ordinaire.
• L'activité sur le serveur n'a pas changé au cours des dernières semaines.
• Le serveur est au courant de Numa. Le scellé généreux est 4, avec un seuil de coût de 10.

Answer 1

Nous avons heurté la mémoire de 28 Go (la quantité d'origine) à 40 Go, laissant 8 Go de mémoire pour le système d'exploitation et d'autres processus.Immédiatement après tout, tout est retourné à la normale et est resté stable.L'un de nos DBA a spéculé que SQL Server était confondu sur la quantité de mémoire qu'elle avait vraiment disponible.J'avais vérifié la mémoire totale du serveur avant et après et les numéros étaient cohérents avec je vois dans les propriétés du serveur, mais je trouve que l'affirmation est difficile à argumenter contre