Partager via

  • Article

Résolution des problèmes du gouverneur de ressources

Cette rubrique fournit de l'aide pour la résolution des problèmes qui peuvent se produire lors de l'utilisation du gouverneur de ressources. Cette aide s'articule autour des catégories suivantes :

  • Erreurs

  • Résultats inattendus

  • Problèmes et erreurs liés aux performances

Erreurs du gouverneur de ressources

Les messages d'erreur du gouverneur de ressources couvrent toutes les actions en rapport avec la configuration et l'utilisation du gouverneur de ressources.

Le tableau suivant fournit des exemples de messages d'erreur du gouverneur de ressources et fournit de l'aide sur la façon de résoudre le problème décrit dans le message d'erreur.

Numéro d'erreur

Message d'erreur

Résolution

8645

Le délai a été dépassé en attendant que les ressources mémoire exécutent la requête dans le pool de ressources 'myTestPool' (257). Réexécutez la requête.

Remplacez la valeur du délai d'attente par une valeur plus élevée ou réduisez la charge de la requête sur le serveur.

8651

Impossible d'exécuter l'opération, car l'allocation de mémoire demandée n'était pas disponible dans le pool de ressources 'myTestPool' (257). Exécutez à nouveau la requête, réduisez sa charge ou vérifiez le paramètre de configuration du gouverneur de ressources.

Réexécutez la requête ultérieurement. Diminuez la charge de la requête sur le serveur. Demandez à l'administrateur de vérifier le paramètre de configuration du gouverneur de ressources.

8657

Impossible d'obtenir l'allocation de mémoire de 1 024 Ko parce qu'elle dépasse la limite de configuration maximale dans le groupe de charge de travail 'myTestGroup' (267) et le pool de ressources 'myTestPool' (257). Contactez l'administrateur du serveur pour augmenter la limite d'utilisation de la mémoire.

Réécrivez la requête pour réduire la consommation de mémoire d'opérations telles que le tri et la jointure de hachage. Demandez à l'administrateur système d'autoriser une limite d'utilisation de la mémoire plus élevée.

Un administrateur peut définir un des paramètres suivants, ou les deux :

  • max_memory_percent sur les pools de ressources, qui définit l'espace d'allocation de la mémoire physique maximal pour toutes les requêtes.

  • request_max_memory_grant_percent sur les groupes de charges de travail, qui définit la limite par requête.

Un administrateur peut obtenir la limite physique réelle à partir de la colonne max_target_memory_kb de sys.dm_exec_query_resource_semaphores.

La limite par requête peut être calculée par max_target_memory_kb * request_max_memory_grant_percent.

RemarqueRemarque
L'administrateur doit s'assurer que la mémoire requise déclarée dans le message d'erreur est inférieure à la limite par requête calculée ci-dessus. Toutefois, il est à noter que l'augmentation de request_max_memory_grant_percent a un effet secondaire sur la réduction de la concurrence des grandes requêtes. Par exemple, les utilisateurs peuvent s'attendre à exécuter trois grandes requêtes avec le paramètre par défaut 25 pour cent, mais uniquement deux grandes requêtes avec un paramètre 40 pour cent.

10900

Impossible de configurer le gouverneur de ressources lors du démarrage. Recherchez des messages d'erreur spécifiques dans le journal des erreurs SQL Server ou vérifiez la cohérence de la base de données master en exécutant DBCC CHECKCATALOG('master').

Essayez d'exécuter « DBCC CHECKCATALOG('master') ».

10901

L'utilisateur n'a pas l'autorisation de modifier la configuration du gouverneur de ressources.

Accordez l'autorisation qui permettrait la modification de la configuration du gouverneur de ressources et recommencez.

10902

La fonction définie par l'utilisateur 'dbo.rgclassifier_v1' n'existe pas dans la base de données MASTER, ou l'utilisateur n'a pas l'autorisation d'y accéder.

Créez une fonction définie par l'utilisateur (UDF) classifieur dans master ou accordez les autorisations requises sur la fonction définie par l'utilisateur classifieur existante.

10903

Le nom de schéma spécifié 'dbo' pour la fonction définie par l'utilisateur classifieur n'existe pas, ou l'utilisateur n'a pas l'autorisation de l'utiliser.

Essayez un autre nom de schéma ou obtenez les autorisations correctes pour ce schéma.

10904

Échec de la configuration du gouverneur de ressources. Des sessions sont actives dans les groupes de charges de travail supprimés ou déplacés vers d'autres pools de ressources. Déconnectez toutes les sessions actives dans les groupes de charges de travail concernés et réessayez.

Déconnectez toutes les sessions actives dans le ou les groupes affectés et réessayez.

RemarqueRemarque
Cette version du gouverneur de ressources n'autorise pas le déplacement de groupes entre des pools lorsque des sessions y sont ouvertes.

10905

Impossible de terminer la configuration du gouverneur de ressources, car la mémoire est insuffisante. Réduisez la charge du serveur ou tentez l'opération sur une connexion administrateur dédiée.

Réduisez la charge sur le serveur ou essayez une opération de configuration sur une connexion administrateur dédiée (DAC).

10906

L'objet 'dbo'.'rgclassifier_v1' n'est pas une fonction définie par l'utilisateur classifieur de gouverneur de ressources valide. Une fonction définie par l'utilisateur classifieur valide doit être liée au schéma, retourner sysname et n'avoir aucun paramètre.

Fournissez une fonction définie par l'utilisateur (UDF) classifieur valide. Une fonction définie par l'utilisateur classifieur valide doit :

  • retourner sysname ;

  • n'avoir aucun paramètre ;

  • être créée avec l'option SCHEMABINDING.

10907

L'attribut 'MIN_CPU_PERCENT' avec la valeur 50 est supérieur à l'attribut 'MAX_CPU_PERCENT' avec la valeur 40.

Fournissez une valeur minimale inférieure ou égale à la valeur maximale.

10908

L'attribut 'MAX_MEMORY_PERCENT' avec une valeur 40 est inférieur à l'attribut 'MIN_MEMORY_PERCENT' avec une valeur 60.

Fournissez une valeur maximale supérieure ou égale à la valeur minimale de l'attribut.

10909

Impossible de créer le pool de ressources. Le nombre maximal de pools de ressources ne peut pas dépasser la limite actuelle de 20, pools de ressources prédéfinis compris.

Supprimez les pools de ressources qui ne sont pas nécessaires.

10910

L'opération n'a pas pu être accomplie. La valeur 'MIN_CPU_PERCENT' spécifiée, 25, a pour conséquence que la somme des valeurs minimales de tous les pools de ressources dépasse 100 pour cent. Diminuez cette valeur ou modifiez d'autres pools de ressources afin que la somme soit inférieure à 100.

Réduisez la valeur pour MIN_CPU_PERCENT.

10911

Impossible d'effectuer l'opération demandée, car le pool de ressources 'myTestPool2' n'existe pas.

Interrogez l'affichage catalogue sys.resource_governor_resource_pools pour déterminer les pools de ressources qui sont actuellement définis. Choisissez un pool existant ou créez un nouveau pool.

10912

L'opération n'a pas pu être terminée. La suppression du groupe de charge de travail prédéfini n'est pas autorisée.

Choisissez un groupe de charge de travail créé par l'utilisateur à supprimer.

10913

Les utilisateurs ne sont pas autorisés à supprimer le groupe de charge de travail 'internal' dans le pool de ressources 'internal'.

Créez le groupe de charge de travail dans un pool créé par l'utilisateur ou le pool par défaut.

10914

Le nom du groupe de charge de travail '#mygroup' ne peut pas commencer par # sur ##.

N'utilisez pas # ou ## lors de la création d'un groupe ou pool.

10915

L'opération n'a pas pu être accomplie. La modification du groupe de charge de travail 'internal' n'est pas autorisée.

Choisissez un groupe ou un pool créé par l'utilisateur à modifier.

Remarque   La modification de la configuration du groupe ou pool de ressources par défaut est autorisée.

10916

Impossible de supprimer le pool de ressources 'myTestPool', car il contient le groupe de charge de travail 'myTestGroup'. Supprimez tous les groupes de charges de travail qui utilisent ce pool de ressources avant de supprimer celui-ci.

Supprimez ou déplacez tous les groupes de charges de travail qui utilisent ce pool, puis supprimez le pool.

10917

ALTER WORKLOAD GROUP a échoué. Une clause 'WITH' ou 'USING' doit être spécifiée.

Utilisez la clause 'WITH' ou 'USING' dans l'instruction ALTER WORKLOAD GROUP.

10918

Impossible de créer le pool de ressources 'myTestPool' car il existe déjà.

Choisissez un autre nom de pool de ressources.

10919

Une erreur s'est produite lors de la lecture de la configuration du gouverneur de ressources à partir de la base de données master. Vérifiez l'intégrité de la base de données master ou contactez l'administrateur système.

Essayez d'exécuter « DBCC CHECKCATALOG('master') ».

10920

Impossible de supprimer la fonction définie par l'utilisateur 'dbo.myclassifer'. Elle est utilisée en tant que classifieur du gouverneur de ressources.

Aucun.

10921

Le groupe de charge de travail 'default' ne peut pas être déplacé hors du pool de ressources 'default'.

Non applicable.

10981

La reconfiguration du gouverneur de ressources a réussi.

Ce message est écrit dans le journal des événements SQL Server.

10982

Impossible d'exécuter la fonction définie par l'utilisateur classifieur du gouverneur de ressources. Pour plus d'informations, examinez les erreurs précédentes dans le journal des erreurs SQL Server à partir de l'ID de session 58. Temps écoulé de la fonction classifieur : 800 ms.

Ce message est écrit dans le journal des erreurs SQL Server.

Remarque   Les messages antérieurs dans le journal des erreurs SQL Server ayant le même identificateur de processus serveur (SPID) peuvent fournir des raisons de défaillance spécifiques. Une fonction classifieur de longue durée peut provoquer une expiration du délai d'attente de la connexion de l'utilisateur. Vérifiez si le temps écoulé de la fonction classifieur dépasse le délai d'attente de la connexion du client.

10983

La reconfiguration du gouverneur de ressources a été annulée par l'utilisateur.

Non applicable.

10984

Échec de la reconfiguration du gouverneur de ressources.

Non applicable.

Résultats inattendus

Les résultats inattendus décrivent des situations où plusieurs éléments du gouverneur de ressources fonctionnent, mais les résultats ne sont pas ceux que vous attendez. Par exemple, la classification de session ne semble pas fonctionner correctement, ou il y a des problèmes liés à la suppression ou à la création de groupes de charges de travail.

Classification de session

Les sessions iront au groupe de charge de travail par défaut si les conditions suivantes sont réunies :

  • la fonction définie par l'utilisateur de classifieur n'existe pas ou n'est pas activée ;

  • la fonction définie par l'utilisateur de classifieur les a mis là, ce qui dénote un défaut dans la logique de la fonction.

Dépannage de base

Si aucune fonction définie par l'utilisateur (UDF) classifieur n'est disponible pour la classification, toutes les sessions iront alors automatiquement au groupe de charge de travail par défaut. Après avoir créé une fonction définie par l'utilisateur classifieur, vous devez vérifier qu'elle est inscrite auprès du gouverneur de ressources et que la configuration en mémoire est mise à jour.

La création, l'inscription et l'activation d'une fonction définie par l'utilisateur (UDF) classifieur est un processus en trois étapes :

  • Premièrement, vous devez créer la fonction.

    CREATE FUNCTION function_name() RETURNS <something> 
WITH SCHEMABINDING

  • Deuxièmement, vous devez inscrire la fonction auprès du gouverneur de ressources.

    ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION=schema_name.function_name)

  • Troisièmement, vous devez mettre à jour la configuration en mémoire du gouverneur de ressources.

    ALTER RESOURCE GOVERNOR RECONFIGURE

La première chose que vous devez faire lors du dépannage de la classification est de vérifier que la fonction que vous avez créée est inscrite auprès du gouverneur de ressources et que la configuration a été mise à jour. Utilisez la requête suivante pour obtenir le nom du schéma (schema_name) et le nom de la fonction classifieur (function_name) pour la fonction définie par l'utilisateur classifieur que le gouverneur de ressources utilise actuellement.

USE master
SELECT 
      object_schema_name(classifier_function_id) AS [schema_name],
      object_name(classifier_function_id) AS [function_name]
FROM sys.dm_resource_governor_configuration

Vous pouvez utiliser l'approche précédente pour dépanner un scénario dans lequel vous avez modifié la fonction définie par l'utilisateur classifieur mais où le gouverneur de ressources utilise encore la logique de la fonction précédente pour classifier des sessions. Ce comportement indique que les modifications que vous avez apportées n'ont pas été appliquées à la configuration en mémoire.

Dépannage avancé

Vous pouvez créer une fonction classifieur très complexe qui ne produit pas les résultats attendus ou qui consomme beaucoup de ressources. Si vous avez procédé à la résolution des problèmes de base, vous devez vérifier que la logique de la fonction est saine. Le scénario le plus pessimiste est celui dans lequel un défaut de codage génère une boucle infinie ou une perte de contrôle de requête.

Vous pouvez utiliser une connexion administrateur dédiée (DAC) pour corriger une fonction classifieur mal écrite, car une DAC n'est pas sujette à la classification et peut être utilisée alors que le gouverneur de ressources est en cours d'exécution et de classification des sessions entrantes. Pour plus d'informations, consultez Utilisation d'une connexion d'administrateur dédiée.

[!REMARQUE]

Si aucune DAC n'est disponible pour résoudre le problème, vous pouvez redémarrer le système en mode mono-utilisateur. Bien que ce mode ne soit pas sujet à la classification, vous ne pouvez pas diagnostiquer la classification du gouverneur de ressources pendant son exécution.

Vous pouvez obtenir des informations sur la fonction classifieur en interrogeant les éléments suivants :

  • sys.dm_exec_query_stats. (contient des informations d'instructions, mais pas la fonction elle-même).

  • sys.dm_exec_sql_text (utilisé en combinaison avec le sql_handle obtenu de sys.dm_exec_query_stats)

  • Classe d'événements PreConnect:Starting (fournit l'ID et le nom de la fonction classifieur)

Échec de la reconfiguration

Le gouverneur de ressources conserve les modifications de métadonnées séparées des sessions actives jusqu'à ce que l'instruction ALTER RESOURCE GOVERNOR RECONFIGURE soit exécutée. ALTER RESOURCE GOVERNOR RECONFIGURE échouera si vous essayez de supprimer un groupe qui contient des sessions actives ou ouvertes, ou si vous essayez de supprimer un pool de ressources qui contient des groupes de charges de travail.

Pour obtenir la configuration en mémoire et stockée, interrogez sys.dm_resource_governor_configuration et sys.resource_governor_configuration respectivement. La valeur 1 pour is_reconfiguration_pending (sys.dm_resource_governor_configuration) indique que la configuration de session n'a pas été mise à jour. Dans ce cas, vos options sont les suivantes :

  • Attendez que les sessions se terminent ou supprimez leur connexion.

  • Arrêtez explicitement la session active ou supprimez la connexion de la session.

  • Recréez le groupe ou le pool que vous avez supprimé, réglez ses paramètres et réexécutez ALTER RESOURCE GOVERNOR RECONFIGURE.

Problèmes et erreurs liés aux performances

Si des problèmes liés aux performances semblent se poser lorsque vous utilisez le gouverneur de ressources, vous devez déterminer si le problème est provoqué par la configuration du gouverneur de ressources. L'aide à la résolution de problèmes fournie dans cette section est groupée dans deux catégories :

  • Classification de session

  • Exécution de la requête

Classification de session

Un déclencheur de connexion ou une fonction définie par l'utilisateur (UDF) classifieur de longue durée peut avoir un impact sur les performances du serveur. Si le déclencheur de connexion ou la fonction définie par l'utilisateur classifieur demande beaucoup de temps, la connexion expire. Toutefois, le déclencheur ou la fonction continue de s'exécuter et d'utiliser les ressources du serveur.

Si vous pensez que des sessions s'exécutent dans un état préconnecté, ouvrez une session en utilisant la connexion d'administrateur dédiée et vérifiez la Classe d'événements PreConnect:Starting pour déterminer si plusieurs demandes ou sessions ont démarré, mais ne se sont pas terminées.

Pour résoudre ce problème et éviter qu'il ne se reproduise :

  • arrêtez les sessions ;

  • identifiez les causes probables de la longue exécution de la fonction ou du déclencheur de connexion ;

  • supprimez et remplacez le déclencheur ou la fonction à l'origine du problème.

Exécution de la requête

Après avoir été classée et exécutée, il peut sembler qu'une requête cesse de répondre (blocage) ou échoue. Vous suspectez que les paramètres actuels du gouverneur de ressources en sont peut-être la cause. Vous devez étudier les aspects suivants de votre configuration du gouverneur de ressources :

  • Limitation du nombre de demandes

  • Limite maximale de l'UC

  • Limitation de la bande passante de l'UC

  • Taille de l'allocation de mémoire

  • Erreur de délai d'expiration de l'allocation de mémoire

  • Erreur de mémoire insuffisante

  • Plan de requête non optimal

Limitation du nombre de requêtes

Dans ce scénario, un utilisateur signale une dégradation des performances et vous suspectez que le nombre de requêtes est limité.

La première chose à faire est de vérifier si la limitation du nombre de requêtes est explicitement définie pour le groupe auquel appartient l'utilisateur. Pour cela, vérifiez l'appartenance de l'utilisateur au groupe afin de déterminer si le paramètre GROUP_MAX_REQUESTS est activé. Si GROUP_MAX_REQUESTS n'est pas activé, il n'existe aucune limitation explicite du nombre de requêtes. Vous devez pousser plus loin vos investigations en exécutant les étapes suivantes.

  • Interrogez sys.dm_os_waiting_tasks pour voir si toutes les demandes se conforment au temps d'attente RESMGR_THROTTLED. La présence de ce type d'attente indique la limitation du nombre de demandes.

  • Démarrez l'analyseur de performances et recueillez des données à l'aide des Requêtes en attente et des compteurs de requêtes actives. Un nombre de requêtes en attente autre que zéro indique une limitation de requêtes.

  • Vérifiez si la valeur de requêtes actives correspond au paramètre GROUP_MAX_REQUESTS. Si la valeur de requêtes actives est plus élevée que le paramètre GROUP_MAX_REQUESTS, le groupe peut avoir des requêtes qui ne peuvent pas être limitées (par exemple, des transactions ouvertes).

  • Si les requêtes en attente ont une valeur égale à zéro, vérifiez les requêtes actives de tous les groupes de charges de travail qui partagent le même pool de ressources parce que le pool a pu être surchargé avec trop de requêtes.

Limite maximale de l'UC

Si vous avez une stratégie qui repose sur la génération d'événement du gouverneur de ressources, vous pouvez utiliser l'événement généré lorsque la limite maximale de l'UC est atteinte.

Dans ce scénario, vous souhaitez déterminer si la limite maximale de l'UC (REQUEST_MAX_CPU_TIME_SEC) que vous avez configurée pour détecter une requête qui utilise trop de ressources processeur est trop basse.

Les actions suivantes vous aideront à valider le paramètre de limite de l'UC.

  • Démarrez une session SQL Trace et collectez l'événement CPU Threshold Exceeded. Lorsqu'une requête utilisateur atteint la limite d'utilisation maximale de l'UC, le serveur génère automatiquement un événement SQL Trace. Si votre paramètre est trop bas, un nombre élevé de ces événements sera généré.

[!REMARQUE]

Cet événement est également exposé en tant que notification d'événements serveur pour que vous puissiez écrire un script qui réagit à l'événement.

  • Démarrez l'analyseur de performances et collectez des données à l'aide du compteur Temps proc. max. par requête (ms). Vous pouvez utiliser la valeur de ce compteur comme indicateur afin de définir la limite appropriée pour le groupe de charge de travail.

Limitation de la bande passante de l'UC

Dans ce scénario, vous suspectez que la bande passante de l'UC est limitée parce que le compteur de performance % d'utilisation de l'UC se situe au niveau du paramètre MAX_CPU_PERCENT du gouverneur de ressources, ou tout près de celui-ci. La requête suivante retourne la valeur de % d'utilisation de l'UC pour tous les groupes de charges de travail et les pools de ressources pour une instance SQL Server.

select * from sys.dm_os_performance_counters where counter_name = 'cpu usage %'

Pour plus d'informations, consultez sys.dm_os_performance_counters (Transact-SQL).

Vous pouvez déterminer si la bande passante de l'UC est limitée en effectuant les contrôles suivants sur votre système.

  • Vérifiez l'utilisation totale de l'UC du serveur. Si une charge autre que SQL Server est actuellement active, elle peut affecter la requête que vous dépannez.

  • Vérifiez la distribution d'utilisation de l'UC entre les pools de ressources. Un pool de ressources pourrait être limité parce qu'un autre pool a une valeur minimale haute configurée pour l'utilisation de l'UC. Comparez les compteurs pour l'utilisation de l'unité centrale calculée attendue par rapport à l'utilisation réelle de l'UC.

  • Vérifiez les groupes de charges de travail affectés au pool de ressources en question. Le fait de charger d'autres groupes de charges de travail peut affecter les utilisateurs qui partagent le même pool.

  • Vérifiez la distribution d'utilisation de l'UC entre les planificateurs. La requête sur laquelle vous enquêtez peut être placée sur un planificateur qui contient des requêtes longues. Dans ce cas, la requête peut sembler être limitée, mais le problème réel provient d'une distribution inégale de la charge entre les planificateurs.

  • Vérifiez les cas possibles où la charge de travail peut être bloquée par d'autres sessions au lieu d'être limitée par les paramètres du gouverneur de ressources.

  • Vérifiez le nombre de sessions actuellement en cours d'exécution sur le système. À mesure que le nombre de requêtes en cours d'exécution simultanées augmente, SQL Server essaie de s'assurer que toutes reçoivent au moins une certaine quantité de temps processeur pour empêcher toute privation en termes de ressources UC.

Taille de l'allocation de mémoire

Dans ce scénario, vous suspectez que la taille de l'allocation de mémoire est à l'origine d'une exécution au ralenti d'une requête.

Le gouverneur de ressources applique la limite de mémoire de requête maximale en réduisant l'allocation de mémoire afin que les requêtes volumineuses puissent tenir dans la limite. Si une requête obtient moins de 100 % de l'allocation de mémoire, il peut être nécessaire de vider les données temporaires et de les écrire sur disque, opération qui peut avoir un effet notable sur les performances.

Vous devez déterminer le pourcentage de requêtes volumineuses afin de définir la limite de taille de requête maximale appropriée. Les actions suivantes vous aideront à déterminer les meilleurs paramètres :

  • Interrogez sys.dm_exec_query_memory_grants pour connaître l'état actuel des allocations de mémoire. La colonne ideal_memory_kb affiche la quantité idéale selon l'estimation de la cardinalité. La colonne requested_memory_kb affiche la quantité de la demande qui aurait pu être réduite après avoir atteint la limite de requête maximale. Si requested_memory_kb est sensiblement inférieur à ideal_memory_kb, la requête peut alors finir par se répandre fréquemment (à supposer que l'évaluation de la cardinalité soit correcte).

  • Démarrez l'analyseur de performances et collectez des données à l'aide du compteur Nombre de requêtes à mémoire réduite/s. La valeur de ce compteur représente le taux du nombre d'allocations de mémoire qui ont reçu moins que la quantité idéale après avoir atteint la limite de taille maximale de la requête. Les grandes requêtes peuvent s'exécuter beaucoup plus lentement que celles qui disposent de la quantité idéale parce qu'elles ont besoin de déborder sur le disque pour rester dans les limites de la mémoire.

Pour atténuer un problème d'allocation de mémoire, vous devrez peut-être augmenter la limite de taille de pool ou la taille limite de la mémoire maximale.

[!REMARQUE]

Si vous augmentez seulement la taille de mémoire maximale, cela peut aboutir à une concurrence réduite entre les requêtes volumineuses.

Erreur de délai d'expiration de l'allocation de mémoire

Dans ce scénario, une requête échoue avec une erreur de délai d'attente de l'allocation de mémoire.

Le nombre total de demandes d'allocations de mémoire actives et les limites de mémoire spécifiées dans les définitions du pool de ressources et du groupe de charge de travail peuvent jouer un rôle dans les délais d'expiration d'allocation de mémoire. Si un pool de ressources unique est partagé par plusieurs groupes de ressources, le nombre de requêtes simultanées dans d'autres groupes peut également affecter les délais d'expiration de l'allocation de mémoire.

Les actions suivantes vous aideront à déterminer les meilleurs paramètres du pool de ressources :

  • Interrogez sys.dm_exec_query_memory_grants pour connaître le nombre d'allocations de mémoire et de requêtes en attente sur ce groupe et ce pool.

  • Interrogez sys.dm_exec_query_resource_semaphores pour connaître le total de mémoire allouée et de cibles.

Si l'utilisation de la mémoire allouée est supérieure à l'espace de mémoire disponible, vous pouvez envisager d'augmenter la taille limite du pool de ressources.

Erreurs de mémoire insuffisante

Une requête échoue avec une erreur de mémoire insuffisante.

Dépannage de base

Les actions suivantes vous aideront à déterminer les meilleurs paramètres de groupe de charge de travail :

  • Interrogez sys.dm_os_memory_brokers pour vérifier la distribution de mémoire relative et la tendance à l'intérieur du pool de ressources. Un trop grand nombre de demandes dans un trop petit un espace mémoire peut conduire à un groupe de charge de travail/pool de ressources surchargé et générer des erreurs de mémoire insuffisante.

  • Démarrez l'analyseur de performances et collectez des données à l'aide des compteurs du pool de ressources lié à la mémoire afin d'obtenir l'utilisation de la mémoire cible et actuelle pour les allocations de mémoire, la mémoire en cache et la mémoire de compilation/de l'optimiseur. Si les valeurs actuelles sont supérieures aux valeurs cibles, cela signifie que le pool de ressources est surchargé. Pensez à modifier les limites de mémoire du pool.

  • Démarrez l'analyseur de performances et collectez des données à l'aide du compteur Quantité max. de mémoire par requête. Si la valeur de compteur dépasse la valeur déterminée par le paramètre REQUEST_MAX_MEMORY_GRANT_PERCENT dans le groupe de charge de travail, la requête échouera très probablement. Pensez à modifier la limite de groupe de charge de travail.

Dépannage avancé

L'erreur de mémoire insuffisante (701) est une erreur générique qui est retournée lorsque des tâches essaient d'allouer un bloc de mémoire à partir du gestionnaire de mémoire et que la tentative échoue. Pour plus d'informations, consultez MSSQLSERVER_701.

Les conditions ci-dessous peuvent générer cette erreur :

  • Le pool de mémoires atteint sa limite totale.

[!REMARQUE]

Le gouverneur de ressources ne peut pas être la seule cause de cette situation. Il peut y avoir d'autres applications qui s'exécutent sur le serveur et dont les demandes de mémoire contribuent à cette erreur.

  • L'allocation d'espace d'adressage virtuel ou multipage échoue parce que l'espace d'adressage virtuel n'a pas de bloc libre assez grand pour la réservation requise. Cette situation risque de se produire sur une architecture 32 bits et est improbable sur une architecture 64 bits.

  • L'allocation d'espace d'adressage virtuel ou multipage échoue parce que l'engagement total atteint la limite de validation. Cela s'applique aux architectures 32 et 64 bits.

Lorsque vous constatez l'erreur de mémoire insuffisante, le journal des erreurs est le meilleur point de départ pour examiner l'erreur. Le journal contient un résultat analogue à celui de l'exemple suivant :

2006-01-28 04:27:15.43 spid51 Échec d'allocation de pages : FAIL_PAGE_ALLOCATION 1

Les défaillances possibles enregistrées dans le journal des erreurs sont :

  • FAIL_PAGE_ALLOCATION, suivi du nombre de pages dont l'allocation a été tentée

  • FAIL_VIRTUAL_RESERVE, suivi du nombre d'octets dont la réservation a été tentée

  • FAIL_VIRTUAL_COMMIT, suivi du nombre d'octets dont la validation a été tentée

Il est important de comprendre que la tâche qui a déclenché l'erreur de mémoire insuffisante n'est pas souvent la tâche qui génère l'erreur. À moins qu'il y ait une perte de contrôle de tâche, l'erreur de mémoire insuffisante est en général le point culminant de plusieurs tâches en cours d'exécution. En conséquence, votre analyse doit prendre une vue plus générale de l'activité du système en utilisant le cas très commun d'une erreur FAIL_PAGE_ALLOCATION.

Les informations précieuses suivantes dans le journal des erreurs est la sortie de l'état de la mémoire. Selon la défaillance, vous devez rechercher la page unique, les pages multiples, les réservations virtuelles ou les nombres validés des différents Clerks de mémoire. L'identification des plus grands consommateurs de mémoire est une étape clé pour continuer à étudier l'erreur. En général, les plus grands consommateurs de mémoire sont les types suivants :

  • MEMORYCLERK_ * signifie que la configuration du serveur ou de la charge de travail requiert une allocation de mémoire spécifique. Il existe des Clerks de mémoire correspondants pour les composants SQL Server, et les composants individuels peuvent avoir plusieurs Clerks de mémoire. Pour plus d'informations, consultez sys.dm_os_memory_clerks (Transact-SQL). Vous pouvez parfois identifier la charge de travail qui provoque le problème des Clerks de mémoire, mais il est plus probable que vous devrez examiner les objets de mémoire associés aux Clerks pour trouver ce qui a provoqué la consommation de la grande quantité de mémoire.

  • CACHESTORE_*, USERSTORE_*, OBJECTSTORE_* sont les types de caches. La consommation de mémoire élevée par un cache peut signifier ceci :

    • La mémoire est allouée hors du cache mais n'est pas encore insérée en tant qu'entrée qui peut être supprimée. Ceci est très semblable au cas MEMORYCLERK ci-dessus.

    • Toutes les entrées du cache sont en cours d'utilisation et elles ne peuvent pas être supprimées. Cela peut être confirmé en consultant sys.dm_os_memory_cache_counters et en comparant les valeurs des colonnes entries_count et entries_in_use_count.

  • MEMORYCLERK_SQLQERESERVATIONS indique la quantité de mémoire qui a été réservée par l'exécution de la requête (QE) pour exécuter des requêtes avec des tris/jointures. Une erreur de mémoire insuffisante qui se produit lorsque les réservations sont élevées indique habituellement un bogue dans le serveur.

La sortie de l'état de la mémoire dans le journal des erreurs affichera également le pool de mémoires qui est épuisé. Les gestionnaires d'allocation mémoire pour chaque pool indiquent la distribution de mémoire entre mémoire volée (compilation), mémoire mise en cache et mémoire réservée (allouée). Les nombres pour les trois gestionnaires correspondent aux objets de mémoire précédents associés aux Clerks de mémoire. Vous pouvez déterminer la quantité de mémoire allouée pour un pool à partir d'un Clerk ou d'un objet de mémoire donné en extrayant les informations d'un vidage complet à l'aide d'un script personnalisé et de la vue de gestion dynamique sys.dm_os_memory_cache_entries, qui affiche le pool_id associé à chaque entrée.

Si vous devez contacter les services de support technique, collectez les informations suivantes pour notre équipe d'assistance :

  • Le journal des erreurs indique l'erreur de mémoire insuffisante et la sortie de l'état de la mémoire au moment de l'erreur.

  • La sortie à partir des instructions ci-dessous :

    dbcc memorystatus
dbcc sqlperf(spinlockstats)
select * from sys.dm_os_memory_clerks
select * from sys.dm_os_wait_stats order by wait_type
select * from sys.dm_os_waiting_tasks
select * from sys.dm_os_ring_buffers where ring_buffer_type='RING_BUFFER_OOM'
select * from sys.dm_os_ring_buffers where ring_buffer_type='RING_BUFFER_RESOURCE_MONITOR'
select * from sys.dm_os_ring_buffers where ring_buffer_type='RING_BUFFER_MEMORY_BROKER'
select * from sys.dm_os_memory_cache_clock_hands

  • Facultativement, un vidage de mémoire insuffisante recueilli avec T8004. Ce mini-vidage offrira des informations précieuses telles que les statistiques relatives aux mémoires tampons en anneau et les verrouillages spinlock/attente. Le compteur de vidage pour T8004 peut être réinitialisé sans redémarrer le serveur en désactivant, puis en réactivant T8004.

Plan de requête non optimal

Dans ce scénario, vous suspectez qu'une requête s'exécute lentement à cause d'un plan de requête non optimal. L'optimiseur de requête peut générer un plan de requête non optimal planifie s'il ne reçoit pas assez de mémoire à cause d'un paramètre de limite basse de la mémoire pour un pool de ressources.

Les actions suivantes vous aideront à déterminer les meilleurs paramètres du pool de ressources :

  • Obtenez des données du compteur Optimisations de requêtes/s afin de déterminer si le groupe de charge de travail a un nombre élevé de compilations de requêtes.

  • Obtenez des données du compteur Plans non optimaux/s afin de déterminer si l'optimiseur de requête génère fréquemment des plans non optimaux.

Si l'une ou l'autre des conditions précédentes existe, pensez à augmenter la limite de mémoire du pool de ressources.