Mehr CPU-Kerne im Vergleich zu schnelleren Festplatten

Ich bin Teil einer kleinen Firma, die wie immer verschiedene Rollen innehat. Die neueste davon ist die Anschaffung einer dedizierten SQL Server-Box für unsere .NET-Web-App. Wir wurden mit einer Dual-Xeon E5-2620-CPU (6 Kerne) mit 2,00 GHz (insgesamt 12 Kerne) und 32 GB RAM bewertet. Aus diesem Grund haben wir ein begrenztes Budget für das Festplatten-Array, das im Wesentlichen aus zwei 2,5-Zoll-SAS-Laufwerken mit 300 GB (15 KB U / min) in einer RAID-1-Konfiguration besteht.

Ich weiß, dass das Festplatten-Setup für SQL Server nicht optimal ist, und ich würde wirklich gerne auf RAID 10 pushen, damit wir die Datenbank, Protokolldateien und Tempdb auf ihre eigenen Laufwerke stellen können. Sollte ich in Betracht ziehen, die Anzahl der CPU-Kerne zu reduzieren, um dies mit unserem Budget in Einklang zu bringen? oder würde ich eine bessere Bank für Geld bekommen, um die Kerne zu behalten und weniger Laufwerke zu verwenden, vielleicht 4 in einem dualen RAID 1-Setup?

Hier sind einige zusätzliche Statistiken

• Die SQL Server-Datenbank ist in Richtung einer hohen Anzahl von Lese- und Schreibvorgängen geneigt, wahrscheinlich 80% gegenüber 20%. Die aktuelle Größe der Datenbank beträgt derzeit etwa 10 GB, 26 GB, was einer monatlichen Wachstumsrate von 250 MB entspricht.

• Wird derzeit unter SQL Server 2008 R2 Standard auf einer einzelnen Quad-Core-Xeon-Box ausgeführt, die gemeinsam mit dem Webserver genutzt wird (12 GB RAM, 2 x 10 k 300 GB SAS-Laufwerke in RAID 1) und versucht, auf SQL Server 2012 Standard umzusteigen.

• Die Datenbank bedient ca. 100-150 gleichzeitige Benutzer mit einigen im Hintergrund ausgeführten Planungsaufgaben. Wenn ich das lese, denke ich, dass 12 Kerne ein schwerwiegender Overkill sind!

Ich habe die gesamte Anwendung für einen Azure-Clouddienst (2 kleine Instanzen) bereitgestellt, der mit einer SQL Azure-Datenbank verbunden ist. Obwohl die Leistung beim Testen angemessen war (fast keine Last), verlor ich den Mut, sie in der Produktion einzusetzen, weil ich so viel über Unvorhersehbarkeit gelesen hatte. Es funktioniert vielleicht besser mit einem Scale-Out-Ansatz, aber mit nur einer 10-GB-Datenbank kann ich wahrscheinlich sofort mit dem Skalieren davonkommen und etwas Geld sparen.

Anfangs habe ich die Lizenzkosten übersehen und nicht bemerkt, dass die SQL Server 2012-Lizenzierung auf der Anzahl der Kerne basiert. Ich besitze ein BizSpark MSDN-Abonnement mit einer SQL Server 2012-Standardlizenz, daher muss ich nachlesen, wie viele Kerne dies ohne Vorankündigung verwenden würde.

Wenn man von bescheidenen Erfahrungen spricht, von denen ich glaube, dass sie es wert sind, geteilt zu werden, besteht der größte Engpass bei SQL-Datenbanken (hier Sybase und SQL Server) in der Speicherung.

Aber ich finde es nur fair, dass jemand zuerst sein Setup bewertet, bevor er falsche Annahmen trifft. In meinem Fall war die CPU-Auslastung noch nie so hoch, dass eine baldige Aktualisierung der CPU gerechtfertigt wäre. Stattdessen habe ich ein Upgrade von einem einzelnen Laufwerk auf RAID 1 und dann auf RAID 10 + eine Erhöhung von 8 GB auf 16 GB RAM durchgeführt.

All diese RAID-Upgrades haben dazu beigetragen, die vorherigen Wartezeiten um den Faktor 2 bis 6 zu verkürzen. Ich vermute, dass ein Upgrade auf SSDs noch besser wäre. Wenn Sie darüber nachdenken, kann alles auf (theoretische) Bandbreite reduziert werden. Ihre Kombination aus [(RAM-Geschwindigkeit + RAM-Größe + Speichercontroller) und CPU] hat eine Bandbreitenbeschränkung. Dies ist der wichtigste Faktor bei Lesevorgängen, wenn Ihre Daten immer zwischengespeichert werden sollen. Ihr bestimmter (RAID-) Speicher hat eine Bandbreitenbeschränkung. Beeinflusst Lesevorgänge bei fehlendem Cache und Schreibvorgänge beim Leeren oder wenn viele Clients viele Daten zusammen schreiben.

Normalisieren Sie alle diese Grenzwerte so weit wie möglich (bringen Sie sie näher, damit Sie keine verschwendeten Ressourcen haben) und erhöhen Sie sie so weit wie möglich (aktualisieren Sie sie bei Bedarf und lassen Sie Ressourcen nicht verschwenden, wenn das System gewinnt). ' Sie können sie nicht verwenden, da ein anderer Engpass im Weg ist. Am Ende ist Ihr schlimmster Engpass das Server-Subsystem mit der geringsten Leistung (mit der geringsten Bandbreite) in Ihrer speziellen Konfiguration.

Ich kann auch hinzufügen, dass ich während des Upgrades separate RAID-Konfigurationen für die Datenbankdateien und die Datenbankprotokolldateien erstellt habe. Der Grund war, dass Datenbankprotokolldateien in der Regel schreibintensiv sind. Eine Protokolldatei wird verwendet, um eine Datenbank nach einem Absturz wiederherzustellen. Sie wird immer sofort geschrieben, wenn eine Transaktion festgeschrieben wird, bevor Daten in die Datenbankdatei geschrieben werden.

Eine Protokolldatei wird auch von einigen Datenbankreplikationsservern verwendet. Die meisten Replikationen werden jedoch nicht sofort, sondern häufig durchgeführt, sodass die Auswirkungen auf die Leseleistung hier minimal sind. Zumindest glaube ich das. Während dieses Upgrades wurde nur ein minimales Benchmarking durchgeführt. Daher empfehle ich jedem, zuerst die verschiedenen Konfigurationen und zuerst den Speicher, dann den Arbeitsspeicher und die Netzwerkverbindung zu vergleichen, bevor er über ein Upgrade der CPUs nachdenkt.

Nach umfangreicheren Upgrades auf mehr als 5 Servern gab ich meine Erfahrungen weiter. Ich befürworte definitiv immer noch, zuerst den Speicher zu aktualisieren, dann den Arbeitsspeicher und dann die CPU. Grund ist die Ungleichheit der Bandbreiten im System zwischen Speicher, RAM und CPU in der Reihenfolge von niedrigster zu höchster. Also habe ich eine Reihe von Servern von RAID10 und Dual-RAID1 auf SSDs aktualisiert.

Aus Kostengründen (ich muss noch 20 Server aufrüsten) habe ich die Datenbankdaten und Objektdateien auf eine SSD verschoben (ja, nur eine SSD in RAID0) und das Transaktionsprotokoll plus Tempdb auf eine 4xHDD RAID10 Aufbau. Ich habe das Tempdb auch auf der SSD mit tollen Ergebnissen getestet (in der Tat sehr schöne Ergebnisse mit mehr als 15-mal schnelleren Abfragen, die in der Vergangenheit einige Berichte in Sekunden statt Minuten ergaben), aber das Tempdb später auf die Festplatte RAID10 verschoben, weil von intensiven Write-Wear-Bedenken für die SSD.

So, jetzt habe ich im Grunde genommen 10-15 mal schnellere Antwortzeiten für einige der längsten Abfragen beobachtet. Die SSD eignet sich hervorragend zum schnellen Einlesen von Daten in den Arbeitsspeicher, da SQL Server erst dann Daten in den Arbeitsspeicher einliest, wenn sie von der CPU angefordert werden und die Daten zunächst in den Arbeitsspeicher geladen werden müssen (später im L1-, L2-, L3-Cache). Daher helfen SSDs dabei, die anfängliche Wartezeit um einen großen Faktor zu verkürzen. Und SSDs helfen auch dabei, die Auslagerungszeiten zu verkürzen ... RAM zu löschen und neue Daten zu laden, insbesondere wenn Ihre Datenbank größer ist, als in RAM passen kann.

Alles in allem sind wir sehr zufrieden und arbeiten bereits seit einigen Monaten in einem langsamen Migrationsprozess, damit die Server ausgeführt werden können, damit ich Informationen zum Verschleißgrad erfassen kann, bevor ich alle meine Server auf diese Konfiguration umstelle. Und das ist nur SQL Server Express! : D - Stellen Sie einfach sicher, dass Ihre SSDs konstante IOPS liefern können, denn das ist eine andere Sache, die einen großen Unterschied macht (googeln Sie einfach). Aus diesem Grund habe ich mich für SSDs der Intel DC (DataCenter) -Serie entschieden.

Etwas, nach dem Sie im ersten Teil wahrscheinlich nicht suchen, aber: Haben Sie darüber nachgedacht, es in die Cloud zu schieben? Mit AWS können Sie die meisten der oben genannten Anforderungen erfüllen und Ihre Kaufkraft erweitern, ohne sich auch mit der Hardware befassen zu müssen.

Zweiter Teil - Die Hardware hängt wirklich von den Aufgaben ab. Wenn ich in der Lage bin, eine benutzerdefinierte CLR-Integration durchzuführen, tendiere ich eher zu mehr CPUs, da ich dann für wirklich parallele Problemlösungen optimieren kann. Die meiste Zeit finde ich jedoch, wenn es besser ist, setbasierte Lösungen zu haben, dass RAM und Festplattengeschwindigkeit der größte Engpass sind, und der zweite scheint Ihr Fall zu sein. (Wo die SSD Idee oben hilfreich wäre)

Ohne echte Statistiken von Ihrem Server würde ich vorschlagen, dass Sie sich einige Caching-Lösungen ansehen, um die Schreibvorgänge zu verringern (es sei denn, Sie führen eine Art Protokollierung mit den Schreibvorgängen durch oder Dinge, die einen Verlauf benötigen) und viel mehr Geld auf Ihre Festplatten stecken als CPU's. SQL Server ist ziemlich gut darin, Abfragen parallel zu bearbeiten (wenn sie dafür geschrieben wurden), aber wenn Sie viel schreiben müssen, ist Ihre Festplatte der wahre Engpass.