Partage via

MSSQLSERVER_17890

  • Article

S’applique à : SQL Server

Détails

Attribut Valeur
Nom du produit SQL Server
ID de l’événement 17890
Source de l’événement MSSQLSERVER
Composant SQLEngine
Nom symbolique SRV_WS_TRIMMED
Texte du message Une partie importante de la mémoire du processus SQL Server a été paginée. Cela peut entraîner une dégradation des performances. Durée : %d secondes. Plage de travail (en Ko) : %I64d, validé (en Ko) : %I64d, utilisation de la mémoire : %d%%.

Explication

Vous pouvez rencontrer le message d’erreur suivant dans le journal des erreurs SQL Server ou dans le journal des événements de l’application Windows.

Une partie importante de la mémoire du processus SQL Server a été paginée. Cela peut entraîner une dégradation des performances. Durée : 0 secondes. Jeu de travail (Ko) : 3383250, validé (Ko) : 9112480, utilisation de la mémoire : 37 %.

Vous pouvez également remarquer une dégradation soudaine des performances avec l’exécution de la requête et toutes les autres opérations sur SQL Server.

Cause

SQL Server surveille les différentes informations relatives aux mémoires relatives au processus SQL Server. Dans ce cas, il a détecté que la plage de travail du processus était inférieure à 50 % de la mémoire processus allouée. Par conséquent, cet avertissement est imprimé. Les causes habituelles de cet avertissement sont les suivantes :

  • Le système d’exploitation pages de grandes parties de la mémoire validée SQL Server dans le fichier de pagination.
  • Cela peut être dû à une demande croissante soudaine de mémoire provenant d’autres applications ou des besoins du système d’exploitation.
  • Cela peut également se produire lorsque certains pilotes de périphérique demandent des allocations de mémoire contiguës pour leurs besoins.

Action utilisateur

Vous pouvez empêcher le système d’exploitation Windows de paginer la mémoire du pool de mémoires tampons du processus SQL Server en verrouillant la mémoire allouée pour le pool de mémoires tampons en mémoire physique. Vous verrouillez la mémoire en affectant les pages de verrouillage en mémoire au droit utilisateur du compte d’utilisateur utilisé comme compte de démarrage du service SQL Server. Mais avant d’implémenter cette solution, passez en revue les sections Ce qui entraîne la pagination de la mémoire de SQL Server et Considérations importantes avant d’attribuer le droit utilisateur « Verrouiller les pages en mémoire » pour une instance SQL Server

Remarque

L’utilisation des pages de verrouillage en mémoire garantit que la mémoire gérée par SQL Server n’est pas paginée. Toutefois, les piles de threads, l’EXE et toutes les images DLL, mémoire du tas, mémoire CLR peuvent toujours être paginées par le système d’exploitation.

À compter de SQL Server 2008 SP1 Cumulative Update 2, les éditions SQL Server Standard et Enterprise peuvent utiliser les pages lock in memory user right. Pour plus d’informations sur la prise en charge des pages verrouillées, consultez KB970070 - Prise en charge des pages verrouillées sur les systèmes SQL Server Standard Edition (64 bits).

Pour affecter le droit utilisateur Verrouiller les pages en mémoire, procédez comme suit :

  1. Cliquez sur Démarrer, puis Exécuter, tapez gpedit.mscet cliquez sur OK.
  2. Notez que la boîte de dialogue Stratégie de groupe s’affiche.
  3. Développez Configuration ordinateur, puis développez Paramètres Windows.
  4. Développez Paramètres de sécurité, puis Stratégies locales.
  5. Cliquez sur Affectation des droits de l’utilisateur, puis double-cliquez sur Verrouiller les pages en mémoire.
  6. Dans la boîte de dialogue Paramètres de stratégie de sécurité locale, cliquez sur Ajouter un utilisateur ou Ajouter un groupe.
  7. Dans la boîte de dialogue Sélectionner des utilisateurs ou Sélectionner des groupes, ajoutez le compte qui a l’autorisation d’exécuter le fichier sqlservr.exe, puis cliquez sur OK.
  8. Fermez la boîte de dialogue Stratégie de groupe.
  9. Redémarrez le service SQL Server.

Une fois que vous avez affecté les pages de verrouillage à l’utilisateur en mémoire et que vous redémarrez le service SQL Server, le système d’exploitation Windows ne pages plus la mémoire du pool de mémoires tampons dans le processus SQL Server. Toutefois, le système d’exploitation Windows peut toujours pager la mémoire du pool nonbuffer dans le processus SQL Server.

Vous pouvez vérifier que le droit utilisateur est utilisé par l’instance de SQL Server en vous assurant que le message suivant est écrit dans le journal des erreurs SQL Server au démarrage : « Utilisation de pages verrouillées pour le pool de mémoires tampons »

Ce message s’applique uniquement à SQL Server. Pour plus d’informations sur ce message dans errorLOG, consultez les rubriques suivantes : Dois-je affecter les pages de verrouillage pour le privilège mémoire dans le système local

Quand le système d’exploitation Windows pagine la mémoire du pool hors tampon, vous pourriez toujours rencontrer des problèmes de performances. Toutefois, les messages d’erreur mentionnés dans la section « Explication » ne sont pas enregistrés dans le journal des erreurs SQL Server.

Ce qui entraîne la pagination de la mémoire de SQL Server

Trois grandes catégories de causes peuvent être à l’origine de ce problème :

  • Problèmes liés à l’application : toutes les applications ont épuisé la mémoire physique disponible et le système d’exploitation doit libérer de la mémoire pour les nouvelles demandes d’application pour les ressources. En règle générale, l’approche consiste à rechercher les applications qui épuisent la mémoire et à prendre les mesures nécessaires pour équilibrer la mémoire entre elles sans conduire à l’épuisement de la RAM.
  • Problèmes de pilote de périphérique : les pilotes de périphérique peuvent entraîner la pagination de tous les processus en cas d’appel incorrect d’une fonction d’allocation de mémoire.
  • Problèmes liés au système d’exploitation

Vous trouverez ci-dessous des informations sur chacune de ces catégories

  • Problèmes liés à l’application : les applications peuvent consommer toutes les ram sur le système. Si de nouvelles demandes de mémoire sont effectuées, le système d’exploitation tente de les satisfaire, et s’il n’y a pas de mémoire disponible, il supprime la plage de travail des applications en cours d’exécution pour répondre aux demandes de mémoire. Dans ce cas, vous pouvez observer que la plage de travail de la plupart des applications (voire toutes) chute de manière significative. Pour ce faire, collectez le compteur de l’analyseur de performances suivant pour toutes les applications sur le système :

    • Objet performance : Processus
    • Compteur : Ensemble de travail

    En outre, surveillez le compteur suivant pour mettre en corrélation la quantité de mémoire physique disponible sur le système.

    • Objet performance : Memory
    • Compteur : Mémoire disponible (Mo)

    Le comportement classique que vous pouvez observer à la fois la réduction de la mémoire disponible à un niveau proche de 0 Mo et une chute soudaine des compteurs de la plage de travail pour la plupart des processus (voire tous) sur le système. Si vous observez un tel comportement, vous devrez peut-être prendre des mesures pour réduire l’utilisation de la mémoire sur le système, ce qui comprend, par exemple, la réduction de la mémoire maximale du serveur pour SQL Server.

    Les applications peuvent également trop utiliser le cache du système, ce qui peut entraîner une croissance importante du cache système. Pour répondre à la croissance du cache système, le système met en page l’ensemble de travail du processus SQL Server ou d’autres applications. Si vous rencontrez ce problème, vous pouvez utiliser certaines fonctions de gestion de la mémoire dans l’application. Ces fonctions contrôlent l’espace de la mémoire cache du système que les opérations d’E/S de fichiers peuvent utiliser dans l’application. Par exemple, vous pouvez utiliser la fonction SetSystemFileCacheSize et la fonction GetSystemFileCacheSize pour contrôler l’espace de la mémoire cache du système que les opérations d’E/S de fichier peuvent utiliser.

    Vous pouvez utiliser l’objet de performance mémoire pour afficher les valeurs de différents compteurs dans cet objet afin de déterminer si la plage de travail du cache système utilise trop de mémoire. Par exemple, vous pouvez afficher les compteurs Octets du cache et Octets résidents du cache système. Pour plus d’informations sur cette rubrique, consultez :

    Vous pouvez télécharger et déployer le « Service de cache dynamique Microsoft Windows » pour contrôler la mémoire consommée par le cache système.

  • Problèmes de pilote de périphérique : si un pilote de périphérique utilise la MmAllocateContiguousMemory fonction et s’il définit la valeur du paramètre HighestAcceptableAddress sur moins de 4 gigaoctets (Go), le système d’exploitation Windows peut mettre en page l’ensemble de travail des processus sur le système, y compris le processus SQL Server. Pour résoudre ce problème, contactez le fournisseur du pilote de périphérique pour les mises à jour des pilotes.

    Lorsqu’un pilote de périphérique tente d’allouer de la mémoire, le système d’exploitation Windows peut paginer le jeu de travail d’autres applications. Ce correctif logiciel Windows vous permet d’utiliser le suivi des événements pour rechercher le pilote de périphérique à l’origine du problème. Pour obtenir plus d’informations sur le pilote spécifique qui provoque le comportement de réduction de la plage de travail, consultez Identification des pilotes qui allouent de la mémoire contiguë.

  • Problèmes liés au système d’exploitation : pour résoudre les problèmes connus qui entraînent la page du système d’exploitation Windows sur le jeu de travail du processus SQL Server, appliquez les correctifs logiciels décrits dans les articles de la Base de connaissances Microsoft suivants.

    Remarque

    Les correctifs sont cumulatifs. Une version ultérieure d’un correctif contient les versions antérieures de ce correctif logiciel.

Considérations importantes avant d’attribuer le droit utilisateur « Verrouiller les pages en mémoire »

Vous devez prendre en compte d’autres éléments avant d’attribuer le droit utilisateur Verrouiller les pages en mémoire. Si vous affectez ce droit utilisateur sur des systèmes qui ne sont pas configurés correctement, le système peut devenir instable ou subir une baisse des performances de l’ensemble du système. En outre, l’ID d’événement 333 peut être enregistré dans le journal des événements.

Si vous contactez le service de support technique Microsoft (CSS) pour ces problèmes, les ingénieurs CSS peuvent vous demander de révoquer ce droit d’utilisateur pour le compte d’utilisateur utilisé comme compte de démarrage du service SQL Server. Cette étape peut être nécessaire pour collecter des données de performances importantes que les ingénieurs CSS peuvent utiliser pour la configuration nécessaire des différentes options pour SQL Server et pour d’autres applications qui s’exécutent sur le système. Une fois que les ingénieurs CSS collectent les données de performances, vous pouvez affecter les pages de verrouillage en mémoire directement au compte de démarrage du service SQL Server.

Avant d’attribuer le droit utilisateur Verrouiller les pages en mémoire, assurez-vous de capturer un journal de l’analyseur de performances pour déterminer les besoins en mémoire des divers services et applications installés sur le système. Ces applications incluent également SQL Server. Pour déterminer les besoins en mémoire, collectez les informations de ligne de base suivantes :

  • Veillez à définir l’option max server memory et l’option min server memory correctement. Ces options reflètent uniquement les besoins en mémoire requise du pool de mémoires tampons du processus SQL Server. Ces options n’incluent pas la mémoire allouée pour d’autres composants au sein du processus SQL Server. Ces composants incluent :

    • Threads de travail SQL Server
    • Différentes DLL et composants que le processus SQL Server charge dans l’espace d’adressage du processus SQL Server
    • Les opérations de sauvegarde et de restauration

  • Les DLL et composants incluent différents fournisseurs OLE DB, procédures stockées étendues, objets MICROSOFT COM utilisés pour la procédure stockée sp_OACreate, les serveurs liés et LE CLR SQL Server. La mémoire allouée pour ces composants se trouve sous la région du pool non-buffer de l’espace d’adressage du processus SQL Server. Pour déterminer idéalement la quantité maximale de mémoire que l’ensemble du processus SQL Server peut utiliser, vous devez soustraire la mémoire allouée pour les composants qui n’utilisent pas le pool de mémoires tampons à partir de la mémoire totale que vous souhaitez que le processus SQL Server utilise. Ensuite, vous pouvez utiliser la valeur restante pour définir l’option max server memory. Avant de définir l’option max server memory et l’option min server memory, vous devez examiner attentivement la rubrique « Définition manuelle des options de mémoire » dans la documentation en ligne de SQL Server.

  • Déterminez la mémoire requise par les autres applications et les composants du système d’exploitation Windows. Les applications peuvent inclure d’autres composants SQL Server, par exemple, SQL Server Agent, Réplication SQL Server Agents, SQL Server Reporting Services, SQL Server Analysis Services, SQL Server Integration Services et recherche en texte intégral SQL Server. Les applications qui effectuent des opérations de sauvegarde et des opérations de copie de fichiers peuvent utiliser un grand nombre de mémoires. Envisagez des opérations telles que la copie en bloc et les agents d’instantanés qui génèrent des E/S de fichier. Vous devez prendre en compte les besoins en mémoire de toutes ces applications lorsque vous déterminez la valeur de l’option max server memory et de l’option min server memory. Vous pouvez utiliser le compteur Octets privés et le compteur Jeu de travail sous l’objet Processus pour chaque processus afin de déterminer les besoins en mémoire pour un processus spécifique.

  • Par défaut, le droit utilisateur Verrouiller les pages en mémoire a déjà été affecté au compte système local intégré. Pour plus d’informations, visitez le site web Microsoft suivant : Dois-je affecter les pages de verrouillage en mémoire pour le système local ?

  • Si vous utilisez un compte d’utilisateur Windows globalement pour tous les processus SQL Server dans un domaine, déterminez les droits utilisateur affectés à l’aide d’une configuration de stratégie de groupe. Un processus SQL Server 32 bits peut utiliser ce compte comme compte de démarrage. Toutefois, ce compte requiert le droit utilisateur Verrouiller les pages en mémoire pour activer la fonctionnalité Address Windowing Extensions (AWE). Pour plus d’informations, consultez la rubrique « Fournir la quantité maximale de mémoire à SQL Server » dans la documentation en ligne de SQL Server.

  • Avant de configurer l’option max server memory et l’option min server memory pour plusieurs instances SQL Server, tenez compte des besoins en mémoire du pool non-buffer pour chaque instance de SQL Server. Configurez ensuite ces options pour chaque instance de SQL Server.

Dans l’idéal, vous collectez ces informations de référence pendant les pics de charge. Par conséquent, vous pouvez déterminer les besoins en mémoire pour divers composants et applications afin de pouvoir soutenir la charge maximale. Les besoins en mémoire varient d’un système à un autre, et selon les activités et applications qui s’exécutent sur le système. Vous pouvez interroger les informations fournies dans la vue de gestion dynamique sys.dm_os_process_memory pour savoir si le système rencontre des conditions de mémoire insuffisante. Pour plus d’informations, consultez sys.dm_os_process_memory (Transact-SQL).

Améliorations apportées à Windows Server 2008 et à la version R2

Windows Server 2008 et Windows Server 2008 R2 améliorent le mécanisme d’allocation de mémoire contiguë. Cette amélioration permet à Windows Server 2008 et Windows Server 2008 R2 de réduire dans une certaine mesure les effets de la pagination de la plage de travail des applications lorsque de nouvelles demandes de mémoire arrivent.

Vous trouverez ci-dessous une explication des améliorations apportées, tirées du livre blanc Microsoft « Évolutions de la gestion de la mémoire dans Windows » :

Dans Windows Server 2008, l’allocation de mémoire physiquement contiguë a été grandement améliorée. Les demandes d’allocation de mémoire contiguë sont plus susceptibles d’avoir lieu, car le gestionnaire de mémoire remplace désormais les pages de manière dynamique, généralement sans tronquer la plage de travail ou effectuer d’opérations d’E/S. En outre, de nombreux autres types de pages, comme les piles de noyau et les pages de métadonnées du système de fichiers, sont désormais des candidats pour le remplacement. Par conséquent, une mémoire plus contiguë est généralement disponible à tout moment donné. En outre, le coût d’obtention de ces allocations est sensiblement réduit.

Pour plus d’informations, consultez Problèmes de réduction de plage de travail avec SQL Server.

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.