Teilen über

MSSQLSERVER_17890

  • Artikel

Gilt für: SQL Server

Details

attribute Wert
Produktname SQL Server
Ereignis-ID 17890
Ereignisquelle MSSQLSERVER
Komponente SQLEngine
Symbolischer Name SRV_WS_TRIMMED
Meldungstext Ein erheblicher Teil des SQL Server-Prozessspeichers wurde ausgelagert. Dies kann zu einer Leistungsbeeinträchtigung führen. Dauer: %d Sekunden. Workingset (KB): %I64d; Commit ausgeführt (KB): %I64d; Arbeitsspeichernutzung: %d%%.

Erklärung

Möglicherweise tritt die folgende Fehlermeldung im SQL Server-Fehlerprotokoll oder im Ereignisprotokoll der Windows-Anwendung auf.

Ein erheblicher Teil des SQL Server-Prozessspeichers wurde ausgelagert. Dies kann zu einer Leistungsbeeinträchtigung führen. Dauer: 0 Sekunden. Arbeitssatz (KB): 3383250, zugesichert (KB): 9112480, Arbeitsspeicherauslastung: 37 %.

Möglicherweise bemerken Sie zudem eine plötzliche Leistungsbeeinträchtigung bei der Abfrageausführung und allen anderen Vorgängen auf der SQL Server-Instanz.

Ursache

SQL Server überwacht die verschiedenen Speicherinformationen zum SQL Server-Prozess. In diesem Fall wurde festgestellt, dass der Arbeitssatz des Prozesses weniger als 50 % des zugesicherten Prozessarbeitsspeichers beträgt. Aus diesem Grund wurde diese Warnung ausgegeben. Nachfolgend sind die üblichen Ursachen dieser Warnung aufgeführt:

  • Das Betriebssystem übergibt große Teile des SQL Server-Speichers, der an die Auslagerungsdatei gebunden ist.
  • Dies könnte daran liegen, dass der Bedarf an Arbeitsspeicher durch andere Anwendungen oder Betriebssystemanforderungen plötzlich zunimmt.
  • Eine weitere mögliche Ursache ist, dass bestimmte Gerätetreiber zusammenhängende Arbeitsspeicherzuweisungen benötigen und anfordern.

Aktion des Benutzers

Sie können verhindern, dass das Windows-Betriebssystem den Pufferpoolspeicher des SQL Server-Prozesses auslagerungen kann, indem Sie den Speicher sperren, der für den Pufferpool im physischen Speicher zugeordnet ist. Sie sperren den Speicher, indem Sie die Sperrseiten im Speicherbenutzer direkt dem Benutzerkonto zuweisen, das als Startkonto des SQL Server-Diensts verwendet wird. Bevor Sie diese Lösung implementieren, sollten Sie die Gründe für das Auslagern von SQL Server-Arbeitsspeicher sowie die wichtigen Überlegungen vor dem Zuweisen der Benutzerberechtigung „Sperren von Seiten im Speicher“ für eine SQL Server-Instanz durchlesen.

Hinweis

Die Verwendung von Sperrseiten im Arbeitsspeicher stellt sicher, dass der von SQL Server verwaltete Speicher nicht ausgelagert wird. Threadstapel, exe und alle DLL-Images, Heap-Speicher, CLR-Speicher können jedoch weiterhin vom Betriebssystem ausgelagert werden.

Ab SQL Server 2008 SP1 kumulatives Update 2 können sowohl SQL Server Standard- als auch Enterprise-Editionen die Sperrseiten im Speicherbenutzerrecht verwenden. Weitere Informationen zur Unterstützung von gesperrten Seiten finden Sie hier: KB970070 – Unterstützung für gesperrte Seiten bei SQL Server Standard Edition (64 Bit).

Führen Sie folgende Schritte aus, um die Benutzerberechtigung „Sperren von Seiten im Speicher“ zuzuweisen:

  1. Klicken Sie auf Start und dann auf Ausführen, geben Sie gpedit.msc ein, und klicken Sie dann auf OK.
  2. Das Dialogfeld „Gruppenrichtlinie“ wird geöffnet.
  3. Erweitern Sie nacheinander Computerkonfiguration und dann Windows-Einstellungen.
  4. Erweitern Sie Sicherheitseinstellungenund dann Lokale Richtlinien.
  5. Klicken Sie auf „Zuweisen von Benutzerrechten“, und doppelklicken Sie dann auf Sperren von Seiten im Speicher.
  6. Klicken Sie im Dialogfeld Lokale Sicherheitsrichtlinie einstellen auf Benutzer hinzufügen oder Gruppe hinzufügen.
  7. Fügen Sie im Dialogfeld Benutzer auswählen oder Gruppen auswählen das Konto hinzu, das zum Ausführen der Datei „Sqlservr.exe“ berechtigt ist, und klicken Sie dann auf OK.
  8. Schließen Sie das Dialogfeld Gruppenrichtlinie.
  9. Starten Sie den SQL Server-Dienst neu.

Nachdem Sie die Sperrseiten im Speicherbenutzer richtig zugewiesen und den SQL Server-Dienst neu gestartet haben, überträgt das Windows-Betriebssystem nicht mehr den Pufferpoolspeicher innerhalb des SQL Server-Prozesses. Das Windows-Betriebssystem kann jedoch weiterhin den Nichtpufferpoolspeicher innerhalb des SQL Server-Prozesses ausblättern.

Sie können überprüfen, ob das Benutzerrecht von der SQL Server-Instanz verwendet wird, indem Sie sicherstellen, dass die folgende Meldung beim Start im SQL Server-Fehlerprotokoll geschrieben wird: "Verwenden gesperrter Seiten für pufferpool"

Diese Meldung gilt nur für SQL Server. Weitere Informationen zu dieser Meldung im ERRORLOG finden Sie in den folgenden Themen: Muss ich die Sperrseiten für Speicherberechtigungen im lokalen System zuweisen.

Auch wenn das Windows-Betriebssystem Speicher auslagert, der nicht im Zusammenhang mit dem Pufferpool steht, können Leistungsprobleme auftreten. Die im Abschnitt "Erklärung" erwähnten Fehlermeldungen werden jedoch nicht im SQL Server-Fehlerprotokoll protokolliert.

Gründe für das Auslagern von SQL Server-Arbeitsspeicher

Die Gründe für dieses Problem lassen sich in drei allgemeine Kategorien untergliedern:

  • Anwendungsbezogene Probleme: Alle Anwendungen haben gemeinsam den verfügbaren physischen Speicher ausgeschöpft, und das Betriebssystem muss Speicherplatz für neue Anwendungsanforderungen für Ressourcen freigeben. In dieser Situation sollten üblicherweise die Anwendungen ermittelt werden, die den Arbeitsspeicher auslasten. Anschließend führen Sie die erforderlichen Schritte aus, um die Speicherkapazität so auf die Anwendungen zu verteilen, dass es nicht zu einer RAM-Auslastung kommt.
  • Gerätetreiberprobleme: Gerätetreiber können die Auslagerung aller Prozesse verursachen, wenn der Treiber eine Speicherzuweisungsfunktion falsch aufruft.
  • Betriebssystemprobleme

Nachfolgend finden Sie Informationen zu diesen Kategorien

  • Anwendungsbezogene Probleme: Anwendungen können gemeinsam den gesamten RAM auf dem System verbrauchen. Wenn neuer Speicher angefordert wird, versucht das Betriebssystem, diese Anforderung zu erfüllen. Sollte kein freier Speicher verfügbar sein, wird der Arbeitssatz ausgeführter Anwendungen verkleinert, um die Speicheranforderungen zu erfüllen. In diesen Fällen macht sich möglicherweise für die meisten, wenn nicht sogar für alle Anwendungen eine signifikante Verkleinerung des Arbeitssatzes bemerkbar. Um dieses Verhalten zu kontrollieren, können Sie die folgenden Zähler des Leistungsmonitors für alle Anwendungen innerhalb des Systems überwachen:

    • Performance-Objekt: Process
    • Leistungsindikator: Arbeitssatz

    Überwachen Sie außerdem den folgenden Zähler, um die verfügbare Größe des physischen Speichers innerhalb des Systems zu ermitteln.

    • Performance-Objekt: Arbeitsspeicher
    • Leistungsindikator: Verfügbarer Arbeitsspeicher (MB)

    Das typische Verhalten ist ein Rückgang des verfügbaren Speichers auf fast 0 MB, während gleichzeitig die Arbeitssatzzähler für die meisten oder alle Prozesse des Systems plötzlich abfallen. Wenn Sie dieses Verhalten beobachten, müssen Sie möglicherweise die Speicherauslastung im System senken. Senken Sie dazu z. B. die maximale Serverarbeitsspeichergröße für SQL Server.

    In einigen Fällen wird auch zu viel Systemcache durch Anwendungen verwendet, sodass der Systemcache sehr groß wird. Um auf das Wachstum des Systemcaches zu reagieren, werden die Arbeitssätze des SQL Server-Prozesses oder anderer Anwendungen vom System aus seiten. Wenn dieses Problem auftritt, können Sie einige der Speicherverwaltungsfunktionen in der Anwendung nutzen. Mit diesen Funktionen wird die Systemcachegröße gesteuert, die Datei-E/A-Vorgänge in der Anwendung verwenden können. Mit den Funktionen „SetSystemFileCacheSize“ und „GetSystemFileCacheSize“ legen Sie z. B. die Systemcachegröße fest, die von Datei-E/A-Vorgängen verwendet werden kann.

    Mithilfe des Leistungsobjekts „Speicher“ können Sie die Werte verschiedener Zähler in diesem Objekt anzeigen, um zu ermitteln, ob der Systemcache-Arbeitssatz zu viel Speicher belegt. Zeigen Sie z. B. die Zähler „Cachebytes“ und „Systemcache: Residente Bytes“ an. Weitere Informationen zu diesem Thema finden Sie hier:

    Sie können den Microsoft Windows Dynamic Cache Service herunterladen und bereitstellen, um die Größe des Speichers festzulegen, die der Systemcache nutzt.

  • Gerätetreiberprobleme: Wenn ein Gerätetreiber die MmAllocateContiguousMemory Funktion verwendet und der Wert des Parameters "HighestAcceptableAddress" auf weniger als 4 Gigabyte (GB) festgelegt wird, kann das Windows-Betriebssystem den Arbeitssatz der Prozesse auf dem System einschließlich des SQL Server-Prozesses ausblättern. Zum Behandeln dieses Problems kontaktieren Sie den Anbieter des Gerätetreibers, um Treiberupdates zu erhalten.

    Wenn ein Gerätetreiber versucht, Speicher zu belegen, lagert das Windows-Betriebssystem möglicherweise den Arbeitssatz anderer Anwendungen aus. Mit diesem Windows-Hotfix können Sie die Ereignisablaufverfolgung verwenden, um den Gerätetreiber zu ermitteln, der das Problem verursacht. Weitere Informationen zum Treiber, der das Verkleinern des Arbeitssatzes verursacht, finden Sie unter Ermitteln von Treibern, die zusammenhängenden Speicher belegen.

  • Betriebssystemprobleme: Wenden Sie die Hotfixes an, die in den folgenden Microsoft Knowledge Base-Artikeln beschrieben werden, um bekannte Probleme zu beheben, die dazu führen, dass das Windows-Betriebssystem den Arbeitssatz des SQL Server-Prozesses ausgelagert.

    Hinweis

    Hotfixes sind kumulativ. Eine spätere Version eines Hotfixes umfasst die früheren Versionen des jeweiligen Hotfixes.

Wichtige Überlegungen vor dem Zuweisen der Benutzerberechtigung „Sperren von Seiten im Speicher“

Bevor Sie die Benutzerberechtigung „Sperren von Seiten im Speicher“ zuweisen, sollten Sie einige Aspekte berücksichtigen. Wenn diese Benutzerberechtigung in Systemen zugewiesen wird, die nicht ordnungsgemäß konfiguriert sind, kann das System instabil oder die Leistung des gesamten Systems beeinträchtigt werden. Darüber hinaus wird möglicherweise die Ereignis-ID 333 im Ereignisprotokoll protokolliert.

Wenn Sie sich an den Microsoft-Kundendienst (CSS) für diese Probleme wenden, bitten CSS-Techniker Sie möglicherweise, diesen Benutzerrecht für das Benutzerkonto zu widerrufen, das als Startkonto des SQL Server-Diensts verwendet wird. Dieser Schritt kann erforderlich sein, um wichtige Leistungsdaten zu sammeln, die CSS-Techniker für die erforderliche Konfiguration der verschiedenen Optionen für SQL Server und für andere Anwendungen verwenden können, die auf dem System ausgeführt werden. Nachdem CSS-Techniker die Leistungsdaten gesammelt haben, können Sie die Sperrseiten im Speicherbenutzer direkt dem Startkonto des SQL Server-Diensts zuweisen.

Stellen Sie vor dem Zuweisen der Benutzerberechtigung „Sperren von Seiten im Speicher“ sicher, dass Sie ein Leistungsmonitorprotokoll erstellen, anhand dessen Sie die Speicheranforderungen verschiedener Anwendungen und Dienste ermitteln können, die im System installiert sind. Zu diesen Anwendungen zählt auch SQL Server. Erfassen Sie die folgenden Baselineinformationen, um die Speicheranforderungen zu ermitteln:

  • Stellen Sie sicher, dass die Optionen „Max. Serverarbeitsspeicher“ und „Min. Serverarbeitsspeicher“ ordnungsgemäß konfiguriert sind. Diese Optionen spiegeln nur die Speicheranforderung des Pufferpools des SQL Server-Prozesses wider. Diese Optionen enthalten nicht den Speicher, der anderen Komponenten innerhalb des SQL Server-Prozesses zugeordnet ist. Dazu zählen die folgenden Komponenten:

    • Die SQL Server-Arbeitsthreads
    • Verschiedene DLLs und Komponenten, die der SQL Server-Prozess im Adressraum des SQL Server-Prozesses lädt
    • Sicherungs- und Wiederherstellungsvorgänge

  • Die DLLs und Komponenten umfassen verschiedene OLE DB-Anbieter, erweiterte gespeicherte Prozeduren, Microsoft COM-Objekte, die für die sp_OACreate gespeicherte Prozedur, verknüpfte Server und SQL Server CLR verwendet werden. Der für diese Komponenten zugewiesene Arbeitsspeicher fällt unter den Nichtpufferpoolbereich des Adressraums des SQL Server-Prozesses. Um im Idealfall die maximale Arbeitsspeichermenge zu ermitteln, die der gesamte SQL Server-Prozess verwenden kann, müssen Sie den Speicher subtrahieren, der für Komponenten zugewiesen ist, die den Pufferpool nicht aus dem gesamten Arbeitsspeicher verwenden, den der SQL Server-Prozess verwenden soll. Den verbleibenden Wert können Sie dann verwenden, um die Option „Max. Serverarbeitsspeicher“ festzulegen. Bevor Sie die Option für den maximalen Serverspeicher und die Min.-Serverspeicheroption festlegen, sollten Sie das Thema "Manuelles Festlegen der Speicheroptionen" in SQL Server-Büchern online lesen.

  • Bestimmen Sie die Arbeitsspeicheranforderungen anderer Anwendungen und der Komponenten des Windows-Betriebssystems. Anwendungen können andere SQL Server-Komponenten enthalten, z. B. SQL Server-Agent, SQL Server-Replikation Agents, SQL Server Reporting Services, SQL Server Analysis Services, SQL Server Integration Services und SQL Server Full Text Search. Anwendungen, die Sicherungs- und Dateikopiervorgänge ausführen, können eine große Menge an Arbeitsspeicher belegen. Berücksichtigen Sie Vorgänge wie das Massenkopieren und den Momentaufnahmen-Agent, durch die Datei-E/A generiert wird. Wenn Sie die Werte für „Max. Serverarbeitsspeicher“ und „Min. Serverarbeitsspeicher“ festlegen, müssen die Speicheranforderungen all dieser Anwendungen berücksichtigt werden. Um die Speicheranforderung für einen bestimmten Prozess zu bestimmen, können Sie für jeden Prozess die Zähler „Private Bytes“ und „Arbeitssatz“ unter dem Objekt „Prozess“ verwenden.

  • Standardmäßig wurde die Benutzerberechtigung „Sperren von Seiten im Speicher“ dem integrierten Konto „Lokales System“ bereits zugewiesen. Weitere Informationen finden Sie auf der folgenden Microsoft-Website: Muss ich die Sperrseiten im Speicherberechtigung für das lokale System zuweisen?

  • Wenn Sie ein Windows-Benutzerkonto global für alle SQL Server-Prozesse in einer Domäne verwenden, bestimmen Sie die Benutzerrechte, die mithilfe einer Gruppenrichtlinienkonfiguration zugewiesen werden. Ein 32-Bit-SQL Server-Prozess kann dieses Konto als Startkonto verwenden. Für dieses Konto ist die Benutzerberechtigung „Sperren von Seiten im Speicher“ jedoch erforderlich, um das Address Windowing Extensions-Feature (AWE) zu aktivieren. Weitere Informationen finden Sie im Thema "Bereitstellen des maximalen Arbeitsspeichers für SQL Server" in SQL Server Books Online.

  • Bevor Sie die Option für den maximalen Serverspeicher und die Min.-Serverspeicheroption für mehrere SQL Server-Instanzen konfigurieren, sollten Sie die Speicheranforderungen des Nichtpufferpools für jede Instanz von SQL Server berücksichtigen. Konfigurieren Sie diese Optionen dann für jede Instanz von SQL Server.

Idealerweise erfassen Sie diese Baselineinformationen zu Spitzenlastzeiten. Auf diese Weise können Sie die Speicheranforderungen für verschiedene Anwendungen und Komponenten zur Unterstützung der Spitzenlast bestimmen. Die Arbeitsspeicheranforderungen variieren abhängig von den Aktivitäten und Anwendungen, die auf einem System ausgeführt werden. Sie können die Informationen abrufen, die in der dynamischen Verwaltungssicht „sys.dm_os_process_memory“ bereitgestellt werden, um zu ermitteln, ob es innerhalb des Systems zu einer hohen Speicherauslastung kommt. Weitere Informationen finden Sie unter sys.dm_os_process_memory (Transact-SQL).

In Windows Server 2008 und R2 hinzugefügte Verbesserungen

Mit Windows Server 2008 und Windows Server 2008 R2 wurde der Mechanismus für die Zuordnung von zusammenhängendem Speicher verbessert. Durch diese Verbesserung lassen sich in Windows Server 2008 und Windows Server 2008 R2 die Auswirkungen reduzieren, die mit dem Auslagern der Arbeitssätze von Anwendungen einhergehen, wenn neue Speicheranforderungen eingehen.

Nachfolgend werden die Verbesserungen aus dem Microsoft-Whitepaper zu den Fortschritten bei der Speicherverwaltung in Windows beschrieben:

In Windows Server 2008 wurde die Zuordnung von physisch zusammenhängendem Speicher erheblich verbessert. Anforderungen zum Zuordnen von zusammenhängendem Speicher werden nun mit deutlich höherer Wahrscheinlichkeit erfolgreich ausgeführt. Der Grund dafür ist, dass der Speicher-Manager Seiten jetzt dynamisch ersetzt und dabei üblicherweise den Arbeitssatz nicht verkleinert und keine E/A-Vorgänge ausführt. Darüber hinaus können nun deutlich mehr Seitentypen (darunter u. a. Kernelstapel und Dateisystem-Metadatenseiten) ersetzt werden. Folglich ist üblicherweise eine größere Menge an zusammenhängendem Speicher verfügbar. Außerdem wurden die Kosten für diese Zuordnungen deutlich reduziert.

Weitere Informationen finden Sie unter Probleme beim Verkleinern von SQL Server-Arbeitssätzen.

Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.