it-swarm.com.de

Unbekannt, AppDomain 66 (master.sys [Laufzeit] .65) ist aufgrund des Speicherdrucks zum Entladen markiert

Ich habe diesen Fehler gelegentlich im SQL-Fehlerprotokoll bemerkt:

spid20s, Unknown, AppDomain 79 (master.sys [Laufzeit] .78) ist aufgrund des Speicherdrucks zum Entladen markiert.

Ich verwende SQL Server 2016, SP1 CU5 (ich dränge auf Patches, aber das Unternehmen ist resistent).

Alles, was ich gelesen habe, deutet auf einen nicht CLR-spezifischen Speicherdruck hin. Es gibt Vorschläge zum Ändern der Einstellung MemToLeave in den Startparametern. Ist dies bei neueren Versionen von SQL Server immer noch der Fall oder gibt es andere Empfehlungen?

6
Stockburn

Die Speicherarchitektur wurde in SQL Server 2012 so geändert, dass Sie sich keine Gedanken mehr über die Einstellung MemToLeave machen müssen, insbesondere bei Verwendung von 64-Bit-SQL Server. Ab SQL Server 2016 (das Sie verwenden) ist SQL Server nur in 64-Bit verfügbar (siehe "Hinweis" oben in " Was ist neu in Database Engine - SQL Server 2016 = "Seite). Also, nein, mach dir keine Sorgen um MemToLeave.

Richtig, "Memory Pressure" -Fehler sind nicht spezifisch für SQLCLR. Diese Fehler sagen Ihnen nicht die Ursache des Speicherdrucks, sondern was durch den Speicherdruck beeinflusst wird (was ich bezweifle, dass es eine Möglichkeit gibt, wirklich einen Einblick in die Ursache von sowieso zu bekommen - ich meine, wenn es 10 Prozesse gibt Speicher aufnehmen, welche Kombination ist wirklich die Ursache? Es ist nicht unbedingt das, was den größten Teil aufnimmt, da dies möglicherweise völlig gültig ist. Der Speicherdruck wirkt sich auch auf andere Bereiche aus, die möglicherweise nicht im Fehlerprotokoll angezeigt werden, z. B. das Leeren des Plan-Cache und/oder des Pufferpools (d. H. In den Speicher geladene Datenseiten).

Es gibt mehrere integrierte Funktionen, die SQLCLR verwenden. Eine unvollständige Liste lautet wie folgt:

  • Datentypen:
    • HierarchyID
    • Erdkunde
    • Geometrie
  • Funktionen:
    • FORMAT
    • PARSE
    • TRY_PARSE
    • AT TIME ZONE (Ab SQL Server 2016)
    • COMPRESS (aber nicht UNCOMPRESS; ab SQL Server 2016)
  • Eigenschaften:
    • Datenerfassung ändern
    • Dynamic Management Framework
    • Reproduzieren
    • Richtlinienbasiertes Management
    • Stammdatendienste
    • SSISDB (die "Fuzzy Lookup" -Funktion)

Eine oder mehrere davon (oder vielleicht eine, die ich oben nicht aufgeführt habe) sind in Ihrem System betroffen. Es gibt zwei Hinweise, beide im (master.sys[runtime].78) Teil dieser Informationen, die uns Folgendes sagen:

  1. die Datenbank ist master (vorausgesetzt, Sie würden niemals benutzerdefinierte Assemblys in master laden ;-))
  2. der "Eigentümer" (dh AUTHORIZATION) der Assembly ist sys (wir können weder sys noch INFORMATION_SCHEMA als keinem dieser Principals das Eigentum an Assemblys zuweisen hat ein SID). Wenn Sie den Eigentümer für jede Assembly anzeigen möchten, führen Sie Folgendes aus:

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

Was Sie tun können, ist:

  1. Sie erwähnen, dass dieser Fehler "gelegentlich" auftritt, haben aber nicht genau definiert, wie oft dies wirklich ist. Einmal pro Stunde ist anders als einmal am Tag, was anders ist als einmal pro Woche. Der Speicherdruck tritt auf. Wenn dies nicht mehr als ein paar Mal pro Tag geschieht, würde ich nicht zu viel Zeit damit verbringen, mir darüber Sorgen zu machen.
  2. Fügen Sie mehr Speicher hinzu (entweder physisch und/oder damit SQL Server mehr Systemspeicher verwenden kann, wenn SQL Server derzeit auf eine geringere Menge beschränkt ist).
  3. Analysieren Sie, was Speicher außerhalb von SQL Server verbraucht, um festzustellen, ob auf dem Server unnötige Prozesse vorhanden sind, die auf andere Server ausgelagert oder möglicherweise vollständig heruntergefahren werden können (dh werden andere Dienste verwendet und/oder Remotedesktopsitzungen) dann SSMS usw. ausführen, die viel Speicher belegen?)
10
Solomon Rutzky

Könnte dies untersuchen: https://docs.Microsoft.com/en-us/sql/relational-databases/memory-management-architecture-guide . Insbesondere die Abfrage, was aktuell zugeordnet ist. Sie können sich auf die Diagnose konzentrieren.

Ich hatte dieses Problem schon einmal und es kam zu wiederholten Aufrufen einer CLR-Prozedur, die sich nach Abschluss des Vorgangs niemals selbst schließen würde.

7
Adam K.