none
A significant part of sql server process memory has been paged out. RRS feed

  • Frage

  • Hallo,

    wir haben einen SQL-Server 2012 Standard ED SP2 / SP3 im Fail Over Cluster im Einsatz. Dieser läuft auf einem Microsoft Server 2008 R2 Enterprise Server. Dieser Server ist mit 32 GB RAM ausgestattet.

    Auf diesem Server haben wir eine SQL Server 2012 SP2 Standard Instanz und eine SQL Server 2012 SP3 benannte Instanz installiert. Nach dem ich die benannte Instanz installiert habe, schaute ich mir die ERRORLOG-File vom SQL Server der benannten Instanz an darin fand ich folgende Meldung:

     A significant part of sql server process memory has been paged out. This may result in a performance degradation. Duration: 329 seconds. Working set (KB): 135068, committed (KB): 293292, memory utilization: 46%.

    Nun habe ich schon die Einstellungen der Arbeitsspeicher-Optionen in der jeweiligen SQL-Server-Instanz mehrmals angepasst.

    Derzeit sind die Einstellungen für: Minimaler Serverarbeitsspeicher auf 10GB

                                                      Maximaler Serverarbeitsspeicher auf 14 GB

                                                      Minimaler Arbeitsspeicher pro Abfrage auf 1024KB

    Alle Anpassungen brachten keine Verbesserungen. Schaue ich Tagsüber im Taskmanager unter den Prozessen nach, dann hat die 1. SQL-Instanz (Standardinstanz) ein zugeordneten Arbeitsspeicher von 14 GB und die 2. benannte Instanz einen zugeordneten Arbeitsspeicher von ca. 1 GB.

    Kann mir jemand sagen wo ich noch was anpassen muß, damit diese o.g. Meldung nicht mehr auftaucht?

    Danke

    Viele Grüße

    Sabine

    Donnerstag, 5. Januar 2017 13:18

Antworten

  • Hallo Sabine

    die Einstellung für minimalen RAM greift erst wenn der Prozess auch mal diesen Wert erreicht hat. Wenn er die Hürde nie erreicht ist die Einstellung nutzlos.

    Um zu verhindern dass der SQL Server in das Pagefile ausgelagert wird kann man die SQL Server Prozesse dafür ausschließen

    https://msdn.microsoft.com/en-us/library/ms190730.aspx

    Hier muss man die Dienstkonten des SQL Servers eintragen. Achtung. Die Einstellung greift für alle Prozesses mit diesem Dienstkonto.

    Zudem solltest du dir mal den PLE Wert beider Instanzen ansehen

    USE master;
    GO
    
    -- Page Life Expectancy (PLE) value for each NUMA node in current instance!
    SELECT	@@SERVERNAME											AS	[Server Name],
    		[object_name],
    		[instance_name],
    		[cntr_value]											AS	[Page Life Expectancy],
    		GETDATE()												AS	[Measure_Date_Time],
    		(SELECT sqlserver_start_time FROM sys.dm_os_sys_info)	AS	Server_Start_Date_Time
    FROM	sys.dm_os_performance_counters WITH (NOLOCK)
    WHERE	[object_name] LIKE N'%Buffer Node%' AND
    		[counter_name] = N'Page life expectancy' OPTION (RECOMPILE);

    Gruß Benjamin


    Benjamin Hoch
    MCSE: Data Platform
    MCSE: Data Management and Analytics
    MCSA: SQL Server 2012/2014
    MCSA: Windows Server 2012
    Blog


    • Bearbeitet Benjamin.Hoch Donnerstag, 5. Januar 2017 13:34
    • Als Antwort vorgeschlagen Benjamin.Hoch Dienstag, 10. Januar 2017 07:41
    • Als Antwort markiert sglbs Dienstag, 10. Januar 2017 07:49
    Donnerstag, 5. Januar 2017 13:29

Alle Antworten

  • Hallo Sabine

    die Einstellung für minimalen RAM greift erst wenn der Prozess auch mal diesen Wert erreicht hat. Wenn er die Hürde nie erreicht ist die Einstellung nutzlos.

    Um zu verhindern dass der SQL Server in das Pagefile ausgelagert wird kann man die SQL Server Prozesse dafür ausschließen

    https://msdn.microsoft.com/en-us/library/ms190730.aspx

    Hier muss man die Dienstkonten des SQL Servers eintragen. Achtung. Die Einstellung greift für alle Prozesses mit diesem Dienstkonto.

    Zudem solltest du dir mal den PLE Wert beider Instanzen ansehen

    USE master;
    GO
    
    -- Page Life Expectancy (PLE) value for each NUMA node in current instance!
    SELECT	@@SERVERNAME											AS	[Server Name],
    		[object_name],
    		[instance_name],
    		[cntr_value]											AS	[Page Life Expectancy],
    		GETDATE()												AS	[Measure_Date_Time],
    		(SELECT sqlserver_start_time FROM sys.dm_os_sys_info)	AS	Server_Start_Date_Time
    FROM	sys.dm_os_performance_counters WITH (NOLOCK)
    WHERE	[object_name] LIKE N'%Buffer Node%' AND
    		[counter_name] = N'Page life expectancy' OPTION (RECOMPILE);

    Gruß Benjamin


    Benjamin Hoch
    MCSE: Data Platform
    MCSE: Data Management and Analytics
    MCSA: SQL Server 2012/2014
    MCSA: Windows Server 2012
    Blog


    • Bearbeitet Benjamin.Hoch Donnerstag, 5. Januar 2017 13:34
    • Als Antwort vorgeschlagen Benjamin.Hoch Dienstag, 10. Januar 2017 07:41
    • Als Antwort markiert sglbs Dienstag, 10. Januar 2017 07:49
    Donnerstag, 5. Januar 2017 13:29
  • Hallo Benjamin,

    vielen Dank für die schnelle Beantwortung meiner Frage.

    Ich habe gemäß Deinem Hinweis den User unter dem die SQL-Server-Prozesse ausgeführt werden, der Lokalen Richtlinie "Sperren von Seiten im Speicher" hinzugefügt. Und werde es in den nächsten Tagen mal beobachten welche Auswirkung diese Einstellung hat.

    Die PLE für die jeweilige Instanz liegt bei uns in einem guten Bereich. (meine ich jedenfalls)

    Wenn ich Deine o.g. Abfrage ausführe bekomme ich folgende Werte.

    1. Instanz hat demnach einen PLE von 30229

    2. Instanz hat demnach einen PLE von 292979

    Ich habe gelesen alles was höher ist als 300 ist gut. Ich hoffe dem ist so.

    Viele Grüße

    Sabine

    Montag, 9. Januar 2017 08:56
  • Hallo Sabine,

    der Wert von 300 ist schon sehr sehr alt. Heute sollte man Werte von 1000 - 5000 als Minimum ansetzen. Aber auch da sieht es ja sehr gut aus.

    Insgesamt kann man sagen dass die Instanz 2 mit dem Arbeitsspeicher sehr gut auskommt. Wenn dann die Daten auch wirklich im RAM liegen sehe ich da keine Probleme was den Arbeitsspeicher angeht.

    Gruß Benjamin


    Benjamin Hoch
    MCSE: Data Platform & Data Management and Analytics
    MCSA: SQL Server 2012/2014 & 2016 DB Administration
    MCSA: Windows Server 2012

    Montag, 9. Januar 2017 09:00
  • Hallo Benjamin! Hallo Sabine!

    Die Empfehlung von 300 Sekunden stammt aus der Zeit, als die Server in der Regel 4 GB RAM hatten. 4 GB RAM in 5 Minuten zu lesen war ok.

    Heute haben die Server aber viel mehr RAM (32 GB sind wahrscheinlich eher die Untergrenze).

    Am besten teilt man den RAM durch 4GB und multipliziert das Ergebnis mit 300 um einen adäquaten Wert zu erhalten.

    Siehe auch: What’s Wrong about Page Life Expectancy >= 300?

    Instanz 1 könnte also locker bis auf 1050 fallen, liegt aber weit darüber. Instanz 2 zeigt uns mit dem Wert eigentlich an, dass es überhaupt keine Anforderungen gibt Daten nachzuladen.


    Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu

    • Als Antwort vorgeschlagen Benjamin.Hoch Dienstag, 10. Januar 2017 07:41
    Montag, 9. Januar 2017 10:06
    Beantworter
  • Moin,

    was sagen denn die PerfMon-Counter "target server memory" und "total server memory"?


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    Montag, 9. Januar 2017 11:13
  • Hallo Benjamin, Hallo Christoph,

    das Problem ist gelöst. Der SQL-Server lagert den Speicher nicht mehr aus nach dem ich die Einstellungen vorgenommen habe wie diese hier im Artikel ms190730.aspx beschrieben wurde.

    Die PLE bei beiden Instanzen ist derzeit bei 44429 bzw 44486.

    Sieht also gut aus.

    Vielen Dank für Eure Hilfe.

    Viele Grüße

    Sabine

    Dienstag, 10. Januar 2017 07:35
  • Hallo Sabine,

    dann markiere doch bitte die für Dich relevanten Antworten im Forum.


    Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu

    Dienstag, 10. Januar 2017 07:45
    Beantworter