SSAS: Prozessor kaufen für die "Formula Engine"

Question

Win2008 R2, SQL-Server 2008 R2

Hallo!

Wir versuchen die Performance unserer MDX - Abfragen zu verbessern, dh. die "Formula Engine" läuft relativ lange, gefühlsmässig zu lange für das Ergebnis. Die Gründe dafür sind allerdings bekannt, verschiedene Massnahmen aus dem Performance Guide und anderen Quellen sind schon umgesetzt, einige aber auch noch nicht. Auch das Design der Cubes trägt seinen Teil bei, leider hat aber niemand etwas von einem schnellen Würfel, der Ergebnisse liefert, die keiner gebrauchen kann...

Als Alternative zu monatelangen Programmierversuchen möchte ich nun das Problem der "Formula Engine" mit einem eigenen Server mit einer schnellen CPU zu "erschlagen". Die Frage ist nur, welche CPU das sein könnte, denn es gibt nur noch CPUs mit unzähligen Kernen, während die "Formula Engine" (msmdsrv.exe) nur einen verwenden kann (bitte nicht festnageln, das ist nur Halbwissen). Ich teste mit einer relativ einfachen Abfrage, nur Kombiantionen von Dimensionen (ohne eigene Berechnungen, Filter, Sortierung...).

Kann mir jemand eine CPU empfehlen bzw. etwas zu der mir vom EDV-Dienstleister angebotenen etwas sagen, das wäre: http://www.cpubenchmark.net/cpu_lookup.php?cpu=Intel+Xeon+X5680+%40+3.33GHz. Der Preis wäre bei ca. 3.000 EUR Listenpreis für einen Rackserver, viel mehr sollte es nicht werden.

Die ganzen CPU Kennzahlen sind ja gut gemeint, aber welche CPU ist gut für die Formula Engine geeignet? Ich würde nur gerne vermeiden, einen "schnellen" Server zu kaufen, der dann wieder nur einen Bruchteil der CPU für seine wichtigste Aufgabe nutzen kann.

Getestet habe ich folgende Systeme:

Produktivsystem: Intel Xeon E5620 @ 2.40GHz, Laufzeit Testabfrage 52 sec
Testsystem: Intel Xeon E5440 @ 2.83GHz, Laufzeit 32 sec

Angeboten: Intel Xeon X5680@2.33, Laufzeit??? Viele Grüsse arno

Answer 1

Hallo Arno,

auch wenn Intel die Menschheit über Jahrzehnte damit geimpft hat, das mehr GHZ besser sind,
ist das in einem Großteil der Fälle schlicht und einfach nicht richtig, schon gar nicht für Server Anwendungen.

Bei größeren Datenmengen - zu denen Du jetzt gar nichts gesagt hast - haben andere Faktoren
wie die I/O Leistung und Anbindung derselben ein großes Gewicht.
"Pseudo-Benchmarks" wie der Passmark haben keine Aussagekraft, da wäre ein TPC werthaltiger
(und jetzt nicht über die Preise dort erschüttert sein ;-)

Summa Summarum wirst Du ein abgerundetes Paket brauchen.

Und wenn Du monatelange Programmierversuche vermeiden möchtest, so engagiere jemanden,
der sich damit auskennt - mehr will ich jetzt dazu nicht sagen.

Gruß Elmar

Answer 2

Hallo Arno,

ich habe mehrere Cubes am Laufen, u.a. einen mit 3 GB und einen mit 34 GB Größe auf der Platte, und das auf einem 6 Jahre altem 32 Bit System. Wenn ich gegen die "einfache" Abfragen fahre, wird dabei die CPU (Dual Core) eher mäßig belastet. Ebenso würde ich nicht sagen, das immer nur ein Core genutzt wird, das verteilt sich schon über die vorhandenen; hängt halt auch davon ab, wie gut SSAS die Abfrage parallelisieren kann.

Wie Elmar finde auch ich, das die CPU nicht so ausschlaggebend ist, vielmehr die I/O Performance und wieviel RAM zur Verfügung steht; SSAS ist nun mal Speicher-hungrig.

Was für die Cube Abfrage Performanz aber ebenfalls sehr wichtig ist, ist das Cube + Aggregation Design und die Abfragen selbst, denn da kann man viel falsch machen, was sich negativ auf die Performanz auswirkt. MDX Studio gibt einem z.B. gute Hinweise, was als Abfrage eher inperformant ist; leider wird das Tool nicht mehr gepflegt.
Allein das Entwerfen eines guten Aggregation Designs ist schon so eine Kunst für sich.

Die Performance Guides von MS CAT Team kennst Du ja scheinbar schon, aber ist gibt noch andere, z.B. von Chris Webb Query Performance Tuning in Microsoft Analysis Services: Part 1; alleine die Länge des Artikels lässt schon erahnen, das es beim Design viel zu beachten gibt.

---

Olaf Helper
* cogito ergo sum * errare humanum est * quote erat demonstrandum *
Wenn ich denke, ist das ein Fehler und das beweise ich täglich
Blog Xing

Answer 3

Hallo Elmar und Olaf,

danke für die Antworten und Links! Ich frage ja gerade, weil mein Testsystem lt. den Benchmarks langsamer als mein Produktivsystem sein sollte, beim Test aber um 40% schneller ist. Da absolut nichts gegen die Anschaffung eines Servers spricht, reduziert sich daher meine Frage auf: Welche CPU hätte die Formula Engine gerne, bzw. von welcher hat sie garantiert nichts? (Momentan ist der SQL-Server nur virtuell auf einem SBS und sollte umziehen.)

Dass von den Programmierern her auch an dem Problem gearbeitet wird ist klar. Nur kann ich micht nicht darauf verlassen, dass dabei etwas rauskommt. Ich bin schliesslich kein Programmierer sondern Pessimist ;)

lg
arno

Answer 4

Welche CPU hätte die Formula Engine gerne, bzw. von welcher hat sie garantiert nichts?

Hallo Arno,

lakonisch formuliert: Die FE hätte gerne eine funktionsfähige CPU und hätte garantiert nichts von einer defekten CPU.

Es gibt keine speziell für SSAS entworfene CPU, nimm einfach einen handelsüblichen Server der Mittelklasse mit ordentlich RAM und einem guten I/O Subsystem; nach anderen Maßstäben kaufen wir auch nicht ein.

---

Olaf Helper
* cogito ergo sum * errare humanum est * quote erat demonstrandum *
Wenn ich denke, ist das ein Fehler und das beweise ich täglich
Blog Xing

Answer 5

achso, ein handelsüblicher tripple sockel mit obenliegender kühlung der hypercores tut's also auch :))

Danke allen nochmal,
arno

Answer 6

weil mein Testsystem lt. den Benchmarks langsamer als mein Produktivsystem sein sollte, beim Test aber um 40% schneller ist. 

Und um darauf auch noch "vermutent" zu antwort: Auf dem Produktivsystem wird wohl auch produktiv gearbeitet und das mit unterschiedlichen Abfragen; auf dem Testsystem wohl eher nur Du und vielleicht ein paar andere Entwickler und das mit immer gleichartigen Abfragen, da ist die Wahrscheinlichkeit eines Cache Hits viel größer, sprich das (Teil-) Ergebnisse häufiger schon im Cache vorliegen und nicht neu ermittelt werden müssen.

Und von daher der nächste Optimierungstipp, wieder von Chris Webb: Building a Better Cache-Warmer, Part 2: The Formula Engine Cache

---

Olaf Helper
* cogito ergo sum * errare humanum est * quote erat demonstrandum *
Wenn ich denke, ist das ein Fehler und das beweise ich täglich
Blog Xing

Answer 7

Hallo Arno,

so falsch liegst Du da gar nicht ;-)

Denn viele typische Cube Operationen sind typischerweise nicht mal besonders rechenintensiv.
Das Filtern von Daten ist seitens der CPU eine einfache Operation, da kommt es nur auf das Reinschaufeln der Daten an -
und auch wenn die GHZ steigen, so ändert sich Anbindung innerhalb einer Prozessorgeneration nur wenig.

Hilfreich kann (manchmal) ein großer Second-Level Cache sein, aber der hat seine Grenzen
und darauf hängt es nur noch am Speicher-Bussystem.
Geht der RAM-Speicher aus, kommt die Plattensubsystem  an die Reihe - beim Erstlauf sowieso.

Diese (oberflächliche) Beschreibung sollte verdeutlichen, dass es auf das Gesamtsystem ankommt.
Eine High-End-CPU in einer Klapperkiste bringt da überhaupt nichts,
auch das Fahrwerk muss die Leistung auf die Straße bringen.

Gruß Elmar