sqlklaus
Goto Top

SQL Server Empfehlung für Speicher pro User und Datenbank

Hallo SQL Fachmänner,

ich bin derzeit auf der Suche nach einer sinnvollen Formel zum Errechnen der notwendigen SQL Serverressourcen eines Kunden. Der Server ist leider nicht sehr performant nur benötige ich ein Argument oder sys Abfragen um den Mangel an Ressourcen zu begründen.

Hier die Daten:

Der SQL-Server ist eine VM auf einem größeren ESX.

Die VM selbst hat laut Systemabfrage einen Quad 2.7 GHz Intel Xeon E5 v2 Chip
16 GB Ram
Windows 2008R2 SP1

Um die Lizenzkosten zu minimieren werden in einer SQL-Instanz 105 Kunden-DBs gehostet.

Der Server läuft laut Performance-Auswertung auf 60% CPU-Last und hat sich bei Schleifen-Tests hoch auf 80% bewegt. Im Schnitt werden 10-12GB von 16 GB RAM belegt.


Wieviel Speicher würdet Ihr empfehlen? Kennt jemand einen Leitfaden von Microsoft der sich nicht ausschließlich auf Maxmem und weitere Attribute der Konfig bezieht sondern sagt, wenn du 100 DBs mit einer Größe von 200 - 1GB in einer Instanz betreibst, dann rechne X MB Speicher pro DB bei X Usern.

Danke Euch

Content-Key: 295624

Url: https://administrator.de/contentid/295624

Printed on: April 25, 2024 at 00:04 o'clock

Member: clSchak
clSchak Feb 09, 2016 updated at 21:29:34 (UTC)
Goto Top
Hi

RAM, SQL Server brauchen RAM und um eine Aussage zu treffen benötigt man noch die Daten vom Storage, wie hoch ist der Schreib-/Leseanteil, wie viele Abfragen werden aktuell aus dem RAM bedient (% Angabe), wie viele Waiting-Tasks laufen und wie "groß" sind diese usw usw usw. dann noch die Config, wie gut ist der Index der Datenbanken, sind die Datenbanken optimiert ....

So auf's blaue hinaus kann man keine Aussage treffen, wenn die 100 Datenbanken nur je 100MB groß sind, dann sind das peanuts, wenn die aber >10GB sind wir das schon eine ganz andere Hausnummer und die 16GB RAM sind mehr als Lächerlich face-wink.

Wir haben mit ~ 40 Datenbanken einen Server der 128GB RAM hat und durch Abfrageanteil von 90% der aus dem RAM bedient wird, werden wir den auf auf 256GB hochrüsten, damit reduziert man auch die IO Last auf dem Storage und die Requests laufen schneller durch, aber das ist halt auch auf uns abgestimmt...

Gruß
@clSchak

PS: Ich gehe jetzt mal davon aus, das der SQL Server im Cluster bzw. ein 2. im Hot-Standby läuft bei so vielen Kunden ... wobei das je nach Szenario eine Enterprise Lizenz voraussetzt und das klingt jetzt nicht danach...
Member: sqlklaus
sqlklaus Feb 10, 2016 at 11:32:42 (UTC)
Goto Top
Danke für deine Antwort.

Kannst du die Abfragen benennen, mit denen ich deine Werte aus dem SQL Server ziehen kann? Von einem Cluster wüsste ich übrigens nichts. Das Hosting übernimmt ein RZ, mögliche Konsequenzen liegen also nicht in unserem Verantwortungsbereich. Ich würde nur gerne handfeste Nachweise liefern können. Ich kann dabei leider nicht einmal bewerten, ob 60 Dauerlast für einen SQL Server gut oder schlecht ist.


Die WaitingTask denke ich hiermit "select * from sys.dm_os_waiting_Tasks". Allerdings kann ich der Liste keine sinnvollen Informationen entnehmen bzw. auf wen oder was soll dabei geachtet werden?


Die CPU Leistung habe ich mit dieser Abfrage getestet. Der Kundenserver erzielt dabei eine Laufzeit von 90sek. Unser Server kommt auf 60sek.

DECLARE @loops INT SET @loops = 1
DECLARE @cpu INT SET @cpu = @@CPU_BUSY
DECLARE @startdate DATETIME SET @startdate = GETDATE()

WHILE @loops <= 1000000
BEGIN
IF COALESCE('123', '456') = '456'
PRINT 1
SET @loops = @loops + 1
END

PRINT 'COALESCE, both non-NULL'
PRINT 'Total CPU time: ' + CONVERT(varchar, @@CPU_BUSY - @cpu)
PRINT 'Total milliseconds: ' + CONVERT(varchar, DATEDIFF(ms, @startdate, GETDATE()))
PRINT ''
GO

--==================================================

DECLARE @loops INT SET @loops = 1
DECLARE @cpu INT SET @cpu = @@CPU_BUSY
DECLARE @startdate DATETIME SET @startdate = GETDATE()

WHILE @loops <= 1000000
BEGIN
IF ISNULL('123', '456') = '456'
PRINT 1
SET @loops = @loops + 1
END

PRINT 'ISNULL, both non-NULL'
PRINT 'Total CPU time: ' + CONVERT(varchar, @@CPU_BUSY - @cpu)
PRINT 'Total milliseconds: ' + CONVERT(varchar, DATEDIFF(ms, @startdate, GETDATE()))
PRINT ''
GO


Und die I/O mit dieser hier. Von den Ergebniswerten liegt die I/O bei ca 250K R und W. Verglichen mit unserem hauseigenen SQL mit 400k W und 800k R erscheint mir das bei der Kundenanzahl schon mehr als langsam.

USE TempDB
GO
EXEC sp_helpfile
GO

SELECT files.physical_name, files.name,
stats.num_of_writes, (1.0 * stats.io_stall_write_ms / stats.num_of_writes) AS avg_write_stall_ms,
stats.num_of_reads, (1.0 * stats.io_stall_read_ms / stats.num_of_reads) AS avg_read_stall_ms
FROM sys.dm_io_virtual_file_stats(2, NULL) as stats
INNER JOIN master.sys.master_files AS files
ON stats.database_id = files.database_id
AND stats.file_id = files.file_id
WHERE files.type_desc = 'ROWS'
Member: sawimbulu
sawimbulu Feb 10, 2016 at 20:55:30 (UTC)
Goto Top
Man kann Deine Anfrage nicht unbedingt beantworten.
Es kommt immer drauf an, wie viele Anfragen die Sekunden auf den SQL treffen und dieser die dann bearbeiten muss. Allerdings sind 10-12 GB RAM für ca. 105 DB recht wenig.
Bsp., wir haben eine DB mit 64 GB RAM ausgestattet, um u.a. den I/O zu entschärfen. Dein I/O mit ~250 finde ich recht wenig. Hier würde ich ggfls. ein leistungsstärkeres Storage hinter schalten.

Nichtsdestotrotz, rüste den SQL mit RAM auf. Wichtig ist auch, dass Du dem SQL-Server den RAM fest vergibst !!!
Du wirst dann sicherlich eine Verbesserung spüren.
Member: sqlklaus
sqlklaus Feb 11, 2016 at 11:56:13 (UTC)
Goto Top
Danke für Eure Antworten. Ich glaube ich bin fündig geworden bzw. habe ich eine super Seite gefunden auf der sogar die am häufigsten auftretenden Probleme mit den SQL Attributen näher beschrieben werden.

SQL Server Performance Tuning Using Wait Statistics

Sicherlich ist das noch keine endgültige Lösung für unser Problem aber hier ist genau erklärt, wie die Werte interpretiert werden können. Unserem Kunden haben wir nebenher schon ein Upgrade auf 64GB RAM empfohlen.