7
Bedeutung der Auslagerungsdatei für den MS SQL Server
Hallo zusammen,
in einem Datenbankserver (virtualisierter Windows Server 2016 mit SQL 2014 STD) liegen die DB Dateien (. MDF und .LDF) sowie Transaktionslogs für die ERP-Datenbank selber und die Temp-DB in einem recht schnellen Storage.
2 weitere Partitionen (Betriebssystem und DB Backups) liegen in einem etwas langsameren Speicher. Dadurch liegt auch die Pagefile.sys dort.
Hat jemand Erfahrungen, wie bedeutend die pagefile.sys für die Performance des SQL Servers ist?
Ohne es begründen zu können, würde ich sagen Speicherort der DB Files und der Arbeitsspeicher haben einen viel größeren Stellenwert als die Auslagerungsdatei.
Aber ist das wohl wirklich so?
Gruß
Christoph
in einem Datenbankserver (virtualisierter Windows Server 2016 mit SQL 2014 STD) liegen die DB Dateien (. MDF und .LDF) sowie Transaktionslogs für die ERP-Datenbank selber und die Temp-DB in einem recht schnellen Storage.
2 weitere Partitionen (Betriebssystem und DB Backups) liegen in einem etwas langsameren Speicher. Dadurch liegt auch die Pagefile.sys dort.
Hat jemand Erfahrungen, wie bedeutend die pagefile.sys für die Performance des SQL Servers ist?
Ohne es begründen zu können, würde ich sagen Speicherort der DB Files und der Arbeitsspeicher haben einen viel größeren Stellenwert als die Auslagerungsdatei.
Aber ist das wohl wirklich so?
Gruß
Christoph
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: 501546
Url: https://administrator.de/contentid/501546
Ausgedruckt am: 13.11.2024 um 08:11 Uhr
7 Kommentare
Neuester Kommentar
Moin,
Ist genug RAM vorhanden kann die Auslagerungsdatei bedenkenlos auf langsamen Speichern liegen.
Gruß
Zitat von @christophh:
Ohne es begründen zu können, würde ich sagen Speicherort der DB Files und der Arbeitsspeicher haben einen viel größeren Stellenwert als die Auslagerungsdatei.
um das beurteilen zu können, muss man erst einmal wissen, ob die Datei auch genutzt wird. Bei zu wenig RAM wird die Auslagerung permanent genutzt - und da ist es natürlich von Vorteil, wenn der Speicherort schnell liefern kann.Ohne es begründen zu können, würde ich sagen Speicherort der DB Files und der Arbeitsspeicher haben einen viel größeren Stellenwert als die Auslagerungsdatei.
Ist genug RAM vorhanden kann die Auslagerungsdatei bedenkenlos auf langsamen Speichern liegen.
Gruß
Moin,
Das gilt nicht nur für DB-Server: Man sollte Server so mit RAM ausstatten, dass die Auslagerungsdatei nie benutzt wird. Wird sie benutzt, dann wird es in der Regel sehr langsam. Wird sie regelmäßig benutzt, dann stattet man den Server mit mehr RAM aus. Insofern spielt die Auslagerungsdatei bei Servern keine große Rolle. Dennoch würde ich sie immer auf ein möglichst schnelles Store legen, damit, falls sie benutzt werden sollte, es wenigstens möglichst schnell geht.
hth
Erik
Zitat von @christophh:
Hat jemand Erfahrungen, wie bedeutend die pagefile.sys für die Performance des SQL Servers ist?
Ohne es begründen zu können, würde ich sagen Speicherort der DB Files und der Arbeitsspeicher haben einen viel größeren Stellenwert als die Auslagerungsdatei.
Aber ist das wohl wirklich so?
Hat jemand Erfahrungen, wie bedeutend die pagefile.sys für die Performance des SQL Servers ist?
Ohne es begründen zu können, würde ich sagen Speicherort der DB Files und der Arbeitsspeicher haben einen viel größeren Stellenwert als die Auslagerungsdatei.
Aber ist das wohl wirklich so?
Das gilt nicht nur für DB-Server: Man sollte Server so mit RAM ausstatten, dass die Auslagerungsdatei nie benutzt wird. Wird sie benutzt, dann wird es in der Regel sehr langsam. Wird sie regelmäßig benutzt, dann stattet man den Server mit mehr RAM aus. Insofern spielt die Auslagerungsdatei bei Servern keine große Rolle. Dennoch würde ich sie immer auf ein möglichst schnelles Store legen, damit, falls sie benutzt werden sollte, es wenigstens möglichst schnell geht.
hth
Erik
Mit der Beurteilung ob es im Moment "genug" RAM is, tue ich mich recht schwer.
Die Datenbank hat ca 90GB, dem Betriebssytem stehen 72GB RAM zur Verfügung, die SQL Instanz "darf" sich davon 64GB nehmen.
Nach einem Server Neustart nimmt die SQL Instanz sich nach und nach den RAM, bis es nach etwa 5-6 Tagen bei den 64GB ankommt.
Die Größe Auslagerungsdatei wird bisher mit den Standard-Einstellungen betrieben, und hat im Moment 10GB.
Die Datenbank hat ca 90GB, dem Betriebssytem stehen 72GB RAM zur Verfügung, die SQL Instanz "darf" sich davon 64GB nehmen.
Nach einem Server Neustart nimmt die SQL Instanz sich nach und nach den RAM, bis es nach etwa 5-6 Tagen bei den 64GB ankommt.
Die Größe Auslagerungsdatei wird bisher mit den Standard-Einstellungen betrieben, und hat im Moment 10GB.
Zitat von @christophh:
Mit der Beurteilung ob es im Moment "genug" RAM is, tue ich mich recht schwer.
Mit der Beurteilung ob es im Moment "genug" RAM is, tue ich mich recht schwer.
Faustregel: Genug ist, wenn im Normalbetrieb ca. 50% RAM frei sind. Wenn er das RAM, das zur Verfügung steht, vollständig nutzt, dann ist es nicht genug.
Gibt es Performance-Counter, wie viel so mit der Auslagerungsdatei gemacht wird?
Wenn ich mal einen Moment auf die Datenträgeraktivität ( über den Ressourcenmonitor) schaue, sehe ich keine Zugriffe auf die Pagefile.sys.
Ich war der Meinung (allerdings nicht fundiert), ein SQL Server nimmt sich irgendwann immer alles an verfügbarem RAM , falls möglich sogar über die DB Größe hinaus?
Wenn ich mal einen Moment auf die Datenträgeraktivität ( über den Ressourcenmonitor) schaue, sehe ich keine Zugriffe auf die Pagefile.sys.
Ich war der Meinung (allerdings nicht fundiert), ein SQL Server nimmt sich irgendwann immer alles an verfügbarem RAM , falls möglich sogar über die DB Größe hinaus?
Moin,
Das stimmt soweit. Nicht nur der MSSQL greift sich allen verfügbaren Speicher auf Vorrat, um schneller reagieren zu können. So muss der Arbeitsspeicher nicht alloziert werden, wenn er ihn braucht. Die Frage ist, ob er ihn auch benutzt. Wenn Du wissen willst, wieviel von der Auslagerungsdatei benutzt wird, dann hilft die Powershell:
Wie Du siehst, gibt es da zwei Eigenschaften: currentusage und peakusage. Damit kannst Du mit einem kleinen Skript Dir mal in ein Log schreiben lassen, wieviel tatsächlich genutzt wird.
<edit>Zur Konfiguration, wieviel sich der Server greifen darf, guckst Du hier: https://www.sqlxpert.de/grundeinstellungen-sql-server-performance-tuning ... </edit>
hth
Erik
Zitat von @christophh:
Gibt es Performance-Counter, wie viel so mit der Auslagerungsdatei gemacht wird?
Wenn ich mal einen Moment auf die Datenträgeraktivität ( über den Ressourcenmonitor) schaue, sehe ich keine Zugriffe auf die Pagefile.sys.
Ich war der Meinung (allerdings nicht fundiert), ein SQL Server nimmt sich irgendwann immer alles an verfügbarem RAM , falls möglich sogar über die DB Größe hinaus?
Gibt es Performance-Counter, wie viel so mit der Auslagerungsdatei gemacht wird?
Wenn ich mal einen Moment auf die Datenträgeraktivität ( über den Ressourcenmonitor) schaue, sehe ich keine Zugriffe auf die Pagefile.sys.
Ich war der Meinung (allerdings nicht fundiert), ein SQL Server nimmt sich irgendwann immer alles an verfügbarem RAM , falls möglich sogar über die DB Größe hinaus?
Das stimmt soweit. Nicht nur der MSSQL greift sich allen verfügbaren Speicher auf Vorrat, um schneller reagieren zu können. So muss der Arbeitsspeicher nicht alloziert werden, wenn er ihn braucht. Die Frage ist, ob er ihn auch benutzt. Wenn Du wissen willst, wieviel von der Auslagerungsdatei benutzt wird, dann hilft die Powershell:
Get-CimInstance -Class Win32_PageFileUsage | select *Wie Du siehst, gibt es da zwei Eigenschaften: currentusage und peakusage. Damit kannst Du mit einem kleinen Skript Dir mal in ein Log schreiben lassen, wieviel tatsächlich genutzt wird.
<edit>Zur Konfiguration, wieviel sich der Server greifen darf, guckst Du hier: https://www.sqlxpert.de/grundeinstellungen-sql-server-performance-tuning ... </edit>
hth
Erik
Microsoft SQL Server Produkte lagern keinen Arbeitsspeicher aus. O-Ton eines MS-Consultants, der es definitiv wissen muß. Ich hatte vor 3 WOchen nämlich die Gelegenheit, mal einen echten MS-Mitarbeiter bei einem Kunden zu treffen.
Wer allerdigns auf die irre Idee kommt, auf nem SQL Server noch andere Sachen mitlaufen zu lassen, der wird dann erleben daß das verbleibende kleine bißchen an Arbeitsspeicher nicht mehr ausreichen wird, da der SQL SErver a) lock pages in memory macht damit das OS die nicht pagen kann und b) Speicher freiwillig nur beim Herunterfahrend es Dienstes freigibt.
Ferner:
Er nimmt sich ansonsten den Speicher, der in dem Servereinstellungen konfiguriert ist, aber die Standardeintellung ist 0 und max steht auf 2 Exabyte, was dann bedeutet daß die Maxmalauslastung jeglichen physischen Speicher umfaßt den das Betriebsysten nicht selber braucht. Und nur bei mehreren Instanzen trägt man dort denselben Wert für Start und Maxmimum ein... der SQL Server lagert im Übrigen seine Daten in der TEMPDB aus, und sollte es zu einer intensiven Nutzung der TempDB kommen dann gehört die auf nen eigene NVME Datenträger im Server.
Wer allerdigns auf die irre Idee kommt, auf nem SQL Server noch andere Sachen mitlaufen zu lassen, der wird dann erleben daß das verbleibende kleine bißchen an Arbeitsspeicher nicht mehr ausreichen wird, da der SQL SErver a) lock pages in memory macht damit das OS die nicht pagen kann und b) Speicher freiwillig nur beim Herunterfahrend es Dienstes freigibt.
Ferner:
Er nimmt sich ansonsten den Speicher, der in dem Servereinstellungen konfiguriert ist, aber die Standardeintellung ist 0 und max steht auf 2 Exabyte, was dann bedeutet daß die Maxmalauslastung jeglichen physischen Speicher umfaßt den das Betriebsysten nicht selber braucht. Und nur bei mehreren Instanzen trägt man dort denselben Wert für Start und Maxmimum ein... der SQL Server lagert im Übrigen seine Daten in der TEMPDB aus, und sollte es zu einer intensiven Nutzung der TempDB kommen dann gehört die auf nen eigene NVME Datenträger im Server.
