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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 193323
Url: https://administrator.de/forum/speicherauslastung-99prozent-obwohl-genug-ram-vorhanden-193323.html
Ausgedruckt am: 22.12.2024 um 09:12 Uhr
11 Kommentare
Neuester Kommentar
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
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,
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