none
Task-Manager - Physiklaischer RAM 100% sqlservr.exe ca. 9000KB - katastrophale Performance RRS feed

  • Frage

  • Hallo,

    wir haben einen virtuellen  SQL Server 2008 R2 Standard, das OS ist Windows 2008 R2 Standard. Zuletzt hatte der Server 16 GB RAM, was einigen zu wenig war und somit haben wir im 32 GB RAM gegeben.

    Jetzt macht der Server folgende zicken:

    Nachdem er hochfährt, schraubt er, im Task-Manager zu sehen, den RAM komplett hoch, zeigt aber unter Prozesse (aller Benutzer) gerade mal 14 GB verbraucht an. Das heißt, es sind nach kurzer Betriebsszeit nur noch ca. 200 MB frei und damit kämpfen dann die Entwickler und User gleichzeitig.

    Der SQL-Server ist auf 28 GB konfiguriert, somit bleiben dem OS noch 4 GB. Die Auslagerungsdatei wird vom OS verwaltet.

    Im ProcExp ist auch nicht mehr zu erkennen also im Task-Manager, jedenfalls was die Auslastung des RAM betrifft.

    Was könnte die Ursache für dieses Verhalten sein?

    Danke und Gruß

    Markus


    lloyd0815

    Dienstag, 21. Oktober 2014 05:18

Antworten

  • Hallo Leute,

    die Ursache ist gefunden, jedenfalls was die Auslastung des RAM betrifft.

    Die VM hatte in den Ressourcen einen Grenzwert im Arbeitsspeicher hinterlegt, der lag bei 8 GB.

    Nachdem ich den Haken auf "Unbegrenzt" gesetzt habe, hat sich die sqlservr.exe das Maximum genommen und der Server läuft sehr performant.

    Vielen Dank für eure Unterstützung!

    Gruß

    Markus


    lloyd0815

    Freitag, 24. Oktober 2014 09:18

Alle Antworten

  • Hallo Markus,

    im SQL Server 2008R2 und Vorgänger Versionen wird mit der "Max. Memory" Einstellung nur der Buffer Pool limitiert, aber nicht andere Speicher-Resourcen wie Clr, Proc Cache etc.; das Verhalten wurde erst mit Version 2012 geändert. Von daher ist es besser, das Limit noch etwas zu senken, damit das OS garantiert genügend Speicher zur Verfügung hat.

    Ist evtl. auch der Min Memory Wert gesetzt? Das würde erklären, warum der SQL Server sofort Speicher allokiert und nicht erst bei Bedarf. Wie sieht die CPU und IO Auslastung aus? Gibt es SQL Server Agent Jobs, die sofort anstarten?


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Dienstag, 21. Oktober 2014 06:05
  • Hallo Markus,
    kleine Zusatzinfo: Vergiss den Task Manager bei der Kontrolle des RAM.

    Verwende besser den Performance Monitor und dort die Werte für:
    SQLServer: Memory Manager
    - Target Server Memory (KB)
    - Total Server Memory (KB)

    Weiterhin interessant dürfte der Wert sein für
    SQLServer: Buffer Manager
    - Buffer cache hit ratio
    - Page life expectancy
    bzw.
    SQLServer: Buffer Node
    - Page life expectancy (000, 001, ... pro CPU eine Instanz)

    Den PageFile würde ich selber konfigurieren und auf erst mal auf 6 GB beschränken. Dann kannst Du die Verwendung auch im Performance Monitor kontrollieren und ggf. die Größe anpassen:
    Paging File
    - % Usage
    - % Usage Peak
     Läuft noch etwas auf der Maschine außer der Datenbank Engine? Reporting, Analysis, Integration Services?
    Dann solltest Du auch dafür entsprechend RAM freihalten.
     Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu

    Dienstag, 21. Oktober 2014 06:39
    Beantworter
  • Hallo und vielen Dank für die Antworten.

    Hier die Ergebnisse aus dem PerfMon nach 10 Minuten:

    SQLServer: Memory Manager
    - Target Server Memory (KB) = Durchschnitt/Min/Max = 10.448,480 (alle Werte gleich)
    - Total Server Memory (KB) = Durchschnitt/Min/Max = 10.273,700/10.231,232/10.329,320

    SQLServer: Buffer Manager
    - Buffer cache hit Ratio = Durchschnitt/Min/Max = 98,430/0,000/100,00
    - Page life expectancy = Durchschnitt/Min/Max = 1.605,750/1.213,000/2.031,000

    SQLServer: Buffer Node
    - Page life expectancy  = Durchschnitt/Min/Max = 1.660,711/1.213,000/2.122,000

    Bezüglich der CPU-Einstellungen:

    Der Server hat 2 virtuelle Sockets mit je 2 virtuellen CPUs. In den SQL-Servereigenschaften zeigt er und Prozessoren jedoch nur eine Node an, NumaNode0.


    lloyd0815


    • Bearbeitet Lloyd0815 Dienstag, 21. Oktober 2014 09:42
    Dienstag, 21. Oktober 2014 09:40
  • Hallo Markus,

    im SQL Server 2008R2 und Vorgänger Versionen wird mit der "Max. Memory" Einstellung nur der Buffer Pool limitiert, aber nicht andere Speicher-Resourcen wie Clr, Proc Cache etc.; das Verhalten wurde erst mit Version 2012 geändert. Von daher ist es besser, das Limit noch etwas zu senken, damit das OS garantiert genügend Speicher zur Verfügung hat.

    Ist evtl. auch der Min Memory Wert gesetzt? Das würde erklären, warum der SQL Server sofort Speicher allokiert und nicht erst bei Bedarf. Wie sieht die CPU und IO Auslastung aus? Gibt es SQL Server Agent Jobs, die sofort anstarten?


    Olaf Helper

    [ Blog] [ Xing] [ MVP]


    Ein Min. Memory ist nicht gesetzt. Es laufen auch keine Jobs im Hintergrund. Es ist einfach nicht zu erkennen, wo der RAM hin ist...

    lloyd0815

    Dienstag, 21. Oktober 2014 10:16
  • Wie passen die Zahlen denn zur ursprünglichen Aussage: Der SQL-Server ist auf 28 GB konfiguriert ???

    Lass Dir noch mal die aktuellen Werte anzeigen:

    exec sp_configure 'min server memory (MB)';
    exec sp_configure 'max server memory (MB)';

    Was läuft noch alles auf diesem virtuellen Server, außer einer SQL Server Instanz?
     Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu

    Dienstag, 21. Oktober 2014 11:15
    Beantworter
  • Es ist einfach nicht zu erkennen, wo der RAM hin ist...

    In SSMS mal Rechte-Maus auf den Server Node => "Reports" => "Standard Reports" => "Memory Consumption", der Bericht zeigt auf, was wie viel Speicher belegt. Auch der "Server Dashboard" Report ist informativ, er zeigt CPU & IO nach Datenbanken an.

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Dienstag, 21. Oktober 2014 11:38
  • Hallo Markus,

    ich mag falsch liegen, aber die Aussage In den SQL-Servereigenschaften zeigt er und Prozessoren jedoch nur eine Node an, NumaNode0. könnte darauf hinweisen, dass Du nur auf einem Knoten läufst (und evtl. der Speicher am anderen Knoten vor sich hinträumt)

    Bitte schau Dir mal an:

    How to set Soft-NUMA for SQL Server 2008 R2

    SQL Server: Clarifying The NUMA Configuration Information

    Understanding Non-uniform Memory Access

    Gruß Elmar

    Dienstag, 21. Oktober 2014 15:59
  • Wie passen die Zahlen denn zur ursprünglichen Aussage: Der SQL-Server ist auf 28 GB konfiguriert ???

    Lass Dir noch mal die aktuellen Werte anzeigen:

    <span style="color:blue">exec</span> sp_configure <span style="color:#a31515">'min server memory (MB)'</span>;
    <span style="color:blue">exec</span> sp_configure <span style="color:#a31515">'max server memory (MB)'</span>;
    

    Was läuft noch alles auf diesem virtuellen Server, außer einer SQL Server Instanz?
     Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu

    Hallo,

    das ist eine gute Frage, da er nach dem booten und einiger Laufzeit immer nur so bei ca. 10Gb herumdümpelt.

    Die genannten Prozeduren möchte er nicht ausführen, habe die Werte aber in den Facets gefunden und min Server Memory steht bei 16 und max bei 28672.

    Auf dem Server läuft nur eine Instanz des SQL-Servers und sonst nichts und es auch niemand direkt (Konsole/RDP) angemeldet, außer mir.

    Gruß

    Markus


    lloyd0815

    Donnerstag, 23. Oktober 2014 09:45
  • Es ist einfach nicht zu erkennen, wo der RAM hin ist...


    In SSMS mal Rechte-Maus auf den Server Node => "Reports" => "Standard Reports" => "Memory Consumption", der Bericht zeigt auf, was wie viel Speicher belegt. Auch der "Server Dashboard" Report ist informativ, er zeigt CPU & IO nach Datenbanken an.

    Olaf Helper

    [ Blog] [ Xing] [ MVP]



    lloyd0815

    Donnerstag, 23. Oktober 2014 09:46
  • Hallo zusammen,

    also ich muss jetzt etwas weiter ausholen und das bringt uns vielleicht der Ursache einen Schritt näher:

    Der Server war bisher aufgesetzt mit 16GB RAM. So läuft er nun seit 2011 vor sich hin. Mit der Zeit sind immer mehr Datenbanken hinzugekommen und damit auch mehr Zugriffe durch User.

    Jetzt hat ein Entwickler gemeint, im Vergleich zum Prod-Server, der mit 32GB ausgestattet ist, sei der Dev-Server (dieser Problemserver) mit 16Gb um das 6-fache langsamer als der Prod.

    Daraufhin haben wir am 10.10.2014 den RAM auf 32 GB gesetzt und damit hat der Ärger angefangen.

    Gestern, ich war allein auf der Maschine, habe ich dem RAM zurückgesetzt auf 16 GB, die Einstellungen vom SQL-Server, was die RAM-Verwaltung betrifft auf Standard gestellt - Servereigenschaften - Arbeitsspeicher - Min (MB) = 0 und Max (MB) = 2147483647. Dann den Server neu gestartet, zwei mal, da er beim ersten mal ca. 15 Minuten zum booten benötigt hat und seit dem ist Ruhe.

    Ich habe danach verschiedene Datenbanken gesichert, wiederhergestellt und kam nie an die 100%ige RAM-Auslastung, wie bisher.

    Heute folgen Tests der Entwickler und User, auch einige Stapelläufe und ich werde das Verhalten beobachten.

    Macht das für euch in irgendeiner Form Sinn, wieso er mit mehr RAM, also dem Maximum für das OS 32GB nicht klar kommt?

    Danke

    Gruß

    Markus


    lloyd0815

    Donnerstag, 23. Oktober 2014 09:53
  • Hallo Markus,

    der Werte von "Stolen Pages" ist bei Dir unerfreulich hoch; Stolen Pages sind Pages, die vom Buffer Pool (Cache) abgezogen werden, um sie für andere Prozesse bereit zu stellen.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Donnerstag, 23. Oktober 2014 10:36
  • Hallo Markus,

    der Werte von "Stolen Pages" ist bei Dir unerfreulich hoch; Stolen Pages sind Pages, die vom Buffer Pool (Cache) abgezogen werden, um sie für andere Prozesse bereit zu stellen.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Und wo kann das herkommen?

    Dazu der Task-Manager:

    01


    lloyd0815

    Donnerstag, 23. Oktober 2014 11:27

  • lloyd0815

    Donnerstag, 23. Oktober 2014 11:27
  • Hallo Leute,

    die Ursache ist gefunden, jedenfalls was die Auslastung des RAM betrifft.

    Die VM hatte in den Ressourcen einen Grenzwert im Arbeitsspeicher hinterlegt, der lag bei 8 GB.

    Nachdem ich den Haken auf "Unbegrenzt" gesetzt habe, hat sich die sqlservr.exe das Maximum genommen und der Server läuft sehr performant.

    Vielen Dank für eure Unterstützung!

    Gruß

    Markus


    lloyd0815

    Freitag, 24. Oktober 2014 09:18