SQL Server occupe plus que la mémoire allouée. Fuite de mémoire possible
Utilisation de SQL Server 2012 64 bits (v11.0.6020.0 - 2012 SP3)
Voici le scénario:
Sur notre production, nous avons 32 Go de DDR3 RAM installé:
La limite de mémoire maximale a été fixée dans le serveur SQL à 16 Go, soit une capacité de 50%:
Lorsque je lance le gestionnaire de tâches et vérifie la mémoire occupée en valeur, cela montre 16 Go, ce qui est correct:
Mais lorsque je sélectionne la mémoire occupée par Pourcentage, elle affiche 80% -85%, ce qui n'est PAS DROIT:
Cela continuera d'augmenter jusqu'à ce qu'il occupe plus de 95% et
- Tout le système va ralentir
- Les requêtes expireront
La seule façon de corriger cela est un redémarrage du serveur
Mes questions sont
- SQL Server perd-il de la mémoire?
- Une solution rapide pour ne pas avoir à redémarrer?
- Résolution permanente?
Mes questions sont la fuite de mémoire de SQL Server?
Très peu probable, mais vous devez planifier SQL Server 2012 SP4 dès que possible. D'après mon expérience passée, je pourrais dire que, puisque SQL Server et d'autres applications comme SSAS et SSRS s'exécutent tous sur la même machine, SQL Server peut être confronté à une pression mémoire et il en va de même pour SSAS/RS. J'ai vu beaucoup de systèmes comme celui-ci et tout se résume à la pression de la mémoire.
Vous avez 32 G de RAM et vous avez donné seulement 16 G à SQL Server pour atteindre 20 G et voir si cette aide. Ajouter plus de mémoire serait certainement utile si vous pouvez y aller.
Il peut y avoir une pléthore de raisons pour lesquelles les requêtes expirent et Dépannage des problèmes de performances de SQL Server peut vous aider à en trouver la cause première.
Mais lorsque je sélectionne la mémoire occupée par Pourcentage, elle affiche 80% -85%, ce qui n'est PAS DROIT:
Je commencerais par dire que le Gestionnaire des tâches n'est pas un endroit correct pour évaluer la consommation de mémoire de SQL Server, il ne vous dira pas la valeur correcte lorsque le compte de service SQL Server a privilège Pages verrouillées en mémoire (LPIM) . Cela est dû au fait que normalement le gestionnaire de tâches suit la mémoire Process Private bytes qui est paginable et allouée via la fonction VirtualAlloc (), mais avec une portion LPIM d'allocation de mémoire effectuée par l'API AWE qui est NON paginable, le gestionnaire de tâches ne la suit pas et cela peut conduire à une erreur valeur. Pour le pourcentage que vous recherchez, c'est en fait Percentage of Process Private bytes pas la mémoire complète et elle ne fournit aucune information pertinente, alors arrêtez de la regarder.
Il est tout à fait normal que SQL Server utilise la mémoire qui lui est allouée et pour connaître la quantité de mémoire physique que SQL Server utilise, veuillez utiliser la requête
select * from sys.dm_os_process_memory
PS: Il est toujours recommandé de déplacer d'autres applications sur une machine différente (si possible) et de laisser SQL Server s'exécuter uniquement sur son propre système, cela aidera SQL Server à fonctionner plus rapidement et mieux
La réponse est détaillée dans un article KB .
SQL Server 2012 et les versions ultérieures peuvent allouer plus de mémoire que la valeur spécifiée dans le paramètre de mémoire maximale du serveur. Ce problème peut se produire lorsque la valeur de la mémoire totale du serveur (Ko) a déjà atteint le paramètre de mémoire du serveur cible (Ko) (comme spécifié par la mémoire maximale du serveur). Si la mémoire libre contiguë est insuffisante pour répondre à la demande de demandes de mémoire de plusieurs pages (plus de 8 Ko) en raison de la fragmentation de la mémoire, SQL Server peut effectuer un sur-engagement au lieu de rejeter la demande de mémoire.
Il est plus probable que vous rencontriez ce problème que vous ayez découvert un bug ou une fuite de mémoire.
Vous devez suivre les conseils des autres réponses publiées: appliquez le SP4 et réfléchissez plus attentivement aux autres applications et composants que vous empilez sur la boîte SQL Server pour laquelle vous payez des milliers de dollars par cœur.
Non. C'est normal. Vous rencontrez trop d'applications installées sur votre serveur de base de données. Démarrez la migration de votre base de données (moteur de base de données SQL Server) vers son propre serveur ou commencez à désinstaller toutes les autres applications du serveur de base de données.
Actuellement, votre serveur dispose des éléments suivants: IIS, RS, AS, IS, mongodb installés. Sans mentionner si vous avez installé des outils de surveillance ou un antivirus. Lorsque vous vous connectez au serveur, vous utilisez également de la mémoire. les pilotes de filtre utilisent également la mémoire.
Consultez cet article de blog par Jonathan . Disons que vous avez un serveur de base de données barebone (sans que l'autre application ne lutte pour la mémoire), vous pouvez au moins avoir 27 Go de mémoire pour votre serveur SQL.