Empfohlene RAM-Größe des Windows-SQL-Servers bei einer Datenbankgesamtgröße von mehr als 1 Terabayte

[Netforward]

Hallo zusammen,
leider habe ich zu diesem Thema bisher noch nichts aussagekräftiges gefunden. Vielleicht könnt Ihr mir hier weiterhelfen...
Wir haben einen neuen SQL-Server 2022 Server und ca. 120 Datenbanken, die zusammen eine Größe von > 1 Terabyte haben. Der neue SQL-Server mit Microsoft Server 2022 als Betriebssystem hat eine RAM-Ausstattung von 128 GB. Da hier natürlich nur der SQL-Server und der MS SQL-Server Management Studio 19 läuft, habe ich für das Betriebssystem 4 GB reserviert, die max. RAM-Speichernutzung für SQL ist somit auf 126.976 MB RAM fest eingestellt.

Mich wundert es natürlich nicht, das die 128 GB schnell ausgeschöpft sind. Meine Frage wäre jetzt, wieviel GB RAM sollte der Server hardwaretechnisch idealerweise besitzen, wenn folgende Merkmale gegeben sind:

• ca. 120 Datenbanken - 1 SQL-Server Instanz
• Gesamtgröße aller Datenbanken > 1 Terabyte
• ca. 1000 Benutzer greifen auf die Datenbanken zu
• Betriebssystem: Windows Server 2022 Standard
• 2 x Intel(R) Xeon(R) Gold 6248 CPUs @ 2.50GHz Prozessoren (insgesamt 40 Kerne)

Freue mich auf qualifizierte Antworten...

 

[MDDaniel]

Grundsätzlich - wenn du den Tisch für SQL reservierst wird er sich auch hinsetzen. Unabhängig davon ob er auch mit weniger auskommen würde.
Mit den Zahlen alleine wird es schwer zu sagen wieviel er wirklich braucht, dass lässt sich allein aufgrund der Parameter so nicht bestimmen. Da wirst du eher auf Systemüberwachung gehen müssen. Gibt es irgendwelche Probleme?

Nur die 4 GB für das BS würde ich in Hinblick auf Backup-, Update- und Wartungsvorgänge größer fassen, ist ja eh soviel da.
Wenn du den Server nur für SQL verwendest kannst du ja den ganzen verfügbaren Speicher nutzten.

Allerdings würde ich mich vor der Denkweise hüten - wenn es nicht läuft ist es immer eine Frage der Ressourcen.
Und deine Frage bringt für mich diesen "Touch" mit.
Eine weitere Überlegung: wenn es wirklich einmal zum Speicherengpass kommt dann hast du keinen Puffer. Wenn du das Problem auftritt stehst du mit dem Rücken an der Wand. Kein Speicher mehr zum Analysieren, Jonglieren und Reagieren - aus diesem Aspekt heraus würde ich dem SQL nicht jeden verfügbaren Platz bereitstellen.

Was mich wundert ist, dass die Datenbanken im Durchschnitt recht klein sein müssen (~ 8 GB und 8 Benutzer).
Welche Edition verwendest du?

Gruß MDD

 

[ukulele]

Ich war noch nicht in der Situation wirklich einem RAM Engpass zu haben und finde leider auch grade keine gute Quelle dazu, daher entspringt das hier jetzt nur meiner Überlegung, nicht meinem Wissen

Grundsätzlich nimmt sich der SQL den RAM der da ist. Braucht er darüber hinaus RAM für eine Aufgabe macht er RAM frei mit Daten die "er länger nicht gebraucht hat" - ich stelle mir das vor wie bei einer Swapfile. Wenn der Server frisch gestartet wird ist der RAM erstmal fast leer. Du könntest beobachten wie lange der Server unter normaler Arbeitslast braucht bis der RAM komplett von ihm vereinnahmt wurde. Erst dann ist der Server in der Situation das er Daten aus dem RAM entfernen muss um andere Daten ablegen zu können.

 

[Dukel]

Grundsätzlich nimmt sich der SQL den RAM der da ist.

Er nimmt sich aber nur soviel wie er braucht.
Wenn nicht mehr benötigt wird, wird nicht der ganze RAM vom SQL Server genutzt.

 

[MDDaniel]

Ich bin mir nicht sicher wie es bei der Version 2022 ist, aber in früheren Versionen hat sich der SQL recht geziert allokierten Speicher wieder frei zu geben.
Jedenfalls ist der Speicherbedarf von viel mehr Parametern abhängig, als das man mit dem genannten eine seriöse Aussage geben kann.
Informationen über Datenbankaufbau, Abfragen, und deren Frequenzen, Einsatzzweck, und und und fehlen sind nichtsdestotrotz essentiell.

 

[Dukel]

RAM wieder freigeben geht nur in der Enterprise Edition.

 

[Netforward]

Vielen Dank schon einmal für die ersten Antworten. Bisher gibt es noch keine Performance-Probleme, da auch noch nicht alle Datenbanken auf den neuen Server umgezogen sind. Bisher habe ich nur ca. 1/6 migriert. Die Datenbanken haben ganz unterschiedliche Größen und auch unterschiedliche Nutzung bezgl. Anzahl der User. Die meisten Datenbanken sind relativ klein, es gibt aber auch eine DB, die alleine schon 650 GB umfasst und eine andere, die auch schon eine Größe von 100 GB hat. Die Datenbanken entwickeln wir nicht selber, sondern sind aufgrund der Fachanwendungen durch den Hersteller vorgegeben. Ich möchte es einfach verhindern, dass die DB-Performance am Ende wieder mittelmäßig bis schlecht läuft. Es wird die SQL Server 2022 Enterprise-Version verwendet...

 

[Dukel]

Man hätte auf dem alten Server den RAM Bedarf der einzelnen Datenbanken ermitteln und damit ein Sizing erstellen können.

650 GB sagt ja nichts über den RAM Bedarf aus. Es kommt auf die Queries an.

 

[MDDaniel]

Wenn du auf die Datenbanken keinen Einfluss hast, kannst du nur mit der Überwachung arbeiten und dem Hersteller/Lieferanten die Daumenschrauben anlegen wenn der Bedarf aus dem Ruder läuft oder ihn besser noch im Vorfeld auf Auffälligkeiten hinweisen.
Ich habe festgestellt das Softwareentwickler oft zu wenig Verständnis von Datenbanken haben und Server in die Knie zwingen. Und mit fehlenden Indexen z.B. reicht die 100 GB Datenbank leicht um deinen Server oder zumindest einzelne Anwendungen ins Trudeln zu bringen.

Man hätte auf dem alten Server den RAM Bedarf der einzelnen Datenbanken ermitteln und damit ein Sizing erstellen können.

650 GB sagt ja nichts über den RAM Bedarf aus. Es kommt auf die Queries an.

Damit hat Dukel auch recht.
Es spricht dennoch nichts dagegen das im Nachhinein zu machen um sich eine Baseline anzulegen.
Allerdings ist das dann schon etwas was ausreichend Wissen, Erfahrung und Zeit benötigt.

Das eine DB performant läuft ist in meinen Augen Aufgabe des Herstellers. Als Bahnfahrer hast auch keinen bedeutenden Einfluss auf den Stromverbrauch des Zuges. Kannst höchstens mit einer anderen Bahn fahren, wenn's überhaupt verfügbar ist.

 

[t-sql]

1. SQL Server Management Studio hat auf einem Server nix verloren. Frisst nur RAM,
2. 4 GB fürs Betriebsystem sind völlig ausreichend,
3. halte ich 128 GB RAM für das Scenario für viel zu wenig, 256 GB sollten es schon sein,
4. mußt du deinen Workload testen um eine belastbare Aussage machen zu können,
5. wie war denn der alte Server ausgestattet (ich nehm mal an es gibt einen alten)?
6. SQL Server gibt Speicher nicht frei wenn der erstmal allokiert ist.

 

[dabadepdu]

Ich habe mit MSSQL Server keine aktuellen Erfahrungen. Ich kann viele Dinge die hier gesagt wurden nur bestätigen. Du kannst keine pauschale Aussage zu Deiner Anforderung erwarten. Bei 1 TB und so vielen DB scheinen viele der DB eher klein zu sein.

Wenn Du Pech hast, arbeitest Du mit einer schlechten Implementierung und musst Dich an die Herstelleranforderungen halten.

Dabei ist natürlich die Frage, wie "hungrig" eine Anwendung ist und welcher Natur sie ist.

Du kannst Terrabyte Altdaten haben, die in 98% der Fälle nicht genutzt werden.
1000 User ist nicht wenig, aber wichtiger ist, wieviel Sessions Du offen hast, je DB. Das kostet wirklich Speicher, nicht viel pro user bzw. session, aber es leppert sich.

Sind es Webanwendungen oder Fat Clients, die die DB nutzen? Ersteres ist wahrscheinlich schonender für den Server.
Sind es komplexe Anwendungen oder simple Systeme?
Ist es viel lesender Zugriff oder viel schreibender?
Datawarehouse oder viele Transaktionen, hängen Produktions-Maschinen dran oder darf es mal ne Sekunde dauern?

Deine Frage ist so ähnlich wie die nach den Anforderungsprofilen für die neue IT Stelle. Am besten natürlich alles von Cobol bis KI, von kaufmännisch bis Management, Teamgeist UND Ehrgeiz, Genderneutral und Alpha Gene, Neugier plus das Bestandswissen der letzten 30 Jahre ..

Dass ein DB Server ein Viertel der DB Größe an RAM Bedarf hat, scheint mir eher ein Worst Case Szenario. Widerspricht für meinen Geschmack dem DB Prinzip. Am Ende des Tages ist ein Großteil des RAM einfach ein Cache für den Kram auf der Platte oder für Sortieren und Zwischenergebnisse und Aggregationen. Weniger RAM bedeutet mehr Plattenzugriffe. Aber wenn der Serverbetrieb bzw. die RAM Anforderungen darauf hinauslaufen, dass fast die komplette DB im RAM liegt, warum dann noch den Kopf zerbrechen? Dann kann man auch gleich die Festplatten weglassen (kleiner Spaß).