none
SQL Server 2008 R2 Enterprise nimmt sich nicht genug RAM RRS feed

  • Allgemeine Diskussion

  • Hallo zusammen,

    wir haben das Problem bei einem Kundensystem, dass der SQL Server 2008 R2 (Enterprise Edition) auch bei längerer Laufzeit (> 24 Stunden) nie mehr wie ca. 140 MB RAM nimmt.
    Normalerweise liegt die Speichernutzung bei den SQL Express Installationen bei ca. 1,5 GB.

    Wir vermuten deswegen auch hier die Probleme die der Kunde hat (SQL Timeouts, usw.).

    Unsere Software wird normalerweise mit SQL Express ausgeliefert und da gibt es auch nie Probleme aber dieser Kunde hat eine DB mit 4 GB Grösse. Wegen dieser hat Er auch auf die Enterprise Edition upgedatet.

    Die Einstellungen sind wir soweit schon durchgegangen und das Internet selbst liefert nur massenweise Infos bzgl. "zuviel RAM reserviert".

    Was könnten wir denn noch prüfen?

    Grüsse aus CH

    Micha W.


    Montag, 10. Februar 2014 12:28

Alle Antworten

  • Moinsen!

    In den Einstellungen des SQL-Server's unter Arbeitsspeicher ist der maximale Arbeitsspeicher aber nicht limitiert, oder??

    Ist denn noch Arbeitsspeicher auf dem System frei? Nicht das eine andere Applikation den Arbeitsspeicher belegt.

    gruß

    Ralf

    Montag, 10. Februar 2014 12:48
  • Hallo!

    Jein.
    Er war schon limitiert (1200) aber habe ihn auch schon hochgesetzt (4096) und auch den Standardwert eingetragen.
    Alles ohne Erfolg.

    RAM sind derzeit über 3 GB frei.

    Was aber noch etwas verwunderlich ist: Laut TaskMan werden derzeit 11,7 GB RAM belegt. Wenn man die Prozesse zusammenrechnet kommt man aber auf maximal 2 GB. Wo sind die restlichen 10 GB?

    Ist übrigens ein ESX-System auf dem zwei Server (der SQL und ein DC) laufen.

    Gruss
    Micha

    Montag, 10. Februar 2014 12:55
  • Hallo Micha,

    bitte nicht mit dem Task Manager...

    Für den SQL Server kannst Du mit DBCC MEMORYSTATUS genauere Informationen erhalten: How to use the DBCC MEMORYSTATUS command to monitor memory usage on SQL Server 2005

    Mehr zum Speicher auch: An in-depth look at SQL Server Memory–Part 3 (und die anderen Teile)

    Zur Konfiguration mit VMWare siehe http://www.vmware.com/files/pdf/solutions/SQL_Server_on_VMware-Best_Practices_Guide.pdf

    Gruß Elmar

    Montag, 10. Februar 2014 19:04
  • Hallo zusammen,

    das ganze wird immer mysteriöser.
    Wir haben jetzt herausgefunden, dass 11 GB des nicht über TaskMan identifizierbaren Speichers durch Metafile (6 GB) und SQL AWE (5 GB) reserviert waren.

    Interessant dabei ist, dass AWE nie aktiv war (nichtmal für einen Test).

    Woher kommt denn dieses Metafile?

    Gruss
    Micha

    Mittwoch, 12. Februar 2014 08:15
  • Hallo Micha,

    AWE gibt es nur unter 32-Bit - und man sollte heute 64-Bit einsetzen, gerade bei EE. Wenn es sich um einen 32-Bit SQL Server handelt, so kann er - wie jeder 32-Bit Prozess - vom "normalen" Speicher nur max. etwa 3 GB verwenden. AWE ist mehr ein "Notnagel", da der Speicher nur eingeschränkt verwendet werden kann (als Pufferpool) - siehe Hinweiskasten in der Dokumentation und KB 2644592.

    Ohne Konfiguration wird AWE nicht verwendet. Einzige Erklärung: Jemand hat es geändert, ohne den Dienst neu zu starten.

    Wenn Du mit Metafile den Windows Metafile Cache meinst: Dafür nutzen neuere OS Speicher, der nicht sonst gebraucht wird. Die Speicherbelegung zeigt gut: RAMMap. Was hier darauf hindeutet, dass der SQL Server den Speicher erst gar nicht anfordert.

    Bevor man weitermacht, sollte man auf die 64-Bit EE Edition wechseln.

    Gruß Elmar

    Mittwoch, 12. Februar 2014 09:55
  • Hallo Elmar,

    vielen Dank erstmal für Deine Antworten.

    Es ist so, dass es ein Server 2008 R2 ist und den gibt es ja soweit ich weiss nur mit 64bit. Ist also auf jeden Fall ein 64bit-System.

    Das mit Restart des SQL Server Dienstes kann eigentlich auch nicht sein, da ich diesen gestern selbst durchgestartet hatte.
    Was ich nicht ausschliessen möchte ist, dass der Kunde selbst da mal "rumgespielt" hat.

    Gibt es bekannte Probleme mit dem AWE die ein ähnliches Fehlerbild darstellen?

    Gruss
    Micha

    Mittwoch, 12. Februar 2014 10:06
  • Hallo Micha,

    AWE gibt es nur unter 32-Bit, sonst passt da was bei der Aussage nicht.

    Bitte gib mal ein: SELECT @@VERSION (oder schau im SSMS unter den Server-Eigenschaften nach). Findet sich da ein "Intel x86" so ist es 32-Bit.

    Gruß Elmar

    Mittwoch, 12. Februar 2014 10:49
  • Hallo Elmar,

    der Select liefert folgendes:

    Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64)   Apr  2 2010 15:48:46   Copyright (c) Microsoft Corporation  Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor) 

    Gruss
    Micha

    Mittwoch, 12. Februar 2014 12:00
  • Hallo,

    64-Bit ist es immerhin, was AWE etwas rätselhaft werden lässt:
    http://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-530-awe-must-be-enabled-on-64-bit-servers/

    Fehlen tut aber Microsoft® SQL Server® 2008 R2 Service Pack 2, denn mit RTM sollte man seinen Server nicht mehr segeln lassen.

    Gruß Elmar

    • Bearbeitet Elmar Boye Mittwoch, 12. Februar 2014 12:14 Link
    Mittwoch, 12. Februar 2014 12:13
  • Hallo Elmar,

    der Admin hat jetzt SP2 installiert aber keine Besserung.

    Im RAMMap sieht man, dass sich AWE Speicher reserviert obwohl es deaktiviert ist!
    Wenn man in den SQL Server Einstellungen bei Memory schaut ist der Haken bei AWE unter Configured Values aus. Wenn man auf Running Values stellt ist der Haken drin.

    Kann es sein, dass AWE nicht richtig deaktiviert ist?

    sp_configure 'show advanced options', 1
    RECONFIGURE
    GO
    sp_configure 'awe enabled', 0
    RECONFIGURE
    GO

    hat jedenfalls das als Ergebnis gebracht:

    Configuration option 'show advanced options' changed from 1 to 1. Run the RECONFIGURE statement to install.
    Configuration option 'awe enabled' changed from 0 to 0. Run the RECONFIGURE statement to install.

    Gruss
    Micha

    Donnerstag, 13. Februar 2014 15:08
  • Hallo Micha,

    Der Hinweis auf SP2 hatte damit nichts zu tun, das gehört zum  Gesundheitspflegeprogramm ;)

    RAMMap (und evtl. andere) zeigen große Speicherblöcke als AWE an. Der Begriff wird hat weitergehende Bedeutungen[1].

    Bei 64-Bit benötigt man kein Mapping des Speichers in den physikalischen Adressraum, wie es bei 32-Bit notwendig ist - denn der Speicher kann direkt adressiert werden - und somit ist das AWE Flag im SQL Server bedeutungslos.

    Es sollte "Locked Pages in Memory" aktiviert sein, da zum Sperren großer Seiten erforderlich ist (vermeidet letztendlich Speicherfragmentierung). Man sollte nicht mehr Speicher festlegen, als physikalisch bzw. für die VM verfügbar ist. Die Sicht sys.dm_os_process_memoryzeigt die Werte auf (dort AWE => große Seiten => "umfangreiche Seiten").

    Anschauen solltest Du Dir, ob die (Speicher-)Konfiguration der VMs passend zu den SQL Server Einstellungen ist. Weist die VM nicht genug Speicher zu, so kann sie der SQL Server nutzen. Um zu prüfen, wie viel Speicher vom SQL Server genutzt wird, bitte die Befehle aus der ersten Antwort verwenden.

    Gruß Elmar

    [1] Für die technische Seite siehe VirtualAlloc(Ex) - intern erledigt alles der SQL Server, muss man also nicht im Detail wissen.

    Donnerstag, 13. Februar 2014 16:14
  • Hallo Elmar,

    jetzt wird es richtig krass.

    Nachdem wir den SQL Serverdienst auf den Network Service umgestellt haben (lief mit Domänen-Admin der lokaler Admin ist) ware AWE richtig aus un der SQL-Server hat sich wieder den Speicher wie konfiguriert gezogen.

    Im RAMMap wird AWE jetzt zwar noch angezeigt aber ohne Speicherreservierung (ist an meinem Win7 Laptop mit SQL Server installiert auch so).

    Geht also erstmal.

    Gruss und merci für die Hilfe
    Micha

    Freitag, 14. Februar 2014 15:53
  • Hallo Micha,

    ich vermute, da freust Du Dich über einen Pyrrhus-Sieg.

    Was den Speicher angeht, so findet AWE deswegen nicht mehr statt, weil das notwendige Privileg dem Netzwerk-Dienstkonto fehlt (und das sollte es als eingebautes Konto auch nicht haben).

    Und so sollte man dem SQL Server eigenes Domänen-Service-Konto verpassen, siehe Einrichten von Dienstkonten => Das sollte kein Administrator-Konto sein.

    AWE wiederum ist nichts Schlechtes - ausgen. dass der Task-Manager ihn nicht anzeigt; was aber kein Kriterium ist. Ich weiß nicht, ob Du den Links in den Artikel gefolgt bist, aber schau Dir (noch) einmal an:

    Fun with Locked Pages, AWE, Task Manager, and the Working Set…

    Da steht noch mal, was ich in Kurzform versucht hatte, zu erläutern.

    Und für die eingangs genannten Problemen des Kunden dürfte das eben nicht die Ursache sein ...

    Gruß Elmar

    Samstag, 15. Februar 2014 10:59