17
Datenbankserver physisch oder virtuell?
Gute Morgen liebe Admins,
Mich würde euer fachlichen Meinung interessieren. Folgendes Szenario:
Aktuell MSSQL Server mit ca. 200GB großer Datenbank, läuft auf einem 5 Jahre altem Blech mit SAS-SSDs RI. Die SQL Datenbank ist aufgrund der schlechten Programmierung und Datenstruktur nicht sonderlich performant. Leider haben wir auf die Datenbank jedoch keinen Einfluss! D.h. wie so oft, miese Software muss durch Hardwareleistung kompensiert werden. Ca. 30 User arbeiten damit.
Nun stellt sich die Frage, ist es rein aus Performancegründen besser wieder einen physischen DB Server mit NVMe hinzustellen oder soll ich mich trauen den Server virtuell auf einem ESX Cluster mit All-Flash (nicht NVMe) Speicher laufen zu lassen.
Das Sizing durch den Hersteller sagte 66k IOPS für die Storage.
Erfahrungsgemäß ist es ja so, selbst wenn ich eine doppelt so schnelle Hardware habe, bedeutet das nicht dass die Anwendung doppelt so schnell läuft. Weiters ist Papier sehr geduldig und die Angegebenen Leistungsdaten sind zwar nett und als Vergleich zwischen Produkten brauchbar aber wie praxistauglich die sind, traue ich mir nicht zu beurteilen.
Die Themen wie Verfügbarkeit, Ausfallszenarien, Wartung, Backup, Lizenzen usw. sind uns bewusst und stehen hier nicht zur Diskussion.
Hat jemand Erfahrungen, oder auch Ideen um die IOPS der aktuellen Hardware zu ermitteln. Oder ist das für den Betrieb einer SQL DB ohnehin eher untergeordnet. Lässt sich eine halbwegs realistische Aussage - ohne Glaskugel - treffen ob der Performancevorteil tatsächlich beim Benutzer ankommt.
Die restlichen Server auf der VMware sind nicht sonderlich Ressourcenintensiv.
Danke und Lg Jonny
Mich würde euer fachlichen Meinung interessieren. Folgendes Szenario:
Aktuell MSSQL Server mit ca. 200GB großer Datenbank, läuft auf einem 5 Jahre altem Blech mit SAS-SSDs RI. Die SQL Datenbank ist aufgrund der schlechten Programmierung und Datenstruktur nicht sonderlich performant. Leider haben wir auf die Datenbank jedoch keinen Einfluss! D.h. wie so oft, miese Software muss durch Hardwareleistung kompensiert werden. Ca. 30 User arbeiten damit.
Nun stellt sich die Frage, ist es rein aus Performancegründen besser wieder einen physischen DB Server mit NVMe hinzustellen oder soll ich mich trauen den Server virtuell auf einem ESX Cluster mit All-Flash (nicht NVMe) Speicher laufen zu lassen.
Das Sizing durch den Hersteller sagte 66k IOPS für die Storage.
Erfahrungsgemäß ist es ja so, selbst wenn ich eine doppelt so schnelle Hardware habe, bedeutet das nicht dass die Anwendung doppelt so schnell läuft. Weiters ist Papier sehr geduldig und die Angegebenen Leistungsdaten sind zwar nett und als Vergleich zwischen Produkten brauchbar aber wie praxistauglich die sind, traue ich mir nicht zu beurteilen.
Die Themen wie Verfügbarkeit, Ausfallszenarien, Wartung, Backup, Lizenzen usw. sind uns bewusst und stehen hier nicht zur Diskussion.
Hat jemand Erfahrungen, oder auch Ideen um die IOPS der aktuellen Hardware zu ermitteln. Oder ist das für den Betrieb einer SQL DB ohnehin eher untergeordnet. Lässt sich eine halbwegs realistische Aussage - ohne Glaskugel - treffen ob der Performancevorteil tatsächlich beim Benutzer ankommt.
Die restlichen Server auf der VMware sind nicht sonderlich Ressourcenintensiv.
Danke und Lg Jonny
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: 81974319630
Url: https://administrator.de/forum/datenbankserver-physisch-oder-virtuell-81974319630.html
Ausgedruckt am: 21.12.2024 um 16:12 Uhr
17 Kommentare
Neuester Kommentar
Hallo,
nun wenn das ganze auf Blech schon lahmt, wird es virtuell nicht schneller, aber virtuell kann man besser Skalieren, sichern, verschieben.
Wenn es etwas in der Richung HANA oder schlimmeres ist, dann hilft nur ein eigenes Rechenzentrum ;)
grüße
nun wenn das ganze auf Blech schon lahmt, wird es virtuell nicht schneller, aber virtuell kann man besser Skalieren, sichern, verschieben.
Wenn es etwas in der Richung HANA oder schlimmeres ist, dann hilft nur ein eigenes Rechenzentrum ;)
grüße
1
Hallo,
ich stand vor 2 Jahren vor einem ähnlichen Problem: neues ERP-System mit SQL-Datenbank.
Mein VMware-Cluster hatte aber "nur" SSD-Cache.
Ich habe mich für "Blech" entschieden (2x Xeon Gold; 192GB RAM; eigenes Laufwerk für Datenbank: NVMe RAID10) Ca. 25 User, davon 10 permanent zeitig.
Performance absolut top, selbst der Hersteller des ERP war bei der Implementierung überrascht.
Jürgen
PS. Die Chefs können also nicht mehr über ein "lahmes" System mosern.
ich stand vor 2 Jahren vor einem ähnlichen Problem: neues ERP-System mit SQL-Datenbank.
Mein VMware-Cluster hatte aber "nur" SSD-Cache.
Ich habe mich für "Blech" entschieden (2x Xeon Gold; 192GB RAM; eigenes Laufwerk für Datenbank: NVMe RAID10) Ca. 25 User, davon 10 permanent zeitig.
Performance absolut top, selbst der Hersteller des ERP war bei der Implementierung überrascht.
Jürgen
PS. Die Chefs können also nicht mehr über ein "lahmes" System mosern.
1
Moin,
aus HA Gründen halte ich ALLES virtuell.
Du wirst du um einen Praxistest nicht rumkommen, ich hatte schon SQLs von HDD auf SSD verschoben, mehr CPU und RAM, das kam beim Endanwender nicht an weil die Software so schlecht programmiert war.
Im anderen Fall hatte ich die Hyper-V Systeme (SQL + Anwendung) auf eine Workstation gelegt, mit ganz anderer Hardware. Man konnte den Performance Sprung sehen und wusste, was die Server haben sollten.
aus HA Gründen halte ich ALLES virtuell.
Du wirst du um einen Praxistest nicht rumkommen, ich hatte schon SQLs von HDD auf SSD verschoben, mehr CPU und RAM, das kam beim Endanwender nicht an weil die Software so schlecht programmiert war.
Im anderen Fall hatte ich die Hyper-V Systeme (SQL + Anwendung) auf eine Workstation gelegt, mit ganz anderer Hardware. Man konnte den Performance Sprung sehen und wusste, was die Server haben sollten.
2
Virtualisierung ist schon ein echter Vorteil in sehr vielen Belangen. Hättest du jetzt z.B. schon einen virtuellen SQL, könntest du diesen einfach auf neue Hardware schieben und testen. Eigentlich will man das nicht missen und nimmt dafür leichte Performance Verluste in Kauf.
Ich weiß jetzt natürlich nicht ob deine Umgebung zu diesem 1% gehört wo wirklich jedes Quantum Performance gefordert wird. Da ihr jetzt aber auf alter Hardware mit einem einzelnen SQL ohne HA Cluster unterwegs seit, kann ich mir das irgendwie nicht vorstellen. In der Liga kenne ich mich nicht aus, ich denke aber das die meisten mit einem virtuellen SQL sehr gut fahren.
Solltet ihr OEM Core Lizenzen ins Auge fassen, da gibt es gravierende Änderungen. Die dürfen nicht virtuell betrieben werden, nur Core Lizenzen mit SA oder OEM Lizenzen auf Server / CAL Basis. Wäre ja sonst auch einfach und ich müsste mich gar nicht ärgern.
Ich weiß jetzt natürlich nicht ob deine Umgebung zu diesem 1% gehört wo wirklich jedes Quantum Performance gefordert wird. Da ihr jetzt aber auf alter Hardware mit einem einzelnen SQL ohne HA Cluster unterwegs seit, kann ich mir das irgendwie nicht vorstellen. In der Liga kenne ich mich nicht aus, ich denke aber das die meisten mit einem virtuellen SQL sehr gut fahren.
Solltet ihr OEM Core Lizenzen ins Auge fassen, da gibt es gravierende Änderungen. Die dürfen nicht virtuell betrieben werden, nur Core Lizenzen mit SA oder OEM Lizenzen auf Server / CAL Basis. Wäre ja sonst auch einfach und ich müsste mich gar nicht ärgern.
Guten Morgen,
Mich würde euer fachlichen Meinung interessieren. Folgendes Szenario:
Aktuell MSSQL Server mit ca. 200GB großer Datenbank, läuft auf einem 5 Jahre altem Blech mit SAS-SSDs RI. Die SQL Datenbank ist aufgrund der schlechten Programmierung und Datenstruktur nicht sonderlich performant. Leider haben wir auf die Datenbank jedoch keinen Einfluss! D.h. wie so oft, miese Software muss durch Hardwareleistung kompensiert werden. Ca. 30 User arbeiten damit.
Was heißt das genau? Kann man evtl. die Anwendung erfahren? Oder zumindest um welches Anwendungsgebiet es sich handelt?
Wo sind die Performanceprobleme? Bitte genauer spezifizieren.
Habt Ihr schon folgende Tests bzgl. der Performanceprobleme durchgeführt?
Ich hatte vor 12 Jahren ein ähnliche Problem, daß die Performance grottig war, trotz absoluter Highendhardware. MS wurde hinzugezogen und konnte nichts fehlerhaftes finden.
Ich hatte damals einen MS SQL Entwickler, welchen ich kontaktieren konnte. Dieser hat sich dann die SQL-Queries genauer angeschaut.
Die Rückfrage daraus ergab,
Gruss Penny.
Mich würde euer fachlichen Meinung interessieren. Folgendes Szenario:
Aktuell MSSQL Server mit ca. 200GB großer Datenbank, läuft auf einem 5 Jahre altem Blech mit SAS-SSDs RI. Die SQL Datenbank ist aufgrund der schlechten Programmierung und Datenstruktur nicht sonderlich performant. Leider haben wir auf die Datenbank jedoch keinen Einfluss! D.h. wie so oft, miese Software muss durch Hardwareleistung kompensiert werden. Ca. 30 User arbeiten damit.
Wo sind die Performanceprobleme? Bitte genauer spezifizieren.
Habt Ihr schon folgende Tests bzgl. der Performanceprobleme durchgeführt?
- SQL DB / Anwendung und Client lokal
- SQL DB / Anwendung auf einem Rechner, Client auf zweitem Rechner. Beide am separaten Switch angeschlossen.
- SQL DB / Anwendung auf einem Rechner, Client auf zweitem Rechner. Beide am gleichen Netzwerkswitch angeschlossen.
- usw.
Ich hatte vor 12 Jahren ein ähnliche Problem, daß die Performance grottig war, trotz absoluter Highendhardware. MS wurde hinzugezogen und konnte nichts fehlerhaftes finden.
Ich hatte damals einen MS SQL Entwickler, welchen ich kontaktieren konnte. Dieser hat sich dann die SQL-Queries genauer angeschaut.
Die Rückfrage daraus ergab,
- Was wollt ihr mit den SQL-Queries erreichen?
- Was soll als Ergebnis geliefert werden?
Nun stellt sich die Frage, ist es rein aus Performancegründen besser wieder einen physischen DB Server mit NVMe hinzustellen oder soll ich mich trauen den Server virtuell auf einem ESX Cluster mit All-Flash (nicht NVMe) Speicher laufen zu lassen.
siehe meine Anmerkungen oben. Wenn die SQL-Queries für die schlechte Performance zuständig sind, nützt das alles nichts.Das Sizing durch den Hersteller sagte 66k IOPS für die Storage.
Ok, vom Storage her ist schonmal Leistung da. Besser geht immer, klaarErfahrungsgemäß ist es ja so, selbst wenn ich eine doppelt so schnelle Hardware habe, bedeutet das nicht dass die Anwendung doppelt so schnell läuft. Weiters ist Papier sehr geduldig und die Angegebenen Leistungsdaten sind zwar nett und als Vergleich zwischen Produkten brauchbar aber wie praxistauglich die sind, traue ich mir nicht zu beurteilen.
Hätte ich unter Umständen auch Schwierigkeiten. Außer man kann Hardware testweise ordern, damit man es testet. Macht aber nicht jeder herstellen.Die Themen wie Verfügbarkeit, Ausfallszenarien, Wartung, Backup, Lizenzen usw. sind uns bewusst und stehen hier nicht zur Diskussion.
Hat jemand Erfahrungen, oder auch Ideen um die IOPS der aktuellen Hardware zu ermitteln. Oder ist das für den Betrieb einer SQL DB ohnehin eher untergeordnet. Lässt sich eine halbwegs realistische Aussage - ohne Glaskugel - treffen ob der Performancevorteil tatsächlich beim Benutzer ankommt.
siehe meine Anmerkungen ganz oben mit den verschiedenen Testszenarien.Hat jemand Erfahrungen, oder auch Ideen um die IOPS der aktuellen Hardware zu ermitteln. Oder ist das für den Betrieb einer SQL DB ohnehin eher untergeordnet. Lässt sich eine halbwegs realistische Aussage - ohne Glaskugel - treffen ob der Performancevorteil tatsächlich beim Benutzer ankommt.
Die restlichen Server auf der VMware sind nicht sonderlich Ressourcenintensiv.
Danke und Lg Jonny
Danke und Lg Jonny
Gruss Penny.
1
Moin,
Meine Erfahrung ist ob Blech oder VM ist egal . Wichtig ist die Technik vom Unterbau.
Aus HA Gründen ist es bei uns auch virtualisiert.
Wäre ich an deiner Stelle würde ich definitiv virtualisieren + NVME . Allein der Unterschied von SAS SSD zu NVME ist schon gewaltig. Dazu DDR5 dann rennt das schon ordentlich.
Meine Erfahrung ist ob Blech oder VM ist egal . Wichtig ist die Technik vom Unterbau.
Aus HA Gründen ist es bei uns auch virtualisiert.
Wäre ich an deiner Stelle würde ich definitiv virtualisieren + NVME . Allein der Unterschied von SAS SSD zu NVME ist schon gewaltig. Dazu DDR5 dann rennt das schon ordentlich.
Moin,
schließe mich hier @Penny.Cilin an:
Wenn die DB inhaltlich nicht rund ist (Queries, fehlende Indizies, ...) kannst du da nen Bugatti Viron hinstellen. Damit wirst du dennoch nicht schneller vom Parkplatz wegkommen.
Bei der Aussage
Vorher macht es ja keinen Sinn, das DBMS auf andere Hardware umzuziehen.
Als Beispiel, was man machen kann:
How to analyze SQL Server database performance using T-SQL
Danach würde ich mir weitere Gedanken um die Hardware machen.
Unabhängige Softwareentwickler teilten mir auch mal mit, dass mdf und ldf nichtauf der selben Partition liegen sollten, selbst, wenn im Unterbau eine VM mit einem potenten SAN werkelt. Ob das noch aktuell ist, weiss ich nicht...
Ansonsten wäre ich auch für eine VM als DB-Server.
In gefühlt 90% der Anwendungsfälle reicht das aus...
schließe mich hier @Penny.Cilin an:
Wenn die DB inhaltlich nicht rund ist (Queries, fehlende Indizies, ...) kannst du da nen Bugatti Viron hinstellen. Damit wirst du dennoch nicht schneller vom Parkplatz wegkommen.
Bei der Aussage
Das Sizing durch den Hersteller sagte 66k IOPS für die Storage.
Gehe ich davon aus, der HErsteller hat bereits die DB analysiert und sämtliche Fehlerquellen behoben.Vorher macht es ja keinen Sinn, das DBMS auf andere Hardware umzuziehen.
Als Beispiel, was man machen kann:
How to analyze SQL Server database performance using T-SQL
Danach würde ich mir weitere Gedanken um die Hardware machen.
Unabhängige Softwareentwickler teilten mir auch mal mit, dass mdf und ldf nichtauf der selben Partition liegen sollten, selbst, wenn im Unterbau eine VM mit einem potenten SAN werkelt. Ob das noch aktuell ist, weiss ich nicht...
Ansonsten wäre ich auch für eine VM als DB-Server.
In gefühlt 90% der Anwendungsfälle reicht das aus...
Ich schließe mich da den - zusammengefassten - Meinungen an ...
Hardwareseitig macht es heute kaum einen Unterschied, ob Blech oder Virtuell - es sollten halt schnelle CPUs und Speicher - => NVMe PCIe4 x4 - und viel RAM sein ...
Frage bleibt primär auch, ob die DB "nur abgefragt" und Auswertungen lokal stattfinden oder die DB via Abfragen und Prozeduren die Berechnungen vornimmt .
Letzteres ist das bessere und sollte mit Indizes und Cache optimiert sein ...
Dein Eingangs-Statement
sollte euch zur Überlegung bringen, inwieweit ein Anbieterwechsel euch langfristig finanzielle und organisatorische Vorteile bringt ...
... ggf. schon, wenn dem bisherigen Programmierer damit die Pistole auf die Brust gesetzt wird ... 🤔
Hardwareseitig macht es heute kaum einen Unterschied, ob Blech oder Virtuell - es sollten halt schnelle CPUs und Speicher - => NVMe PCIe4 x4 - und viel RAM sein ...
Frage bleibt primär auch, ob die DB "nur abgefragt" und Auswertungen lokal stattfinden oder die DB via Abfragen und Prozeduren die Berechnungen vornimmt .
Letzteres ist das bessere und sollte mit Indizes und Cache optimiert sein ...
Dein Eingangs-Statement
Die SQL Datenbank ist aufgrund der schlechten Programmierung und Datenstruktur nicht sonderlich performant. Leider haben wir auf die Datenbank jedoch keinen Einfluss! D.h. wie so oft, miese Software muss durch Hardwareleistung kompensiert werden. Ca. 30 User arbeiten damit.
sollte euch zur Überlegung bringen, inwieweit ein Anbieterwechsel euch langfristig finanzielle und organisatorische Vorteile bringt ...
... ggf. schon, wenn dem bisherigen Programmierer damit die Pistole auf die Brust gesetzt wird ... 🤔
Hallo Jonny,
immer virtuell, da einfach viel viel flexibler mit allem.
66k IOPS scheint mir aber auch eine echt grosse Hausnummer zu sein.
Aber wie auch immer; ich möchte diese nicht hinterfragen.
Wichtig:
Die IOPS braucht es in der Regel NUR auf dem TxLog und TempDB; die DB selbst braucht davon vermutlich nur ein Bruchteil.
Also wenn du für TxLog und TempDB ein anderes Volume (z.B. als Mountpoint) anhängst und dort für genügend IOPS sorgst, sollte alles bestens funktionieren.
Wir betreiben einige SQL Cluster (alles virtuell) und ich verwende immer einen separaten Mountpoint für das TxLog/TempDB. Dies hat auch den Vorteil, dass die Instanz nicht grad komplett stehen bleibt, wenn der Mountpoint mal, aus welchen Gründen auch immer, vollläuft.
Aber ganz wichtig:
Eine gute Überwachung und Wartung der DB ist mindestens genauso wichtig.
Durch einen Top DB Dienstleister kannst du in der Regel einiges an Ressourcen sparen.
Ein Beispiel aus der Vergangenheit.
Ein Laborsystem hatte vor meiner Zeit alle 1-2 Jahre einen neuen Datenbankserver gefordert, um die Performance zu leisten. Nachdem dies ein DB Spezialist angeschaut hat, wurde schnell klar, warum immer eine stärkere Hardware ran musst. Die DB wurde überhaupt nicht und nie gepflegt.
Heute läuft die DB mit zig anderen Applikationen auf einer einzigen Instanz und ich habe nie Beschwerden bezüglich Performance.
Also es liegt trotzdem in deiner Hand. Ein DB Dienstleister kann sich die DB trotzdem anschauen und etwas verbessern, auch wenn dem Applikationsanbieter dies nicht gefällt. Braucht halt ein "sa" Zugang.
Und was Applikationslieferanten oft fordern ist ebenfalls immer in Frage zu stellen.
Vor allem, wenn es um das Thema CPU geht.
Vorsicht in der Virtualisierung vor zu vielen CPU's der VM zuzuweisen.
Mehr vCPU heisst nicht automatisch mehr Performance.
Wenn die CPU nicht wirklich ausgelastet wird, wird es eher langsamer laufen.
Stichwort zu dem Thema wäre die "CPU-Ready Time".
Weniger ist oft mehr.
Also wenn jemand 8 vCPU's fordert, du aber siehst, dass er NIE über 50% ausgelastet ist, dann UNBEDINGT auf 4 vCPU's reduzieren. Die VM wird besser laufen. Wenn es dann mal an die 100% kommt, dann halt auf 6 Core gehen.
Hoffe das hilft dir.
Gruss Roland
immer virtuell, da einfach viel viel flexibler mit allem.
66k IOPS scheint mir aber auch eine echt grosse Hausnummer zu sein.
Aber wie auch immer; ich möchte diese nicht hinterfragen.
Wichtig:
Die IOPS braucht es in der Regel NUR auf dem TxLog und TempDB; die DB selbst braucht davon vermutlich nur ein Bruchteil.
Also wenn du für TxLog und TempDB ein anderes Volume (z.B. als Mountpoint) anhängst und dort für genügend IOPS sorgst, sollte alles bestens funktionieren.
Wir betreiben einige SQL Cluster (alles virtuell) und ich verwende immer einen separaten Mountpoint für das TxLog/TempDB. Dies hat auch den Vorteil, dass die Instanz nicht grad komplett stehen bleibt, wenn der Mountpoint mal, aus welchen Gründen auch immer, vollläuft.
Aber ganz wichtig:
Eine gute Überwachung und Wartung der DB ist mindestens genauso wichtig.
Durch einen Top DB Dienstleister kannst du in der Regel einiges an Ressourcen sparen.
Ein Beispiel aus der Vergangenheit.
Ein Laborsystem hatte vor meiner Zeit alle 1-2 Jahre einen neuen Datenbankserver gefordert, um die Performance zu leisten. Nachdem dies ein DB Spezialist angeschaut hat, wurde schnell klar, warum immer eine stärkere Hardware ran musst. Die DB wurde überhaupt nicht und nie gepflegt.
Heute läuft die DB mit zig anderen Applikationen auf einer einzigen Instanz und ich habe nie Beschwerden bezüglich Performance.
Also es liegt trotzdem in deiner Hand. Ein DB Dienstleister kann sich die DB trotzdem anschauen und etwas verbessern, auch wenn dem Applikationsanbieter dies nicht gefällt. Braucht halt ein "sa" Zugang.
Und was Applikationslieferanten oft fordern ist ebenfalls immer in Frage zu stellen.
Vor allem, wenn es um das Thema CPU geht.
Vorsicht in der Virtualisierung vor zu vielen CPU's der VM zuzuweisen.
Mehr vCPU heisst nicht automatisch mehr Performance.
Wenn die CPU nicht wirklich ausgelastet wird, wird es eher langsamer laufen.
Stichwort zu dem Thema wäre die "CPU-Ready Time".
Weniger ist oft mehr.
Also wenn jemand 8 vCPU's fordert, du aber siehst, dass er NIE über 50% ausgelastet ist, dann UNBEDINGT auf 4 vCPU's reduzieren. Die VM wird besser laufen. Wenn es dann mal an die 100% kommt, dann halt auf 6 Core gehen.
Hoffe das hilft dir.
Gruss Roland
Moin @john-doe,
solche Probleme kenne ich leider auch zu Genüge, jedoch haben diese sehr oft unterschiedliche Gründe, daher ist es alleine durch einen Hardwarewechsel auf schnellere Hardware, nicht wirklich immer sichergestellt, dass du danach auch zufriedenere User hast.
Heutzutage passiert bei einem Hardwarewechsel auf eine neuere/schnellere Hardware, sehr oft sogar das Gegenteil, weil diese per Default, sprich vom Werk aus, zumindest performancetechnisch absolut grottenhaft eingestellt ist. 😔
> Nun stellt sich die Frage, ist es rein aus Performancegründen besser wieder einen physischen DB Server mit NVMe hinzustellen oder soll ich mich trauen den Server virtuell auf einem ESX Cluster mit All-Flash (nicht NVMe) Speicher laufen zu lassen.
Wie gesagt, das kommt ganz darauf an, was bei deinem Szenario wirklich das Problem ist.
Wenn es die Latenz der bisherigen Datenträger ist, kann ein Wechsel auf eine schnellere SSD durchaus etwas bringen.
Aber Vorsicht, nur weil eine SSD ein NVMe Interface hat, bedeutet das noch lange nicht, dass diese auch schneller als eine SAS SSD ist, da muss man schon etwas genauer hinschauen.
Zu deiner eigentlichen Frage. Alle SQL Server unserer Kunden laufen virtuell und haben zum Teil DB's im TB Bereich,
jedoch haben auch alle unserer Kunden schon seit längerem All-Flasch SAN's in Betrieb.
Jedoch musst du auch bei den SAN's sehr genau hinschauen, den auch hier gibt es sehr krasse Leistungsunterschiede.
OK und hat er noch etwas mehr dazu geschrieben/gesagt, wie z.B. die Bockgrösse bei der die 66k IO's erreicht werden müssen oder hat er dir einfach die 66k IO's ohne weiten Angaben um die Ohren gehauen?
Jonny, ganz ehrlich, bevor du dir jetzt neue Hardware besorgst und danach eher mehr Frust hast, sollte man zuerst genau analysieren woher eure Performanceprobleme wirklich kommen!
Es kann gut sein, dass der bisherige SQL einfach zu wenig RAM hat und oder sein RAM Konfiguration schlichtweg suboptimal ist, oder die NIC des SQL Servers suboptimal konfiguriert ist, oder die DB z.B. beschissen indiziert ist, oder eine Virenscanner dazwischen Spuckt oder alles zusammen u.s.w.
Infortrend DS4000U - Meine neue Liebe . . . natürlich nur SAN technisch
😉
Auf gar keinen Fall!
Wenn man genau rausgefunden hat was dein Problem wirklich ist, dann schon.
Diese Woche bin ich vollkommen Land unter, nächste Woche könnte ich mir jedoch mal eine Stunde freikratzen und ein Auge auf dein System werfen.
Gruss Alex
Aktuell MSSQL Server mit ca. 200GB großer Datenbank, läuft auf einem 5 Jahre altem Blech mit SAS-SSDs RI. Die SQL Datenbank ist aufgrund der schlechten Programmierung und Datenstruktur nicht sonderlich performant. Leider haben wir auf die Datenbank jedoch keinen Einfluss! D.h. wie so oft, miese Software muss durch Hardwareleistung kompensiert werden. Ca. 30 User arbeiten damit.
solche Probleme kenne ich leider auch zu Genüge, jedoch haben diese sehr oft unterschiedliche Gründe, daher ist es alleine durch einen Hardwarewechsel auf schnellere Hardware, nicht wirklich immer sichergestellt, dass du danach auch zufriedenere User hast.
Heutzutage passiert bei einem Hardwarewechsel auf eine neuere/schnellere Hardware, sehr oft sogar das Gegenteil, weil diese per Default, sprich vom Werk aus, zumindest performancetechnisch absolut grottenhaft eingestellt ist. 😔
> Nun stellt sich die Frage, ist es rein aus Performancegründen besser wieder einen physischen DB Server mit NVMe hinzustellen oder soll ich mich trauen den Server virtuell auf einem ESX Cluster mit All-Flash (nicht NVMe) Speicher laufen zu lassen.
Wie gesagt, das kommt ganz darauf an, was bei deinem Szenario wirklich das Problem ist.
Wenn es die Latenz der bisherigen Datenträger ist, kann ein Wechsel auf eine schnellere SSD durchaus etwas bringen.
Aber Vorsicht, nur weil eine SSD ein NVMe Interface hat, bedeutet das noch lange nicht, dass diese auch schneller als eine SAS SSD ist, da muss man schon etwas genauer hinschauen.
Zu deiner eigentlichen Frage. Alle SQL Server unserer Kunden laufen virtuell und haben zum Teil DB's im TB Bereich,
jedoch haben auch alle unserer Kunden schon seit längerem All-Flasch SAN's in Betrieb.
Jedoch musst du auch bei den SAN's sehr genau hinschauen, den auch hier gibt es sehr krasse Leistungsunterschiede.
Das Sizing durch den Hersteller sagte 66k IOPS für die Storage.
OK und hat er noch etwas mehr dazu geschrieben/gesagt, wie z.B. die Bockgrösse bei der die 66k IO's erreicht werden müssen oder hat er dir einfach die 66k IO's ohne weiten Angaben um die Ohren gehauen?
Erfahrungsgemäß ist es ja so, selbst wenn ich eine doppelt so schnelle Hardware habe, bedeutet das nicht dass die Anwendung doppelt so schnell läuft. Weiters ist Papier sehr geduldig und die Angegebenen Leistungsdaten sind zwar nett und als Vergleich zwischen Produkten brauchbar aber wie praxistauglich die sind, traue ich mir nicht zu beurteilen.
Jonny, ganz ehrlich, bevor du dir jetzt neue Hardware besorgst und danach eher mehr Frust hast, sollte man zuerst genau analysieren woher eure Performanceprobleme wirklich kommen!
Es kann gut sein, dass der bisherige SQL einfach zu wenig RAM hat und oder sein RAM Konfiguration schlichtweg suboptimal ist, oder die NIC des SQL Servers suboptimal konfiguriert ist, oder die DB z.B. beschissen indiziert ist, oder eine Virenscanner dazwischen Spuckt oder alles zusammen u.s.w.
Hat jemand Erfahrungen, oder auch Ideen um die IOPS der aktuellen Hardware zu ermitteln.
Infortrend DS4000U - Meine neue Liebe . . . natürlich nur SAN technisch
😉
Oder ist das für den Betrieb einer SQL DB ohnehin eher untergeordnet.
Auf gar keinen Fall!
Lässt sich eine halbwegs realistische Aussage - ohne Glaskugel - treffen ob der Performancevorteil tatsächlich beim Benutzer ankommt.
Wenn man genau rausgefunden hat was dein Problem wirklich ist, dann schon.
Diese Woche bin ich vollkommen Land unter, nächste Woche könnte ich mir jedoch mal eine Stunde freikratzen und ein Auge auf dein System werfen.
Gruss Alex
1
Moin @ukulele-7,
das ist das was sich Microsoft gerne wünscht, ob dieser Wunsch jedoch auch den europäischen und oder deutschen Rechten entspricht, wage ich mal gewaltig anzuzweifeln, da es ausser noch mehr Geldabzocke, überhaupt keinen Grund für diese bescheuerte Trennung gibt. 😔
Gruss Alex
Solltet ihr OEM Core Lizenzen ins Auge fassen, da gibt es gravierende Änderungen. Die dürfen nicht virtuell betrieben werden, nur Core Lizenzen mit SA oder OEM Lizenzen auf Server / CAL Basis. Wäre ja sonst auch einfach und ich müsste mich gar nicht ärgern.
das ist das was sich Microsoft gerne wünscht, ob dieser Wunsch jedoch auch den europäischen und oder deutschen Rechten entspricht, wage ich mal gewaltig anzuzweifeln, da es ausser noch mehr Geldabzocke, überhaupt keinen Grund für diese bescheuerte Trennung gibt. 😔
Gruss Alex
Moin,
wir haben die Erfahrung gemacht dass trotz guter Hardware die Software schlecht laufen kann und vor allem oft die Datenbank schuld ist.
Oft sind es Queries die einfach schlecht geschrieben sind und deswegen nicht optimal laufen und oft sind es auch die Indizes die die Performance deutlich verbessert haben.
Hier sind ein paar Tipps und Bestpractices die ihr selbst umsetzen könnt dass die Datenbank schneller wird.
Datenbanken, Logs und TempDB auf verschiedene Volumes und LUNs verteilen. ( je nach Last und Hardware kaum/wenig Zugewinne)
Dynamischen Speicherplatzzuwachs vergrößern, statt ein paar Mbs ein bisschen mehr einstellen ( kann was bringen wenn die Datenbank sich ständig vergrößert)
Max DOP/Parallelität richtig einstellen, gibs von Microsoft ein Guide ( bring auch je nach Query ein wenig was, hier ist aber auch manchmal, weniger ist mehr)
RAM, je mehr desto besser, vor allem wenn die Festplatten nicht so schnell sind. Habe schon beobachtet dass eine Verdopplung von RAM die CPU Last geviertelt hat.
Indizes, ganz ganz wichtig, hier kann ein Index x-fachen Performancezuwachs bringen, Vorsicht bei Softwareupdates, wenn die Software versucht eine Spalte zu löschen wird es fehlschlagen da ein Index drauf ist. Aber ansonsten sind Indizes die wichtigste Stellschraube für die Performance.
Indexdefragmentierung, damit ein Index optimal genutzt werden kann, muss er regelmäßig defragmentiert werden, es gibt ein Sql Script von Ola Hallengren, das benutzen wir z.B. https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.h ...
DPA von Solarwinds ist auch ein richtig gutes Tool was wir einsetzen um unsere DB Performance zu monitoren, er schlägt auch direkt SQL Skripte zum Anlegen von Indizes vor und zeigt auch ineffektive Queries an.
Gruß
wir haben die Erfahrung gemacht dass trotz guter Hardware die Software schlecht laufen kann und vor allem oft die Datenbank schuld ist.
Oft sind es Queries die einfach schlecht geschrieben sind und deswegen nicht optimal laufen und oft sind es auch die Indizes die die Performance deutlich verbessert haben.
Hier sind ein paar Tipps und Bestpractices die ihr selbst umsetzen könnt dass die Datenbank schneller wird.
Datenbanken, Logs und TempDB auf verschiedene Volumes und LUNs verteilen. ( je nach Last und Hardware kaum/wenig Zugewinne)
Dynamischen Speicherplatzzuwachs vergrößern, statt ein paar Mbs ein bisschen mehr einstellen ( kann was bringen wenn die Datenbank sich ständig vergrößert)
Max DOP/Parallelität richtig einstellen, gibs von Microsoft ein Guide ( bring auch je nach Query ein wenig was, hier ist aber auch manchmal, weniger ist mehr)
RAM, je mehr desto besser, vor allem wenn die Festplatten nicht so schnell sind. Habe schon beobachtet dass eine Verdopplung von RAM die CPU Last geviertelt hat.
Indizes, ganz ganz wichtig, hier kann ein Index x-fachen Performancezuwachs bringen, Vorsicht bei Softwareupdates, wenn die Software versucht eine Spalte zu löschen wird es fehlschlagen da ein Index drauf ist. Aber ansonsten sind Indizes die wichtigste Stellschraube für die Performance.
Indexdefragmentierung, damit ein Index optimal genutzt werden kann, muss er regelmäßig defragmentiert werden, es gibt ein Sql Script von Ola Hallengren, das benutzen wir z.B. https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.h ...
DPA von Solarwinds ist auch ein richtig gutes Tool was wir einsetzen um unsere DB Performance zu monitoren, er schlägt auch direkt SQL Skripte zum Anlegen von Indizes vor und zeigt auch ineffektive Queries an.
Gruß
1
Moin canlot,
👍👍👍
Das alles braucht man bei einem MS-SQL => 2016 nicht mehr wirklich, denn die neueren SQL-Server bringen schon einen 1A Performance-Analyzer von Haus aus mit sich, denn gefühlt jedoch so gut wie keiner kennt. 😔
Und zwar heisst die entsprechende Funktion, warum auch immer "Abfragespeicher". 🙃
Weitere Details siehe hier ...
https://learn.microsoft.com/de-de/sql/relational-databases/performance/m ...
Gruss Alex
Indizes, ganz ganz wichtig, hier kann ein Index x-fachen Performancezuwachs bringen, Vorsicht bei Softwareupdates, wenn die Software versucht eine Spalte zu löschen wird es fehlschlagen da ein Index drauf ist. Aber ansonsten sind Indizes die wichtigste Stellschraube für die Performance.
👍👍👍
Indexdefragmentierung, damit ein Index optimal genutzt werden kann, muss er regelmäßig defragmentiert werden, es gibt ein Sql Script von Ola Hallengren, das benutzen wir z.B. https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.h ...
DPA von Solarwinds ist auch ein richtig gutes Tool was wir einsetzen um unsere DB Performance zu monitoren, er schlägt auch direkt SQL Skripte zum Anlegen von Indizes vor und zeigt auch ineffektive Queries an.
DPA von Solarwinds ist auch ein richtig gutes Tool was wir einsetzen um unsere DB Performance zu monitoren, er schlägt auch direkt SQL Skripte zum Anlegen von Indizes vor und zeigt auch ineffektive Queries an.
Das alles braucht man bei einem MS-SQL => 2016 nicht mehr wirklich, denn die neueren SQL-Server bringen schon einen 1A Performance-Analyzer von Haus aus mit sich, denn gefühlt jedoch so gut wie keiner kennt. 😔
Und zwar heisst die entsprechende Funktion, warum auch immer "Abfragespeicher". 🙃
Weitere Details siehe hier ...
https://learn.microsoft.com/de-de/sql/relational-databases/performance/m ...
Gruss Alex
DPA von Solarwinds kann ich ebenfalls empfehlen.
Wir setzen diesen seit vielen Jahren erfolgreich ein.
Darüber ist bisher auch jeder DB Spezialist dankbar gewesen; und auch schon die Entwickler.
Wenn alle Stricke reissen, kann es auch mal hilfreich sein, dem Entwicklerteam der Applikation auf die Füsse zu treten.
Eine "###" programmierte Software (Abfrage) kann ebenfalls jede Hardware in die Kniee zwingen.
Vieles kann der DB Admin regeln, aber eben nicht immer alles. Der Applikation-Anbieter steht da auch etwas in der Pflicht sein bestes zu tun.
Wir setzen diesen seit vielen Jahren erfolgreich ein.
Darüber ist bisher auch jeder DB Spezialist dankbar gewesen; und auch schon die Entwickler.
Wenn alle Stricke reissen, kann es auch mal hilfreich sein, dem Entwicklerteam der Applikation auf die Füsse zu treten.
Eine "###" programmierte Software (Abfrage) kann ebenfalls jede Hardware in die Kniee zwingen.
Vieles kann der DB Admin regeln, aber eben nicht immer alles. Der Applikation-Anbieter steht da auch etwas in der Pflicht sein bestes zu tun.
1
Die Frage ist eher ob der TO überhaupt in der Lage ist die Anwendung zu optimieren (also z.B. die Query zu optimieren) oder ausreichend Einfluss auf den Software Hersteller hat, das er diesen dazu bringen kann, die Performance zu verbessern. Mein Gefühl sagt mir, dem ist eher nicht so. Aber natürlich wäre es gut zu verstehen, wo der Schuh drückt.
Hallo Leute, vielen Dank mal für eure Infos und die Meinungen.
Weil gefragt wurde: Es handelt sich um eine ERP Software - keine Individualprogrammierung. Witziges Detail am Rande. Es gab ein paar meiner nach ziemlich gute SQL Kollegen die im Rahmen der Möglichkeiten die Datenbank optimiert haben und auch ein wenig mehr Power rausholen konnten. (Richtig gut wars trotzdem nicht). Nach 3-4 Jahren wurde dann ein Projekt gemacht um die ganzen Individualprogrammierungen und Anpassungen wieder zurückzubauen um so nahe wie möglich am Standardprodukt zu sein. Kurz gesagt, es wurde nicht besser ;)
Daher ist die Optimierung der DB praktisch nicht möglich, wenns nach mir geht -> weg mit dem Ding. Allerdings sind die Entscheidungsträger auf dem Ohr taub.
Schöne Grüße
Jonny
Weil gefragt wurde: Es handelt sich um eine ERP Software - keine Individualprogrammierung. Witziges Detail am Rande. Es gab ein paar meiner nach ziemlich gute SQL Kollegen die im Rahmen der Möglichkeiten die Datenbank optimiert haben und auch ein wenig mehr Power rausholen konnten. (Richtig gut wars trotzdem nicht). Nach 3-4 Jahren wurde dann ein Projekt gemacht um die ganzen Individualprogrammierungen und Anpassungen wieder zurückzubauen um so nahe wie möglich am Standardprodukt zu sein. Kurz gesagt, es wurde nicht besser ;)
Daher ist die Optimierung der DB praktisch nicht möglich, wenns nach mir geht -> weg mit dem Ding. Allerdings sind die Entscheidungsträger auf dem Ohr taub.
Schöne Grüße
Jonny
Dann stell eine vernünftige neue Hardware dahin und pack eine VM drauf, fertig. Beachte Lizenzhinweise und Hardware Tipps.
