web-dev-qa-db-fra.com

Inconnu, AppDomain 66 (master.sys [runtime] .65) est marqué pour déchargement en raison de la pression de la mémoire

J'ai remarqué cette erreur de temps en temps dans le journal des erreurs SQL:

spid20s, Unknown, AppDomain 79 (master.sys [runtime] .78) est marqué pour déchargement en raison de la pression de la mémoire.

J'utilise SQL Server 2016, SP1 CU5 (je pousse pour le patch mais l'entreprise est résistante).

Tout ce que j'ai lu indique une pression mémoire non spécifique au CLR. Il existe des suggestions concernant la modification du paramètre MemToLeave dans les paramètres de démarrage. Est-ce toujours le cas pour les nouvelles versions de SQL Server ou existe-t-il d'autres recommandations?

sql-serversql-server-2016sql-clrerror-log
6
Stockburn

L'architecture de la mémoire a été modifiée dans SQL Server 2012, de sorte qu'il n'était plus nécessaire de s'inquiéter du paramètre MemToLeave, en particulier si vous utilisez SQL Server 64 bits. Et, à partir de SQL Server 2016 (que vous utilisez), SQL Server n'est disponible qu'en 64 bits (voir la "Remarque" en haut de la " Quoi de neuf dans le moteur de base de données - SQL Server 2016 = "page). Donc, non, ne vous inquiétez pas pour MemToLeave.

Correct, les erreurs de "pression de mémoire" ne sont pas spécifiques à SQLCLR. Ces erreurs ne vous disent pas la cause de la pression de la mémoire, mais plutôt ce qui est affecté par la pression de la mémoire (dont je doute qu'il existe un moyen possible d'avoir vraiment un aperçu de la cause de toute façon - je veux dire, s'il y a 10 processus prendre de la mémoire, quelle combinaison est vraiment la cause - ce n'est pas nécessairement ce qui prend le plus gros morceau car cela pourrait être entièrement valide). La pression de la mémoire affecte également d'autres zones qui peuvent ne pas apparaître dans le journal des erreurs, telles que le vidage du cache de plan et/ou du pool de tampons (c'est-à-dire les pages de données chargées en mémoire).

Il existe plusieurs fonctionnalités intégrées qui utilisent SQLCLR, une liste partielle étant la suivante:

  • Types de données:
    • HierarchyID
    • La géographie
    • Géométrie
  • Les fonctions:
    • FORMAT
    • PARSE
    • TRY_PARSE
    • AT TIME ZONE (à partir de SQL Server 2016)
    • COMPRESS (mais pas UNCOMPRESS; à partir de SQL Server 2016)
  • Caractéristiques:
    • Modifier la capture de données
    • Cadre de gestion dynamique
    • La réplication
    • Gestion basée sur les politiques
    • Services de données de base
    • SSISDB (la fonction "Recherche floue")

Un ou plusieurs de ceux (ou peut-être celui que je n'ai pas énuméré ci-dessus) est ce qui est affecté dans votre système. Il y a deux indices, à la fois dans le (master.sys[runtime].78) une partie de cette info, qui nous dit ceci:

  1. la base de données étant master (en supposant que vous ne chargez jamais, jamais d'assemblys personnalisés dans master ;-))

  2. le "propriétaire" (c'est-à-dire AUTHORIZATION) de l'assembly étant sys (nous ne pouvons pas attribuer la propriété des assemblys à sys ou INFORMATION_SCHEMA car aucun de ces principaux n'a un SID). Si vous souhaitez voir le propriétaire de chaque assembly, procédez comme suit:

    SELECT asm.[name] AS [Assembly],
       USER_NAME(asm.[principal_id]) AS [Owner],
       USER_SID(asm.[principal_id]) AS [OwnerSID]
FROM   sys.assemblies asm;

Ce que vous pouvez faire, c'est:

  1. Vous mentionnez que cette erreur apparaît "occasionnellement", mais vous n'avez pas exactement défini la fréquence à laquelle cela se produit. Une fois par heure est différente d'une fois par jour, ce qui est différent d'une fois par semaine. La pression de la mémoire se produit, donc à moins que ce ne soit plus de quelques fois par jour, je ne passerais pas trop de temps à m'en inquiéter.
  2. Ajoutez plus de mémoire (physiquement et/ou autorisez SQL Server à utiliser plus de mémoire système si vous avez actuellement SQL Server contraint à une quantité moindre)
  3. Analysez ce qui consomme de la mémoire en dehors de SQL Server pour voir s'il y a des processus inutiles sur le serveur qui peuvent être déchargés sur d'autres serveurs, ou peut-être complètement arrêtés (c'est-à-dire que d'autres services sont utilisés et/ou des sessions de bureau à distance qui sont puis en exécutant SSMS, etc. qui utilisent beaucoup de mémoire?)
10
Solomon Rutzky

Pourrait examiner cela: https://docs.Microsoft.com/en-us/sql/relational-databases/memory-management-architecture-guide . Surtout la requête sur ce qui est actuellement alloué. Il vous donnera un endroit où concentrer les diagnostics.

J'ai déjà eu ce problème auparavant, et il a fini par être des appels répétés à une procédure CLR qui ne se fermerait jamais une fois terminé.

7
Adam K.