none
SQL Server gibt Arbeitsspeicher nicht wieder frei RRS feed

  • Frage

  • Hallo,

    ich arbeite mit dem SQL Server 2008 R2 und habe Fragen zur Nutzung des Arbeitsspeichers durch den SQL Server. Ich habe die maximale Speichergröße für den SQL Server auf 200GB (204800 MB) festgelegt, dennoch wird mir im Task Manager angezeigt, dass 213 GB belegt sind. Dieser belegte Arbeitsspeicher wird erst durch einen Neustart des SQL Servers wieder freigegeben.

    1) Kann mir jemand erklären, was der Grund dafür sein kann, dass der SQL Server über das gesetzte Limit hinaus Arbeitsspeicher belegt?

    2) Wieso gibt der SQL Server nicht benötigten Speicherplatz bis zum gesetzen Minimum nicht wieder frei? In so ziemlich allen Texten die ich gefunden habe, wird von einer dynamischen Speicherverwaltung gesprochen und dass nicht benötigter Speicherplatz bis zum Minimumswert wieder freigegegen wird.

    Danke und Gruß, Alex

    Donnerstag, 1. September 2011 12:37

Antworten

  • Hallo Alex,

    zu Punkt 2 kann ich Olaf nur zustimmen.

    Zu Punkt 1 kann ich noch folgendes hinzufügen. Das gesetzte Limit (Maximum Server Memory) bezieht sich auf seitens des SQL Servers nur auf den Buffer Pool des SQL Servers. Der Buffer Pool des SQL Servers ist die Komponente die für den Cache der Pages und AUsführungsüläne verantwortlich zeichnet. Innerhalb des SQL Servers ist es jedoch möglich, das andere Komponenten ebenfalls noch Arbeitsspeicher beanspruchen wie z.B. SQLCLR Stored Procedures, die nicht Bestandteil des Buffer Pools sind und somit der Speicherbedarf über die Konfigurationsoption Max-Memory steigt. Dieser Speicherplatzbedarf ist auch nicht einstellbar.

     


    Gruß Falk
    Falk Krahl
    • Als Antwort markiert Alex_23 Freitag, 2. September 2011 07:19
    Donnerstag, 1. September 2011 18:34
  • Hallo Alex,

    zu 1) Nun, eigentlich sollte wirklich nur maximal das festgelegte Oberlimit verwendet werden; aber es sind ja "nur" 6% mehr als gewünscht, das würde ich einem "Toleranzwert" zurechnen.

    zu 2) Warum sollte er? Einmal allokierter Speicher behält der SQL Server solange, bis vom System die Anforderung kommt, das Speicher freigegeben werden soll. Ständig Speicher freigeben und wenn eine Sekunde später eine Abfrage gestartet wird, den wieder neu allokieren wäre hoher Verwaltungsaufwand und so sehr ineffektiv.


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing
    • Als Antwort markiert Alex_23 Freitag, 2. September 2011 07:19
    Donnerstag, 1. September 2011 15:19

Alle Antworten

  • Hallo Alex,

    zu 1) Nun, eigentlich sollte wirklich nur maximal das festgelegte Oberlimit verwendet werden; aber es sind ja "nur" 6% mehr als gewünscht, das würde ich einem "Toleranzwert" zurechnen.

    zu 2) Warum sollte er? Einmal allokierter Speicher behält der SQL Server solange, bis vom System die Anforderung kommt, das Speicher freigegeben werden soll. Ständig Speicher freigeben und wenn eine Sekunde später eine Abfrage gestartet wird, den wieder neu allokieren wäre hoher Verwaltungsaufwand und so sehr ineffektiv.


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing
    • Als Antwort markiert Alex_23 Freitag, 2. September 2011 07:19
    Donnerstag, 1. September 2011 15:19
  • Hallo Alex,

    zu Punkt 2 kann ich Olaf nur zustimmen.

    Zu Punkt 1 kann ich noch folgendes hinzufügen. Das gesetzte Limit (Maximum Server Memory) bezieht sich auf seitens des SQL Servers nur auf den Buffer Pool des SQL Servers. Der Buffer Pool des SQL Servers ist die Komponente die für den Cache der Pages und AUsführungsüläne verantwortlich zeichnet. Innerhalb des SQL Servers ist es jedoch möglich, das andere Komponenten ebenfalls noch Arbeitsspeicher beanspruchen wie z.B. SQLCLR Stored Procedures, die nicht Bestandteil des Buffer Pools sind und somit der Speicherbedarf über die Konfigurationsoption Max-Memory steigt. Dieser Speicherplatzbedarf ist auch nicht einstellbar.

     


    Gruß Falk
    Falk Krahl
    • Als Antwort markiert Alex_23 Freitag, 2. September 2011 07:19
    Donnerstag, 1. September 2011 18:34
  • Hallo Olaf, hallo Falk,

    besten Dank für die hilfreichen Antworten.

    @Falk: Kann man im Prinzip sagen, dass der Speicherbedarf der "anderen Komponenten" quasi zum "Basisbedarf" des SQL Servers gehört?

    Schönen Gruß Alex


    • Bearbeitet Alex_23 Freitag, 2. September 2011 07:35
    Freitag, 2. September 2011 07:22
  • Hallo Alex,

    was 1) betrifft, hat Falk natürlich Recht.

    In SSMS einmal ein Rechte-Maus Klick auf den Server Node => Berichte => Standardberichte => Arbeitsspeichernutzung.

    Hier bekommst Du nett-bunt aufgeführt, welche Komponente (Clerk) wieviel Speicher verwendet; nur MEMORYCLERK_SQLBUFFERPOOL ist der von Falk beschriebene konfigurierbare Teil.
    Buck Woody hat den Inhalt des Berichtes mal in seinem Blog erläutert: Memory Consumption.

    Kannst Du alternative auch über die DMV sys.dm_os_memory_clerks abfragen.


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing
    Freitag, 2. September 2011 15:45