11
Speicherauslastung 99Prozent obwohl genug RAM vorhanden
Hallo Zusammen,
ich habe hier einen Windows 2008 (R1) Datacenter x64 mit installiertem SQL Server 2008. Der Server liegt auf einer ESX 5.0 Umgebung (Enterprise Plus). Datenspeicher ist eine NetApp SAN.
Ich habe nun das Problem, dass der Server permanent ausgelastet ist. Die Auslastung des physkalischen Speichers liegt im Taskmanager immer bei 99%. Wenn ich die Prozesse im Taskmanager (alle Benutzer) zusammenrechne, komme ich aber nur auf circa auf max. 14GB. Der Server verfügt aber über 32GB RAM.
Warum ist die Speicherauslastung so hoch ? Jemand eine Idee ? Größere Abfragen im SQL Server sind teilweise unmöglich da das System total ausgelastet ist.
Vielen Dank
ich habe hier einen Windows 2008 (R1) Datacenter x64 mit installiertem SQL Server 2008. Der Server liegt auf einer ESX 5.0 Umgebung (Enterprise Plus). Datenspeicher ist eine NetApp SAN.
Ich habe nun das Problem, dass der Server permanent ausgelastet ist. Die Auslastung des physkalischen Speichers liegt im Taskmanager immer bei 99%. Wenn ich die Prozesse im Taskmanager (alle Benutzer) zusammenrechne, komme ich aber nur auf circa auf max. 14GB. Der Server verfügt aber über 32GB RAM.
Warum ist die Speicherauslastung so hoch ? Jemand eine Idee ? Größere Abfragen im SQL Server sind teilweise unmöglich da das System total ausgelastet ist.
Vielen Dank
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 193323
Url: https://administrator.de/contentid/193323
Ausgedruckt am: 22.11.2024 um 01:11 Uhr
11 Kommentare
Neuester Kommentar
Moin,
jeder dritte Tag das selbe Thema
Datenbankserver (SQL) wie auch darauf basierende Server (z.Bsp. Exchange) krallen sich allen zur Verfügung stehenden Speicher
Gruß
24
jeder dritte Tag das selbe Thema
Datenbankserver (SQL) wie auch darauf basierende Server (z.Bsp. Exchange) krallen sich allen zur Verfügung stehenden Speicher
Gruß
24
Hallo zusammen,
das machen sie aber nur wenn man es zulässt. Man kann ja im SQL Managemant Studio den auf die Properties gehen und dort unter Select a Page Die Seite Memory aufrufen und das Maximum server memory so einstellen das der SQL nur z.B. 20480 MB (bei 32 Gig RAM natürlich) verwenden darf dann bleiben für dss Betriebssystem immerhin 12 Gig übrig. Dass sollte auf jeden Fall reichen. Ansonnsten kann man mit diesem Wert ein bisschen rumspielen bis man das optimale Verhältnis Speicher Betriebssystem und Speicher SQL gefunden hat und damit die beste Performance erreicht.
Gruß
virtuelleruser
das machen sie aber nur wenn man es zulässt. Man kann ja im SQL Managemant Studio den auf die Properties gehen und dort unter Select a Page Die Seite Memory aufrufen und das Maximum server memory so einstellen das der SQL nur z.B. 20480 MB (bei 32 Gig RAM natürlich) verwenden darf dann bleiben für dss Betriebssystem immerhin 12 Gig übrig. Dass sollte auf jeden Fall reichen. Ansonnsten kann man mit diesem Wert ein bisschen rumspielen bis man das optimale Verhältnis Speicher Betriebssystem und Speicher SQL gefunden hat und damit die beste Performance erreicht.
Gruß
virtuelleruser
Hi,
das ist ein Cache/Speicher-Problem, welches in 2k8 und IMO in 2k8 R2 leider existiert.
Siehe: http://sqlblogcasts.com/blogs/grumpyolddba/archive/2009/03/18/x64-memor ...
Gruß Daniel
das ist ein Cache/Speicher-Problem, welches in 2k8 und IMO in 2k8 R2 leider existiert.
Siehe: http://sqlblogcasts.com/blogs/grumpyolddba/archive/2009/03/18/x64-memor ...
Gruß Daniel
Moin.
Es ist leider so, dass MS das bei SQL und Exchange nicht wirklich im Griff hat. MS schreibt in Knowledgebaseartikeln, dass es so beabsichtigt ist. Sie schreiben auch, dass der Speicher jederzeit schnell freigegeben wird, wenn woanders benötigt... und eben dies ist technisch grottenschlecht umgesetzt, so auch meine Erfahrung mit Exchange 2007 und ebenso SQL 2008 auf Windows 2008 Server - die Server lahmen ohne Ende (in der Bedienung, nicht in Ihren eigentlichen Diensten, die dies verursachen!), wenn der Speicher einmal "vollgelaufen" ist. Bei Exchange hilft wenigstens wirklich, einen regkey zu setzen, der der store.exe ein Limit auferlegt... das klappt!
Du kannst per SQL-Befehl beschneiden, wieviel Speicher sich der SQL reserviert. Hat bei mir leider keine Besserung gebracht, teste dennoch. Ebenso solltest Du dies mal testen: DynCache http://www.microsoft.com/en-us/download/details.aspx?id=9258
Also: Das Problem ist MS bekannt...
Es ist leider so, dass MS das bei SQL und Exchange nicht wirklich im Griff hat. MS schreibt in Knowledgebaseartikeln, dass es so beabsichtigt ist. Sie schreiben auch, dass der Speicher jederzeit schnell freigegeben wird, wenn woanders benötigt... und eben dies ist technisch grottenschlecht umgesetzt, so auch meine Erfahrung mit Exchange 2007 und ebenso SQL 2008 auf Windows 2008 Server - die Server lahmen ohne Ende (in der Bedienung, nicht in Ihren eigentlichen Diensten, die dies verursachen!), wenn der Speicher einmal "vollgelaufen" ist. Bei Exchange hilft wenigstens wirklich, einen regkey zu setzen, der der store.exe ein Limit auferlegt... das klappt!
Du kannst per SQL-Befehl beschneiden, wieviel Speicher sich der SQL reserviert. Hat bei mir leider keine Besserung gebracht, teste dennoch. Ebenso solltest Du dies mal testen: DynCache http://www.microsoft.com/en-us/download/details.aspx?id=9258
Overview
The Microsoft Windows Dynamic Cache Service will manage the working set size of the Windows System File Cache. For 64 bit systems this service helps to address the problem of excessive cached read I/O that could eventually consume all of physical memory. Sample source code and compiled files are included in the compressed file.
The Microsoft Windows Dynamic Cache Service will manage the working set size of the Windows System File Cache. For 64 bit systems this service helps to address the problem of excessive cached read I/O that could eventually consume all of physical memory. Sample source code and compiled files are included in the compressed file.
Also: Das Problem ist MS bekannt...
Hallo,
und geben diesen, teilweise, wieder frei sobald ein anderer Prozess diesen zwingend benötigt. Das spart im Spitzenfall Zeit, da der Speicher schon reserviert ist.
Schaue bei größeren Abfragen mal auf die CPU und I/O Werte des Systems.
Eigene Anwendung oder eingekauft? Wenn eigen, Indexe kontrollieren und ggf. Modell überarbeiten.
Ansonsten: MS SQL nutzt sehr viel Arbeitsspeicher
Gruß
Heiko
und geben diesen, teilweise, wieder frei sobald ein anderer Prozess diesen zwingend benötigt. Das spart im Spitzenfall Zeit, da der Speicher schon reserviert ist.
Schaue bei größeren Abfragen mal auf die CPU und I/O Werte des Systems.
Eigene Anwendung oder eingekauft? Wenn eigen, Indexe kontrollieren und ggf. Modell überarbeiten.
Ansonsten: MS SQL nutzt sehr viel Arbeitsspeicher
Gruß
Heiko
Moin,
sind das auchg 32GB echter Speicher, oder hat der Host schon einen Speicherengpass?
Schau dir mal das Tab "Ressource Allocation" der VM an:
- Ist das Limit < dem Konfigurierten Speicher?
- Hat der Gast Speicher der compressed, swapped oder balooned ist?
lg,
Slainte
sind das auchg 32GB echter Speicher, oder hat der Host schon einen Speicherengpass?
Schau dir mal das Tab "Ressource Allocation" der VM an:
- Ist das Limit < dem Konfigurierten Speicher?
- Hat der Gast Speicher der compressed, swapped oder balooned ist?
System total ausgelastet
Speicherauslasung? oder auch CPU?lg,
Slainte
Hallo SlainteMhath,
danke für deine Antwort (und auch danke für alle anderen Antworten).
Für die VM sind 32GB RAM reserviert. Siehe Screenshot - Es werden 20GB Ram balooned. Warum ?
Screenshot :
http://www.abload.de/img/unbenanntcnzsg.jpg
CPU Auslastung ist soweit ok.
danke für deine Antwort (und auch danke für alle anderen Antworten).
Für die VM sind 32GB RAM reserviert. Siehe Screenshot - Es werden 20GB Ram balooned. Warum ?
Screenshot :
http://www.abload.de/img/unbenanntcnzsg.jpg
CPU Auslastung ist soweit ok.
Moin,
das ist nicht nur Speicher balooned, sonder da geswapped und komprimiert - das ist dein Performancekiller. Das ganze deutet darauf hin, das der Host zuwenig phys. RAM hat um alle VM mit "echtem" Speicher zu bedienen.
2 Fragen:
- Wieviel phys. RAM hat der Host?
- Wie sehen die Anderen VMs auf dem Host(s) aus? Sind da noch mehr Reservierungen eingetragen?
/EDIT:
Bei näherer Betrachtung sehe ich, das lediglich 1,45GB aktiv, d.h. in Benutzung sind. Warum hast du denn 32GB für die VM reserviert? Versuchs mal mit 8GB Reservierung (wenn das überhaupt notwendig ist) und 32GB Limit, dafür die Zuteilungspriorität auf "hoch" setzen.
Zur Frage des "Warum": Ballooning passiert immer dann, wenn dem Host nicht genug phys. RAM hat. Durch Ballooing zwingt der VMTraiber das Gast OS Speicher auf Platte auszulagern. Diser Speicher wird dann benutzt um andere VMs mit phys. RAM zu versorgen.
lg,
Slainte
das ist nicht nur Speicher balooned, sonder da geswapped und komprimiert - das ist dein Performancekiller. Das ganze deutet darauf hin, das der Host zuwenig phys. RAM hat um alle VM mit "echtem" Speicher zu bedienen.
2 Fragen:
- Wieviel phys. RAM hat der Host?
- Wie sehen die Anderen VMs auf dem Host(s) aus? Sind da noch mehr Reservierungen eingetragen?
/EDIT:
Bei näherer Betrachtung sehe ich, das lediglich 1,45GB aktiv, d.h. in Benutzung sind. Warum hast du denn 32GB für die VM reserviert? Versuchs mal mit 8GB Reservierung (wenn das überhaupt notwendig ist) und 32GB Limit, dafür die Zuteilungspriorität auf "hoch" setzen.
Zur Frage des "Warum": Ballooning passiert immer dann, wenn dem Host nicht genug phys. RAM hat. Durch Ballooing zwingt der VMTraiber das Gast OS Speicher auf Platte auszulagern. Diser Speicher wird dann benutzt um andere VMs mit phys. RAM zu versorgen.
lg,
Slainte
Moin SlainteMhath,
am physikalischem (ESX) Host kann es wohl nicht liegen. Der hat 256GB RAM. Die anderen 9 ESX Hosts im Cluster haben auch 256GB RAM. Der besagte SQL Server und drei weitere VMs sind die einzigen, die Reservierungen haben. Die anderen VMs mit Reservierungen sehen soweit gut aus.
Ich glaube ich habe den Übeltäter aber nun gefunden. Der Ressourcenpool für den SQL Server war, warum auch immer fehlerhaft. Ich habe diesen nun gelöscht und neu angelegt. Jetzt läuft der Server auf jeden Fall wesentlich schneller.
Was ich aber trotzdem nicht ganz verstehe ist, dass auf dem SQL Server nun im Taskmanager 28GB RAM für den SQL Server genutzt werden (habe ich so im SQL Server eingestellt) auf dem ESX sieht es aber folgendermaßen aus :
Screenshot :
http://www.abload.de/img/unbenannt1rip1.jpg
Warum werden nur ~3GB RAM als aktiv angezeigt obwohl der SQL Server allein schon 28GB auf der VM verbrät ?
Wie immer - Danke !
am physikalischem (ESX) Host kann es wohl nicht liegen. Der hat 256GB RAM. Die anderen 9 ESX Hosts im Cluster haben auch 256GB RAM. Der besagte SQL Server und drei weitere VMs sind die einzigen, die Reservierungen haben. Die anderen VMs mit Reservierungen sehen soweit gut aus.
Ich glaube ich habe den Übeltäter aber nun gefunden. Der Ressourcenpool für den SQL Server war, warum auch immer fehlerhaft. Ich habe diesen nun gelöscht und neu angelegt. Jetzt läuft der Server auf jeden Fall wesentlich schneller.
Was ich aber trotzdem nicht ganz verstehe ist, dass auf dem SQL Server nun im Taskmanager 28GB RAM für den SQL Server genutzt werden (habe ich so im SQL Server eingestellt) auf dem ESX sieht es aber folgendermaßen aus :
Screenshot :
http://www.abload.de/img/unbenannt1rip1.jpg
Warum werden nur ~3GB RAM als aktiv angezeigt obwohl der SQL Server allein schon 28GB auf der VM verbrät ?
Wie immer - Danke !
Moin,
Resource Pool wäre meine nächste Frage gewesen Wenn die Hosts eh genug RAM haben, warum arbeitest Du denn überhaupt mit Reservierungen (und Resource Pools)?
Speicher/Perfomance-tuning von (MS-)SQL ist ein Thema für sich
lg,
Slainte
Resource Pool wäre meine nächste Frage gewesen
Wenn die Hosts eh genug RAM haben, warum arbeitest Du denn überhaupt mit Reservierungen (und Resource Pools)?Warum werden nur ~3GB RAM als aktiv angezeigt obwohl der SQL Server allein schon 28GB auf der VM verbrät ?
Die "aktiven" 3GB beziehen sich auf den Speicher in dem auch wirklich Bewegung stattfindet. Die 28GB hat sich zwar der SQL reserviet, er benötigt davon anscheinend nur 3GB z.Zt. Wie groß ist/sind denn die DB(s) auf dem SQL?Speicher/Perfomance-tuning von (MS-)SQL ist ein Thema für sich
lg,
Slainte
Moin,
gute Frage Wir haben die VMWare Umgebung gerade erst weiter ausgebaut weil in naher Zukunft noch eine ganze Menge Maschinen darauf abgebildet werden. Daher haben wir schon mal damit begonnen Ressourcenpools anzulegen weil jeden Tag circa 30VMs dazukommen.
Also momentan läuft eine Abfrage mit circa 1 Million Datensätzen. Da sollte der SQL doch wesentlich mehr RAM beziehen müssen oder ? Die DB ist aktuell 250GB groß.
Das Ganze ist ein selbstprogrammiertes Datawarehouse. Vielleicht sollte ich mal dem "Hersteller" auf die Zähne fühlen.
Ohja - ich bin im MSSQL auch leider absoluter Laie
gute Frage
Wir haben die VMWare Umgebung gerade erst weiter ausgebaut weil in naher Zukunft noch eine ganze Menge Maschinen darauf abgebildet werden. Daher haben wir schon mal damit begonnen Ressourcenpools anzulegen weil jeden Tag circa 30VMs dazukommen.Also momentan läuft eine Abfrage mit circa 1 Million Datensätzen. Da sollte der SQL doch wesentlich mehr RAM beziehen müssen oder ? Die DB ist aktuell 250GB groß.
Das Ganze ist ein selbstprogrammiertes Datawarehouse. Vielleicht sollte ich mal dem "Hersteller" auf die Zähne fühlen.
Ohja - ich bin im MSSQL auch leider absoluter Laie
