Donnerstag Mrz 27, 2014

Ein paar Gedanken zu Single Thread Performance

Eines werde ich immer wieder gefragt: Wie misst man Single Thread Performance ?

So gerne ich auch wollte, die Antwort ist leider nicht so einfach wie die Frage.  Und leider auch ein wenig laenger.

Selbst die Definition von Single Thread Performance ist nicht immer die gleiche, weswegen ich damit anfangen moechte.  In diesem Blog ist Single Thread Performance die Menge an Arbeit die eine Software, die als einzelner Instruktions-Strom ablaeuft, in einer gewissen Zeit erledigt.

Das alles dient natuerlich dazu, die Leistung (schon wieder ein schwammiger Begriff..) eines Computersystems, oder manchmal einer Komponente davon, in Bezug auf die zu erwartende Single Thread Performance zu bewerten.

Genug der Vorrede, was uns jetzt interessiert sind die Moeglichkeiten, Single Thread Performance zu messen und natuerlich zu vergleichen.

Das erste, was einem hierzu einfaellt ist ein kleines Testprogramm.  Irgend etwas, von dem wir wissen dass es single threaded  ist und eine Weile dauert.  Je nachdem, was man im taeglichen Leben so macht, koennte das ein kleines Shell-Skript sein, das von 1 bis 1 Million zaehlt, ein SQL-Loop der Fibonacci-Zahlen berechnet oder ein kleines Programm zur Erzeugung kryptographischer Hashes.  Aber bekommen wir damit, was wir wirklich wollen - ein zuverlaessiges Mass der allgemeinen Single Thread Performance eines Systems?  Immerhin sind die Anforderungen all dieser Micro-Benchmarks sehr unterschiedlich.  Manche bevorzugen grosse Caches um die Memory-Latenz zu verstecken.  Andere brauchen hohen Memory-Durchsatz, wieder andere skalieren einfach mit der CPU-Taktrate.  Wie wuerden wir daher die allgemeine Single Thread Leistung eines Systems fuer diese sehr unterschiedlichen Anforderungen bewerten?  Hier ein Beispiel.  Das Diagram zeigt die Leistung verschiedener Tests einer kleinen Testsuite, die ich auf jedem SPARC-System laufen lasse, das ich in die Finger bekomme.  Was die Tests machen, ist nicht interessant.  Wichtig ist, dass sie alle single threaded laufen und nur CPU-gebunden sind

Folgendes ist dabei wichtig:

  1. Test 1 scheint sehr cache-freundlich zu sein - die 3 CPUs mit Caches groesser als 8MB liegen deutlich vorn.  Auch scheint dieser Test von Cache mehr zu profitieren als von Taktrate, da die 1.8 GHz CPU knapp vor der 2.66 GHz CPU liegt. 
  2. All die anderen Tests skalieren ungefaehr mit der Taktrate, das 3.6 GHz System liegt daher vorn.
  3. Es gibt kein festes Verhaeltnis von Leistung und Taktrate.  In Test 1 liegen alle Ergebnisse sehr nahe beinander, waehrend die Unterschiede in Tests 3 und 4 stark schwanken.

Das alles fuehrt letzten Endes zu der Erkenntnis: Single Thread Performance haengt in erster Linie von der Anwendung und den Daten ab - es gibt keine allein selig machende Antwort.  Das sollte natuerlich keine Ueberraschung sein, letztlich ist das bei jedem Benchmark so.  Bei der Bewertung von Single Thread Performance ist es jedoch besonders wichtig, da hier die Unterschiede besonders stark zu Tage treten.  Ein letzter Blick auf das obige Diagramm:  In Test 1 ist das 2.66 GHz System ca. 1/3 schneller als das 2.85 GHz System, und ungefaehr gleich schnell wie das mit 1.8 GHz.  Gemaess Tests 2 und 3 jedoch ist das 1.8 GHz System deutlich schneller als das 2.66 GHz System, aber alle anderen sind schneller als diese beiden.  Das Problem bei der ganzen Sache ist: Man weiss nie, welchen Fall man mit dem jeweils bevorzugten Testprogramm gerade erwischt.  Egal was man testet, egal wie die Resultate ausfallen, es ist zumindest sehr schwierig, damit Performancevorhersagen zu treffen.

Aber vielleicht helfen ja die "offiziellen" Benchmarks weiter.  Der einzige einigermassen relevante, der sich (noch) mit Single Thread Performance beschaeftigt ist SPECcpu2006.  Der Einfachheit halber beschraenke ich mich in dieser Betrachtung auf CINT2006.  Es gibt zwei Varianten davon, den single threaded SPECint_2006 und die Durchsatzvariante SPECint_rate2006.  Da uns Single Thread Performance interessiert, ist SPECint_2006 die natuerliche Wahl.  Leider gibt es auch hier zwei Probleme:
  1. SPECint_2006 ist nicht wirklich single threaded.  Einige der Teilbenchmarks koennen von modernen Compilern sehr gut parallelisiert werden.  Das wird von den Benchmark-Regeln erlaubt und natuerlich oft benutzt.
  2. Nicht alle Hersteller veroeffentlichen SPECint_2006.  Es gibt sehr viele Veroeffentlichungen von SPECint_rate2006 aber sehr viel weniger Veroeffentlichungen der entsprechenden single thread Variante des gleichen Systems.

Wegen dieser Probleme scheint auch SPEC CPU2006 nicht die Antwort auf unsere Frage zu liefern.  Es gibt jedoch viele die meinen, dieses Problem umgehen zu koennen.  Sie argumentieren ungefaehr so:

"SPECint_rate2006 ist nichts anderes als ein paralleler Lauf vieler Kopien von SPECint_2006 auf einem groesseren System.  Wenn ich also die Single Thread Performance dieses Systems wissen moechte, muss ich einfach nur das SPECint_rate2006 Ergebnis durch die Anzahl der CPU Threads oder evtl. durch die Anzahl der verwendeten Kopien, die in der Veroeffentlichung dokumentiert sind teilen, um das Single Thread Ergebnis zu bekommen."

Das klingt eigentlich ganz einfach.  Aber funktioniert es?  Das laesst sich anhand einiger Beispiele ueberpruefen, bei denen es gluecklicher Weise Ergebnisse fuer SPECint_2006 und SPECint_rate2006 gibt.  Um die Betrachtung einfach zu halten, werde ich hier nur den Sub-Benchmark perlbench betrachten, nicht das Gesamtergebnis.  Wer moechte, kann das gerne mit anderen Sub-Benchmarks ueberpruefen.

System SPECint_2006 perlbench SPECint_rate2006 perlbench Number of copies SPECint_rate2006 perlbench / Anzahl der Kopien
Genauigkeit der Single Thread Schaetzung
M3000 16.4 83.5 8 10.4 64%
Power780 4.14 GHz 28.1 1120 128 8.75 31%
Sun Fire X4-2
(Intel Xeon E5-2697 v2 2.7GHz)
41
894
96 9.3
23%

Alle diese Werte sind von spec.org vom 17. Maerz 2014.  Die jeweiligen Werte sind mit ihren Gesamt-Veroeffentlichungen auf spec.org verlinkt.

Es wird sehr deutlich, dass eine Abschaetzung der Single Thread Performance mit diesem einfachen Vorgehen nicht funktioniert.  Warum nicht?  Weil die heutigen CPUs alle multi-threading CPUs sind.  Sie haben nicht nur alle mehrere Kerne, die sich L2 oder L3 Caches und die Memory-Bandbreite teilen.  Sie haben darueber hinaus mehrere Threads, die sich einen Kern teilen.  Der Sinn dieser Threads liegt in einer hoeheren Kernauslastung:  Ein einzelner Thread ist nicht in der Lage, die modernen, schnell laufenden Kerne auch nur annaehernd auszulasten, hauptsaechlich weil die Memory-Latenz mit der Entwicklung der CPU-Taktraten nicht schrittgehalten hat.  Das bedeutet, dass ein zweiter, dritter oder vierter Thread in der Lage ist, zusaetzliche Arbeit zu verrichten ohne die anderen auf diesem Kern laufenden Threads wesentlich zu beeinflussen.  Natuerlich gibt es den Punkt, ab dem der Kern im Wesentlichen ausgelastet ist und daher die zusaetzliche Arbeit, die durch weitere Threads ausgefuehrt wird, mit zunehmender Threadanzahl abnehmen wird.  Das Diagram rechts stellt diesen Zusammenhang idealisiert dar.  Je nach Charakteristik der Rechenlast variiert die optimale Anzahl von Threads zwischen 1 und 8.  Das ist normal und im taeglichen Betrieb eines Rechenzentrums liefern diese CPUs daher hervorragenden Durchsatz.  Allerdings ist es fuer die Kapazitaetsplanung manchmal eine Herausforderung.  Im Falle einer Benchmark-Konfiguration fuer einen Durchsatz-Benchmark wie SPECint_rate2006 jedoch ist maximaler Durchsatz das einzige Ziel.  Daher sind auch die bspw. 2%, die ein weiterer Thread zum Gesamtergebnis noch beitraegt willkommen.  Durchsatz-Benchmarks wie SPECint_rate2006 oder SAP SD 2 Tier werden fuer maximalen Durchsatz optimiert. 

Das bedeutet jedoch zwingend, dass die durchschnittliche Leistung pro Thread deutlich unter der potentiellen Maximalleistung eines Threads liegt.  Und deswegen kann dieser Durchschnitt nicht zur Bewertung der Single Thread Performance herangezogen werden.

Aber welchen anderen Ausweg gibt es?  Hier hilft eine Rueckbesinnung auf das, was wir wirklich wissen wollen.  Single Thread Performance ist ja kein Wert an sich.  Sie hat einen Zweck.  In den meisten Faellen geht es um die Antwortzeit einer Anwendung - Antwortzeit, die unsere Erwartungen erfuellt oder unterschreitet.  Gluecklicher Weise gibt es einen Benchmark, der genau diese Anforderungen stellt:  SPECjbb2013.  Nun weiss ich natuerlich, dass dieser Benchmark sich speziell mit den Anforderungen an einen Application Server befasst.  Was sich stark von denen an bspw. ein Datawarehouse unterscheidet.  Nichts desto Trotz liefert er uns zuverlaessige Hinweise ueber die Single Thread Performance und, noch wichtiger, liefert er uns Hilfen zum Verstaendnis von Single Thread Performance im Vergleich verschiedener Systeme (wenn denn Ergebnisse vorhanden sind...)

Daher also nun ein kurzer Blick auf SPECjbb2013 und wie dieser Benchmark uns vielleicht helfen kann, unsere Frage zu beantworten:

Die Ergebnisse von SPECjbb2013 werden in zwei Werten gemessen:  max-jOPS und critical-jOPS.  max-jOPS ist dabei ein reiner Durchsatz-Wert, der diese Diskussion nicht weiter bringt.  critical-jOPS hingegen ist "a metric that measures critical throughput under service level agreements (SLAs) specifying response times ranging from 10ms to 500ms." (Zitat aus der Benchmark Beschreibung von SPEC.)  Es wird also Durchsatz unter einer Antwortzeiten-Bedingung gemessen.  Damit entsteht ein hoher Druck sowohl auf das System als auch auf die Benchmark-Teams.  Sie muessen das System fuer die sehr realistische Anforderung optimieren, niedrig-latente Antworten bei gleichzeitig hohem Durchsatz zu liefern.  Wie hilft uns das nun auf unserer Suche nach einem Vergleich der Single Thread Performance weiter?  Nun, angenommen wir haben zwei Systeme mit vergleichbarer Konfiguration und Preis.  System A liefert 10000 max-jOPS und 5000 critical-jOPS.  System B liefert 7500 max-jOPS und 6000 critical-jOPS.  System A schafft also einen hoeheren Durchsatz, allerdings nur, solange wir die Antwortzeiten ignorieren.  Der Durchsatz mit System B ist dagegen nicht so hoch, das System schafft jedoch mehr critical-jOPS als System A.  Das ist fuer uns ein Hinweis, dass die Single Thread Performance von System B besser ist als die von System A - es schafft einen hoeheren Durchsatz unter Antwortzeit-Bedingungen.  Zugegeben, auch das ist nicht die "allein selig machende" Antwort auf die Frage nach der absoluten Single Thread Performance, die wir evtl. gesucht haben.  Eine Aussage der Art "System A hat eine 3x hoehere Single Thread Performance als System B" wird es nicht geben.  Das liegt u.A. daran, dass Durchsatz und die Art und Weise wie ein System skaliert und mit einer hoch skalierenden Last umgeht eine grosse Rolle in diesem Benchmark spielt.  Es ist jedoch ein sehr realistisches Szenario das uns einige belastbare Hinweise gibt, was wir bzgl. der Single Thread Performance von verschiedenen Maschinen erwarten koennen.  Wie mit jedem anderen Benchmark auch, muessen diese Schlussfolgerungen natuerlich spezifisch fuer die jeweilige Anwendung, die verwendeten Daten, die Test-Umstaende und aehnliches sein.  Aber SPECjbb2013 ist ein gutest Beispiel dafuer, wie man Hinweise auf Single Thread Performance bekommen kann.

Eine letzte Bemerkung zu SPECjbb2013:  Die Benchmark Teams der verschiedenen Hersteller fangen gerade erst an, diesen neuen Benchmark zu verstehen.  So gibt es bspw. 3 Resultate fuer die Oracle SPARC T5-2, mit critical-jOPS Werte von 23334 bis 43963.  Das macht deutlich, dass man hier vorsichtig vorgehen sollte, moechte man nicht Aepfel mit Birnen vergleichen.  Der Loewenanteil an diesen Unterschieden ist auf die verwendete Java-Version zurueck zu fuehren.  Das erste Ergebnis wurde mit JDK 7u17 erzielt, das zweite, 1.89x bessere mit dem kuerzlich angekuendigten Java 8 JDK.  Das zeigt nicht nur, dass man bei Vergleichen die Software Version beruecksichtigen muss sondern auch, wie Vorteilhaft es sein kann, eine neue Version einzusetzen.  Gluecklicher Weise gibt es zunehmend mehr Einreichungen fuer diesen Benchmark, so dass es in Zukunft hoffentlich einfacher wird, Vergleiche anzustellen.

Geschafft - das war eine etwas lange Antwort auf eine kurze Frage...  Fuer all diejenigen, die noch mehr wissen moechte, hier noch ein paar Vorschlaege:

Vielen Dank an Ruud van der Pas und Patrick McGehearty fuer Ihre Beitraege zu diesem Eintrag!

Benchmark Disclosures:
SPEC and the benchmark names SPECjbb2013 and SPECint are registered trademarks of the Standard Performance Evaluation Corporation. Results as of March 17, 2014 from www.spec.org

Montag Jun 24, 2013

Das T5-4 TPC-H Ergebnis naeher betrachtet

Inzwischen haben vermutlich viele das neue TPC-H Ergebnis der SPARC T5-4 gesehen, das am 7. Juni bei der TPC eingereicht wurde.  Die wesentlichen Punkte dieses Benchmarks wurden wie gewohnt bereits von unserer Benchmark-Truppe auf  "BestPerf" zusammengefasst.  Es gibt aber noch einiges mehr, das eine naehere Betrachtung lohnt.

Skalierbarkeit

Das TPC raet von einem Vergleich von TPC-H Ergebnissen in unterschiedlichen Groessenklassen ab.  Aber auch innerhalb der 3000GB-Klasse ist es interessant:

  • SPARC T4-4 mit 4 CPUs (32 Cores mit 3.0 GHz) liefert 205,792 QphH.
  • SPARC T5-4 mit 4 CPUs (64 Cores mit 3.6 GHz) liefert 409,721 QphH.

Das ist nicht ganz 100% Skalierbarkeit, wenn man davon ausgeht, dass die doppelte Anzahl Kerne das doppelte Ergebnis liefern sollte.  Etwas anspruchsvoller, koennte man natuerlich auch einen Faktor von 2.4 erwarten, wenn man die hoehere Taktrate mit beruecksichtigt.   Da das TPC keine Schaetzungen und andere Zahlenspielereien erlaubt, ueberlasse ich das dem Leser.  Jetzt jedoch ein Blick auf einige Details, die eine moegliche Erklaerung liefern koennen:

Plattenspeicher

Im Bericht auf BestPerf und auch im Full Disclosure Report der TPC stehen einige interessante Details zum Plattenspeicher und der Konfiguration.   In der Konfiguration der SPARC T4-4 wurden 12 2540-M2 Arrays verwendet, die jeweils ca. 1.5 GB/s Durchsatz liefert, insgesamt also eta 18 GB/s.  Dabei waren die Arrays offensichtlich mit jeweils 2 Kabeln pro Array direkt an die 24 8GBit FC-Ports des Servers angeschlossen.  Mit den 2x 8GBit Ports pro Array koennte man so ein theoretisches Maximum von 2GB/s erreichen.  Tatsaechlich wurden 1.5GB/s geliefert, was so ziemlich dem realistischen Maximum entsprechen duerfte.

Fuer den Lauf mit der SPARC T5-4 wurden doppelt so viele Platten verwendet.  Dafuer wurden die 2540-M2 Arrays mit je einem zusaetzlichen Plattentray erweitert.  Mit dieser Konfiguration wurde dann (laut BestPerf) ein Maximaldurchsatz von 33 GB/s erreicht - nicht ganz das doppelte des SPARC T4-4 Laufs.  Um tatsaechlich den doppelten Durchsatz (36 GB/s) zu liefern, haette jedes der 12 Arrays 3 GB/s ueber seine 4 8GBit Ports liefern muessen.  Im FDR stehen nur 12 dual-port FC HBAs, was die Verwendung der Brocade FC Switches erklaert: Es wurden alle 4 8GBit ports jedes Arrays an die Switches angeschlossen, die die Datenstroeme dann in die 24 16GBit HBA ports des Servers buendelten.  Diese Konfiguration liefert ein theoretisches Maximum von 48x8GBbit FC Bandbreite von den Arrays an die 24 FC Ports des Servers.  Das theoretische Maximum jedes Storage-Arrays waere nun 4 GB/s.  Wenn man jedoch den Protokoll- und "Realitaets"-Overhead mit einrechnet, sind die tatsaechlich gelieferten 2.75 GB/s gar nicht schlecht.  Mit diesen Zahlen im Hinterkopf ist die Verdopplung des SPARC T4-4 Ergebnisses eine gute Leistung - und gleichzeitig eine moegliche Erklaerung, warum nicht bis zum 2.4-fachen skaliert wurde.  Aber natuerlich koennte es auch andere Gruende wie bspw. Software-Skalierbarkeit geben, die hier eine Rolle spielten.

Nebenbei bemerkt: Weder die SPARC T4-4 noch die SPARC T5-4 hatten in der gemessenen Konfiguration irgendwelche Flash-Devices.

Mitbewerb

Seit die T4 Systeme auf dem Markt sind, bemuehen sich unsere Mitbewerber redlich darum, ueberall den Eindruck zu hinterlassen, die Leistung des SPARC CPU-Kerns waere weiterhin mangelhaft.  Auch scheinen sie ueberzeugt zu sein, dass (ueber)grosse Caches und hohe Taktraten die einzigen Schluessel zu echter Server Performance seien.  Wenn ich mir nun jedoch die oeffentlichen TPC-H Ergebnisse ansehe, sehe ich dies:

TPC-H @3000GB, Non-Clustered Systems
System QphH
SPARC T5-4
3.6 GHz SPARC T5
4/64 – 2048 GB
409,721.8
SPARC T4-4
3.0 GHz SPARC T4
4/32 – 1024 GB
205,792.0
IBM Power 780
4.1 GHz POWER7
8/32 – 1024 GB
192,001.1
HP ProLiant DL980 G7
2.27 GHz Intel Xeon X7560
8/64 – 512 GB
162,601.7

Kurz zusammengefasst: Mit 32 Kernen (mit 3 GHz und 4MB L3 Cache), liefert die SPARC T4-4 mehr QphH@3000GB ab als IBM mit ihrer 32 Kern Power7 (bei 4.1 GHz und 32MB L3 Cache) und auch mehr als HP mit einem 64 Kern Intel Xeon System (2.27 GHz und 24MB L3 Cache).  Ich frage mich, wo genau SPARC hier mangelhaft ist?

Nun koennte man natuerlich argumentieren, dass beide Ergebnisse nicht gerade neu sind.  Nun, in Ermangelung neuerer Ergebnisse kann man ja mal ein wenig spekulieren:

IBMs aktueller Performance Report listet die o.g. IBM Power 780 mit einem rPerf Wert von 425.5.  Ein passendes Nachfolgesystem mit Power7+ CPUs waere die Power 780+ mit 64 Kernen, verfuegbar mit 3.72 GHz.  Sie wird mit einem rPerf Wert von  690.1 angegeben, also 1.62x mehr.  Wenn man also annimmt, dass Plattenspeicher nicht der limitierende Faktor ist (IBM hat mit 177 SSDs getestet, sie duerfen das gerne auf 400 erhoehen) und IBMs eigene Leistungsabschaetzung zugrunde legt, waere IBM dennoch nicht in der Lage, die Leistung des Power7 Systems zu verdoppeln.  Und sie wuerden ja mehr als das brauchen, um an die Leistung der T5-4 heran zu kommen.  Das ist insbesondere in der von IBM so geschaetzten "per core" Metric schmerzlich.

In der x86-Welt sieht es nicht besser aus.  Leider gibt es von Intel keine so praktischen rPerf-Tabellen.  Daher muss ich hier fuer eine Schaetzung auf SPECint_rate2006 zurueckgreifen.  (Ich bin kein grosser Fan von solchen Kreuz- und Querschaetzungen.  Insb. SPECcpu ist nicht besonders geeignet, um Datenbank-Leistung abzuschaetzen, da fast kein IO im Spiel ist.)  Das o.g. HP System wird bei SPEC mit 1580 CINT2006_rate gelistet.  Das bis einschl. 2013-06-14 beste Resultat fuer den neuen Intel Xeon E7-4870 mit 8 CPUs ist 2180 CINT2006_rate.  Das ist immerhin 1.38x besser.  (Wenn man nur die Taktrate beruecksichtigen wuerde, waere man bei 1.32x.)  Hier weiter zu rechnen, ist muessig und ich ueberlasse das gern dem Leser.  Die Ergebnisse sind fuer x86 nicht gerade ermutigend...

Natuerlich sind IBM oder HP herzlich eingeladen, diese Werte zu widerlegen.  Aber stand heute warte ich noch auf aktuelle Benchmark Veroffentlichungen in diesem Datensegment.

Was koennen wir also zusammenfassen?

  • Es gibt einige Hinweise, dass der Plattenspeicher der begrenzende Faktor sein koennte, der die SPARC T5-4 daran hinderte, auf jenseits von 2x zu skalieren
  • Der Mythos, dass SPARC Kerne keine Leistung bringen, ist genau das - ein Mythos.  Wie sieht es umgekehrt eigentlich mit einem TPC-H Ergebnis fuer die Power7+ aus?
  • Cache ist nicht der magische Performance-Schalter, fuer den ihn manche Leute offenbar halten.
  • Ein System, eine CPU-Architektur und ein Betriebsystem jenseits einer gewissen Grenze zu skalieren ist schwer.  In der x86-Welt scheint es noch ein wenig schwerer zu sein.

Was fehlt?  Nun, das Thema Preis/Leistung ueberlasse ich gerne den Verkaeufern ;-)

Und zu guter Letzt: Nein, ich habe mich nicht ins Marketing versetzen lassen.  Aber manchmal kann ich mich einfach nicht zurueckhalten...


Disclosure Statements

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

TPC-H, QphH, $/QphH are trademarks of Transaction Processing Performance Council (TPC). For more information, see www.tpc.org, results as of 6/7/13. Prices are in USD. SPARC T5-4 409,721.8 QphH@3000GB, $3.94/QphH@3000GB, available 9/24/13, 4 processors, 64 cores, 512 threads; SPARC T4-4 205,792.0 QphH@3000GB, $4.10/QphH@3000GB, available 5/31/12, 4 processors, 32 cores, 256 threads; IBM Power 780 QphH@3000GB, 192,001.1 QphH@3000GB, $6.37/QphH@3000GB, available 11/30/11, 8 processors, 32 cores, 128 threads; HP ProLiant DL980 G7 162,601.7 QphH@3000GB, $2.68/QphH@3000GB available 10/13/10, 8 processors, 64 cores, 128 threads.

SPEC and the benchmark names SPECfp and SPECint are registered trademarks of the Standard Performance Evaluation Corporation. Results as of June 18, 2013 from www.spec.org. HP ProLiant DL980 G7 (2.27 GHz, Intel Xeon X7560): 1580 SPECint_rate2006; HP ProLiant DL980 G7 (2.4 GHz, Intel Xeon E7-4870): 2180 SPECint_rate2006,

Donnerstag Apr 04, 2013

Ein paar Bemerkungen zur T5

Inzwischen wird fast jeder die Ankündigung der neuen T5 und M5 Systeme gesehen haben.  Ich möchte hier nichts wiederholen, aber doch ein paar erste Gedanken dazu loswerden.  Meine Gedanken, wohlgemerkt, nicht notwendiger Weise die von Oracle.

Bei der Ankündigung war es recht offensichtlich, dass wir in Zukunft noch mehr Freude am Wettbewerb mit IBM haben werden.  Ich werde mich an diesem Krieg der Worte nicht beteiligen sondern nur auf eine sehr lesenswerte Zusammenfassung (der bisherigen Scharmützel) hinweisen, die man bei Forbes findet.  Die zwei Minuten Lesezeit lohnen sich - ich finde es sehr interessant, wie IBM plötzlich das Interesse an Performance verliert...

Da ein Großteil der Aufmerksamkeit die die Ankündigung erregt hat sich auf Performance-Behauptungen bezieht, möchte ich hier einfach eine knappe, übersichtliche Zusammenfassung der gebräuchlicheren Benchmarks angeben, die wir veröffentlicht haben.  Vergleiche mit anderen Systemen überlasse ich anderen - ich will niemanden den Spass nehmen ;-)

Es gibt noch ettliche weitere Veröffentlichungen zum Thema Performance, insbesondere auf dem BestPerf blog.  Manche davon sind recht interessant, weil sie T5 mit x86 vergleichen, etwas was ich all denen empfehlen moechte, die ab und zu ihr Weltbild überdenken wollen.  Ich habe hier diejenigen aufgeführt, die meist als "unabhängig" betrachtet werden.  Nun wissen wir ja alle, dass ein Weltrekord nur so lange gilt, bis der nächste veröffentlicht wird.  Bleibt die Frage, wer der nächste sein wird.  (Wir haben ab und zu auch unsere eigenen Rekorde eingestellt...)   Und zu guter letzt möchte ich erwähnen, dass Performance ja nicht immer alles ist.  Price/Performance ist oft mindestens genauso wichtig.  Im Benchmark-Spiel kann man idR. nur Listenpreise vergleichen.  Wer Lust hat, kann sich damit ja mal amüsieren!  Larry meint dazu lediglich:   “You can go faster, but only if you are willing to pay 80% less than what IBM charges.”

Wettbewerb ist spannend, oder nicht?

Montag Mai 14, 2012

Benchware Test der T4

Es gibt einen recht gruendlichen Leistungsvergleich zwischen M5000 und T4-2, den ich jedem nur empfehlen kann der sich immer noch fragt, ob diese TPC-H Weltrekorde wirklich moeglich sind:

Den Testbericht gibt es auf der Benchware Webseite - dort unter "Benchmarks" nach T4 suchen.

Und hier natuerlich der Link zu den TPC-H Ergebnissen.  Interessant wird es bei 1000GB und 3000GB ;-)

(Nein, ich wurde nichts ins Marketing versetzt.  Ich denke nur, dass dieser Test es verdient hat auf einem Blog erwaehnt zu werden, bei dem es unter Anderem um Performance geht.)

Dienstag Apr 17, 2012

Solaris Zones: Virtualisierung beschleunigt Benchmarks!

Wenn ich mich mit Kunden ueber Virtualisierung unterhalte ist eine der ersten Fragen oft die nach dem Overhead.  Nun wissen wir ja alle, dass Virtualisierung mit Hypervisoren nicht ohne Overhead zu machen ist.  Was wir ebenfalls alle wissen sollten ist, dass es stark vom Lastprofil und dem verwendeten Hypervisor abhaengt, wie gross dieser Overhead jeweils ausfaellt.  Zwar gab es schon einige Versuche, dies in standardisierten Benchmarks zu quantifizieren.  Dennoch bleibt die Antwort auf diese Frage noch immer in den Nebeln von Marketing und Benchmark-Unschaerfe verborgen.  Erstaunen erlebe ich jedoch regelmaessig, wenn ich zu Solaris Zonen (bei Solaris 10 hiessen sie noch Container) als Alternative zur Virtualisierung mit Hypervisoren komme. Solaris Zonen sind, grob vereinfacht, nichts weiter sind als eine Menge von Unix Prozessen, abgegrenzt durch einen Regelsatz der vom Solaris Kernel durchgesetzt wird.  Daher ist es einleuchtend, dass hier nicht besonders viel Overhead anfallen kann.  Dennoch wird die Behauptung von "Zero Overhead" oft angezweifelt, gerade auch weil vielen heute Virtualisierung per Hypervisor sehr nahe ist.  Und so sehr ich die Erklaerung mit technischen Details ueberzeugend finde, so sehr verstehe ich auch, dass sehen viel besser ist als glauben.   Daher:

Die Benchmark-Teams bei Oracle sind so ueberzeugt von den Vorteilen der Solaris Zonen, dass sie diese fuer die veroeffentlichten Benchmarks verwenden.  Das Solaris Resource Management funktioniert natuerlich auch ohne Zonen, aber Zonen machen es so viel einfacher, insb. in Verbindung mit den teilweise recht komplexen Benchmark-Konfigurationen.  Es gibt zahlreiche Benchmark-Veroeffentlichungen bis zurueck in die Tage der T5440, in denen Solaris Container zur Anwendung kommen.  Einige aktuelle Beispiele, alles Weltrekorde, sind:

Die genaue verwendung der Zonen ist in der jeweiligen Benchmark-Beschreibung dokumentiert.

Darueber hinaus hat das Benchmark-Team in einem Blogeintrag beschrieben, wie sie das Solaris Resource Management und Zonen verwenden, um die Anwendungsleistung zu erhoehen.  Das verleitet fast dazu, von "negativem Overhead" zu sprechen, waere der Begriff nicht so irrefuehrend.

Freitag Dez 17, 2010

Solaris versteht die Hardware - pgstat erklaert sie

Motiviert durch die recht hohen Latenz-Unterschiede beim Zugriff auf Memory innerhalb der E25K wurde Solaris 9 9/02 um die sogenannten Locality Groups (lgrp) erweitert.  Damit wird die Memory-Hierarchie des Systems beschrieben, die je nach Hardware sehr stark verschieden sein kann.   Beim Erzeugen von Prozessen sowie beim Scheduling wird dann versucht, die CPU und den jeweils verwendeten Speicherbereich moeglichst nahe zueinander zu bringen.  Dieses Feature, als Memory Placement Optimization (MPO) bekannt, kann, je nach Anwendungsfall und Hardware, erhebliche Performance-Verbesserungen realisieren.

Der Solaris Kernel bietet, neben vielem Anderem, auch tausende von Zaehlern, die mit kstat, cpustat oder mit bekannteren Kommandos wie mpstat oder iostat abgefragt werden koennen.  Insbesondere die Werte, die cpustat liefert, sind dabei stark von der Hardware abhaengig, da nicht jede CPU jeden Typ Zaehler bietet. Die Auswirkungen auf die Performance, bzw die Auslastung der diversen Hierarchie-Teile konnte bisher jedoch kaum sinnvoll ausgewertet werden.  Hier gab es mit corestat bisher lediglich fuer die T-Serie ein Perl-Skript, das verschiedene Zaehler mit Hilfe von cpustat auswerten konnte.  Das ist mit Solaris 11 Express nun endlich Geschichte.

Es gibt drei neue Kommandos: lgrpinfo, pginfo und pgstat.

lgrpinfo zeigt die Hierarchie der L-Groups an, also die NUMA-Struktur der Hardware.  Immer dann, wenn man bspw. mit Solaris Containern und Resource-Gruppen einzelne CPUs zu Prozessor-Sets verbinden moechte, ist diese Information recht hilfreich.

pginfo zeigt, etwas anders orientiert als lgrpinfo, eine Baum-Sicht des gesamten Systems an.  Die Blaetter dieses Baumes sind die einzelnen Interger- und Floatingpoint Pipelines der einzelnen Kerne.  Hier ein kleines Beispiel aus einer T2 LDom, bestehend aus 16 Strands, die auf verschiedenen Cores ausgefuehrt werden:

# pginfo -v
0 (System [system]) CPUs: 0-15
|-- 3 (Data_Pipe_to_memory [chip]) CPUs: 0-7
| |-- 2 (Floating_Point_Unit [core]) CPUs: 0-3
| | `-- 1 (Integer_Pipeline [core]) CPUs: 0-3
| `-- 5 (Floating_Point_Unit [core]) CPUs: 4-7
| `-- 4 (Integer_Pipeline [core]) CPUs: 4-7
`-- 8 (Data_Pipe_to_memory [core,chip]) CPUs: 8-15
`-- 7 (Floating_Point_Unit [core,chip]) CPUs: 8-15
|-- 6 (Integer_Pipeline) CPUs: 8-11
`-- 9 (Integer_Pipeline) CPUs: 12-15

Hier wird die Zuordnung der verschiedenen Strands zu Pipelines und Cores sehr schoen deutlich.

pgstat letztlich ist ein wuerdiger Nachfolger fuer corestat und zeigt die Auslastung dieser einzelnen Komponenten sehr uebersichtlich an.  Hier wieder ein Beispiel, das gleichzeitig eine fast 100%ige Kern-Auslastung zeigt - etwas, was es recht selten zu beobachten gibt...


# pgstat -Apv 1 2
PG RELATIONSHIP HW UTIL CAP SW USR SYS IDLE CPUS
0 System [system] - - - 100.0% 99.6% 0.4% 0.0% 0-15
3 Data_Pipe_to_memory [chip] - - - 100.0% 99.1% 0.9% 0.0% 0-7
2 Floating_Point_Unit [core] 0.0% 179K 1.3B 100.0% 99.1% 0.9% 0.0% 0-3
1 Integer_Pipeline [core] 80.0% 1.3B 1.7B 100.0% 99.1% 0.9% 0.0% 0-3
5 Floating_Point_Unit [core] 0.0% 50K 1.3B 100.0% 99.1% 0.9% 0.0% 4-7
4 Integer_Pipeline [core] 80.2% 1.3B 1.7B 100.0% 99.1% 0.9% 0.0% 4-7
8 Data_Pipe_to_memory [core,chip] - - - 100.0% 100.0% 0.0% 0.0% 8-15
7 Floating_Point_Unit [core,chip] 0.0% 80K 1.3B 100.0% 100.0% 0.0% 0.0% 8-15
6 Integer_Pipeline 76.4% 1.3B 1.7B 100.0% 100.0% 0.0% 0.0% 8-11
9 Integer_Pipeline 76.4% 1.3B 1.7B 100.0% 100.0% 0.0% 0.0% 12-15
PG RELATIONSHIP HW UTIL CAP SW USR SYS IDLE CPUS
0 System [system] - - - 100.0% 99.7% 0.3% 0.0% 0-15
3 Data_Pipe_to_memory [chip] - - - 100.0% 99.5% 0.5% 0.0% 0-7
2 Floating_Point_Unit [core] 0.0% 76K 1.2B 100.0% 99.5% 0.5% 0.0% 0-3
1 Integer_Pipeline [core] 79.7% 1.2B 1.5B 100.0% 99.5% 0.5% 0.0% 0-3
5 Floating_Point_Unit [core] 0.0% 42K 1.2B 100.0% 99.5% 0.5% 0.0% 4-7
4 Integer_Pipeline [core] 79.8% 1.2B 1.5B 100.0% 99.5% 0.5% 0.0% 4-7
8 Data_Pipe_to_memory [core,chip] - - - 100.0% 99.9% 0.1% 0.0% 8-15
7 Floating_Point_Unit [core,chip] 0.0% 80K 1.2B 100.0% 99.9% 0.1% 0.0% 8-15
6 Integer_Pipeline 76.3% 1.2B 1.5B 100.0% 100.0% 0.0% 0.0% 8-11
9 Integer_Pipeline 76.4% 1.2B 1.5B 100.0% 99.8% 0.2% 0.0% 12-15

SUMMARY: UTILIZATION OVER 2 SECONDS

------HARDWARE------ ------SOFTWARE------
PG RELATIONSHIP UTIL CAP MIN AVG MAX MIN AVG MAX CPUS
0 System [system] - - - - - 100.0% 100.0% 100.0% 0-15
3 Data_Pipe_to_memory [chip] - - - - - 100.0% 100.0% 100.0% 0-7
2 Floating_Point_Unit [core] 76K 1.2B 0.0% 0.0% 0.0% 100.0% 100.0% 100.0% 0-3
1 Integer_Pipeline [core] 1.2B 1.5B 79.7% 79.7% 80.0% 100.0% 100.0% 100.0% 0-3
5 Floating_Point_Unit [core] 42K 1.2B 0.0% 0.0% 0.0% 100.0% 100.0% 100.0% 4-7
4 Integer_Pipeline [core] 1.2B 1.5B 79.8% 79.8% 80.2% 100.0% 100.0% 100.0% 4-7
8 Data_Pipe_to_memory [core,chip] - - - - - 100.0% 100.0% 100.0% 8-15
7 Floating_Point_Unit [core,chip] 80K 1.2B 0.0% 0.0% 0.0% 100.0% 100.0% 100.0% 8-15
6 Integer_Pipeline 1.2B 1.5B 76.3% 76.3% 76.4% 100.0% 100.0% 100.0% 8-11
9 Integer_Pipeline 1.2B 1.5B 76.4% 76.4% 76.4% 100.0% 100.0% 100.0% 12-15

Die Interpretation der diversen Werte ist, nach einem kurzen Blick in die Manpage, eine einfache und klare Angelegenheit.  Damit macht Performance-Analyse, insbesondere auf T2 und T3 Systemen, jetzt noch mehr Spass :-)

Montag Jun 07, 2010

prstat und microstate accounting

Man lernt nie aus.  Als Reaktion auf meinen letzten Blogeintrag bekam ich den Hinweis, bei prstat doch die Option "-m" zu verwenden, um mich von den traegen und unzuverlaessigen Durchschnittswerten zu befreien.  Was dahinter steckt, wollte ich natuerlich genauer wissen, und wurde bei Eric Schrock fuendig.  Hier eine kurze Zusammenfassung:


Die herkoemmliche Ausgabe von prstat (und einigen anderen Kommandos) gibt Durchschnittswerte aus, die auf regelmaessigen Stichproben beruhen.  Je hoeher der CPU-Takt, desto hoeher ist auch die Wahrscheinlichkeit, dass einige Ereignisse selbst bei langen Messintervallen von keiner Stichprobe erfasst werden - die Ergebnisse werden immer unpraezieser, je hoeher der CPU-Takt und je kuerze die Ereignisse.  Bei Microstate-Accounting werden die Ereignisse direkt "am Objekt" erfasst.  Durch einige Aenderungen in der Implementierung wurde dies in Solaris 10 ausreichend effizient, um staendig aktiv sein zu koennen.  Verwendet man nun bspw. bei prstat diese praezieseren Werte, erscheint ein CPU-Fresser tatsaechlich sofort mit 100%.  Damit eruebrigt sich die Umrechnung der CPU-Anzahl in Auslastungs-Anteile.  Ein von der Singlethread-Leistung begrenzter Prozess wird so viel schneller und einfacher sichtbar.


Auch die Praesentation habe ich natuerlich entsprechend angepasst.


Vielen Dank fuer den Hinweis!  An solchen Dingen merke ich, dass ich Kommandos wie prstat schon viel zu lange (und durchaus erfolgreich) verwende.  Dieses neue Feature ging, aehnlich wie in dem Eintrag von Eric erwaehnt, auch bei mir wegen ZFS, Containern, SMF etc. unter.

Mittwoch Mrz 10, 2010

Ein paar Gedanken zu Skalierbarkeit


Vor einigen Tagen gab es auf einem internen Verteiler ein Diskussion ueber Skalierbarkeit, und warum Solaris besonders gut darin ist.  Einige alt-gediente Performance-Meister fassten das Thema so bemerkenswert gut zusammen, dass ich diese Zusammenfassung gerne einem breiteren Publikum zugaenglich machen moechte.  Sie waren einverstanden, deswegen:


Was ist Skalierbarkeit, und warum ist Solaris so gut darin, Anwendungen nicht am skalieren zu hindern?
Gute Skalierbarkeit ist eine klassische Beobachtung bei Systemen, die ueber Jahre hinweg optimiert wurden.  Diese Systeme habe nicht nur eine gute Leistung bei hoher Last, sondern diese Leistung degeneriert bei Ueberlast auch weniger.


Der Grund dafuer wird meistens mathematisch beschrieben:  Die Steigung der Kurve der Antwortzeit (Degeneration) wird dominiert durch die Antwortzeit der einen, langsamsten Komponente.  Ein neues Produkt hat normalerweise ein paar wenige, grosse Flaschenhaelse.  Und weil sie so gross sind, steigt die Antwortzeit-Kurve fruehzeitig in Richtung Unendlichkeit, und ist dabei sehr steil und gerade.


Ein solches System auch nur ein wenig zu ueberlasten wirkt wie ein "Gegen die Wand fahren" - das System haengt scheinbar.  Wenn man die Last auf der X-Achse, und die Antwortzeit auf der Y-Achse auftraegt, sieht das ungefaehr so aus:



Das heisst in unserem Metier die "Hockey-Stick" Kurve ;-)  Die Antwortzeit ist anfangs recht flach, bis zu einem Wendepunkt, ab dem die Kurve gen Himmel steigt wie ein Engel mit Heimweh.


Ein gut optimiertes, ausgereiftes Produkt hingegen hat viele kleine Flaschenhaelse.  Einer davon ist der groesste, und dieser bestimmt die Position und Steigung des Wendepunkts.  Bei einem entsprechend kleinen Flaschenhals ist die Steigung flach.  Bei Ueberlast erlebt der Benutzer ein solches System als langsam oder zaeh, aber nicht als haengend.  Grafisch sieht das dann etwa so aus:



Nicht optimierte oder wenig ausgereifte Programme zeigen ab ca. 80% Auslastung haeufig schlechte Leistung.  Ein haeufiger Grund dafuer ist, dass die Wahrscheinlichkeit fuer wirklich gleichzeitige Anfragen hoch ist, und diese die Software kurzfristig an den Wendepunkt hin zur Degeneration fuehren.  Da das System nicht-optimal ist, ist der Grad der Degeneration hoch und entsprechend fuer den Benutzer sichtbar.  Diese Situation tritt typischerweise bei ca. 70% - 80% Last auf, manchmal auch frueher.


Wir haben in der Entwicklung von Solaris seit Jahren erfolgreich Jagd auf auch die kleinsten Flaschenhaelse gemacht.  Entsprechend ist der Anstieg unserer Degenerations-Kurve sehr sehr sanft.  PCs, auf der anderen Seite, haben eine Tendenz, schnell und haeufig gegen die Wand zu fahren.  Ein Teil ihrer ja bereits legendaeren Unzuverlaessigkeit ist allerdings nicht echt: Manche Benutzer ueberlasten die Maschine, vermuten wegen der extrem langen Antwortzeiten einen Haenger oder Absturz, und booten neu...


Ein haeufig genannter Grund fuer die hervorragenden Skalierungseigenschaften von Solaris sind seine sehr feinkoernigen Spin-Locks.  Grobkoernige Locks verlaengern die Antwortzeiten von eigentlich seriellen Locks mit der zu erwartenden Auswirkung entsprechend Amdahl's Law.  Durch seine ueber die Jahre entwickelte Plattform-Kenntnisse traegt insbesondere der Solaris Scheduler stark zur Skalierbarkeit von Solaris bei.  Auch andere Features wie diverse AIO Optionen und Preemption-Kontrolle wie sie bspw. in Oracle integriert wurden sind weitere Gruende fuer die gute Skalierbarkeit.


Desweiteren geht es bei Skalierung, insbesondere \*guter\* Skalierung, nicht nur um hohen Durchsatz und die durchschnittliche Antwortzeit als Funktion der Last.  Gute Skalierbarkeit fuehrt haeufig auch zu einer geringeren Varianz in der Antwortzeit, die der Benutzer als hoehere Zuverlaessigkeit erlebt, sowie zu der erwaehnten sanften Degeneration jenseits der Saettigung.  Diese Faktoren sollten viel oefter gemessen und besprochen werden.  Leider konzentriert sich die Benchmark-Welt viel zu sehr auf die eine Zahl des hoechsten Durchsatzes.


Als letztes:  Die Grundlage fuer all dies wurde gelegt, als Sun (in den 90er Jahren) seine Version von SVR4 definierte.  Wir haben die Implementierung von AT&T mehr oder weniger vollstaendig durch unsere eigene Vorstellung von voller Preemption, Multi-Threading und dem ganzen Rest ersetzt.  Wenn die Grundlage stimmt, ist es so viel einfacher, darauf aufbauend andere Dinge zu bauen.  Wenn man bei jedem neuen Feature die Grundlage umbauen muss, ist das sehr viel muehsamer.  


Die Folge:  Grosse Server auf einer hervorragenden Grundlage fuehrt zu Kunden, die immer noch mehr Arbeit auf die Server bringen, was neue Probleme aufzeigt die wir loesen, was zu Kunden fuehrt, die noch mehr Arbeit auf die Maschinen bringen...


Wenn man das ganze live erleben moechte, hier die Zutaten fuer eine Live-Demo:
Perfbar oder den Gnome perfmeter als Anzeige der CPU-Auslastung.  Auch ein Textfenster mit mpstat reicht dafuer aus.  Dann noch eine interaktive Anwendung als Gradmesser fuer die "gefuehlte" Performance.  Hier bietet sich z.B. die Java2D-Demo an, die mit jedem JDK-Release ausgeliefert wird.  Nun den Rechner unter Last setzten, bspw. mit mehreren endlos laufenden encrypt-Kommandos.  Sichtbare Verschlechterung der interaktiven Anwendung wird es erst sehr nahe an 100% geben ;-)


Die Steigerung hiervon ist, die interaktive Anwendung mittels Solaris Resource Manager mit bspw. 80% CPU auszustatten und die Menge der Hintergrundjobs immer weiter zu steigern.  Selbst erfahrene Techniker kommen hierbei immer wieder ins Staunen.  Problematisch an dieser zweiten Demo koennte sein, dass der eine oder andere anfaengt, an einen Trick zu glauben...  


Dieser Artikel wurde aus mehreren Email-Beitraegen zusammengestellt.  Die Autoren sind:

David Collier-Brown
James Litchfield
Bob Sneed

Vielen Dank hierfuer!
(Die englische Originalfassung gibt es im englischsprachigen Teil dieses Blogs.  Die deutsche Uebersetzung ist von mir.

Freitag Jan 22, 2010

Threadbar

Dieses Tool ist einen Blogeintrag ueber den Blogeintrag wert.  Wer kennt ihn nicht, den guten alten perfbar? Thrbar (eigentlich wohl Threadbar) ist ein Perfbar fuer die Threads eines Prozesses.  Damit wird es endlich moeglich, den Unterschied zwischen einem aktiven und einem existierenden Thread zu visualisieren.  Warum mussten wir eigentlich bis 2010 auf dieses Tool warten?  Dabei ist die Idee wirklich naheliegend.  Aber so ist es ja oft mit guten Ideen - wenn sie mal bekannt sind, schlagen wir uns alles ans Hirn und wundern uns, warum wir da nicht selbst schon lange darauf gekommen sind.  Deswegen meine doppelt ausgesprochene Hochachtung an Rickey Weisner fuer dieses Tool!

Nicht jedes Performance-Problem ist ein CMT SingleThread Problem!

Als einer der Performance-Experten in unserem Team bin ich immer wieder beim Kunden, um den beruechtigten "Performance=ON" Knopf zu druecken.  Dass dieser entgegen aller Geruechte nicht existiert und auch weder in den alten noch den neuen Versionen von Solaris jemals eingebaut wurde, hat sich ja leider immer noch nicht ueberall herum gesprochen.  Was es jedoch gibt, sind relativ viele "Performance=OFF" Knoepfe ;-)  Sie verstecken sich oft an immer den gleichen Stellen, und mit ein wenig Erfahrung kann man sie meistens auch finden, oft auch ohne das Zaubermittel DTrace.  Manchmal jedoch gelingt es, diese Knoepfe hinter einer Wand aus Taeuschungs-Nebel so gut zu verbergen, dass auch altbekannte Varianten wieder ganz neu entdeckt werden wollen.


 Genug der Vorrede - In diesem Fall bestand die Nebelwand aus dem Verdacht, dass -- mal wieder -- die Singlethread Leistung der CMT CPUs, hier auf T5240, nicht ausreicht, und der verwirrenden Beobachtung, dass der selbe Test in einem Container 3x schneller ablaeuft als in einer Global Zone.  Zu untersuchen war das Anlegen eines Datenfiles fuer die Informix Datenbank.  Das verwendete Filesystem war UFS und kam aus einem "SAN" - was ja auch stets mit hoher Leistung assoziiert wird.  Mit zur Verwirrung trug weiterhin bei, dass aus Betriebsgruenden fuer die beiden Tests unterschiedliche Systeme und unterschiedliche LUNs verwendet werden mussten, was natuerlich die Menge der moeglichen Ursachen erheblich vergroessert.


Um die Sache abzukuerzen: Es war nicht die Singlethread Leistung der CPU.  Es war auch nicht ein Performance-Artefakt in der Container-Implementierung.  Es war die Mount-Option "forcedirectio", die einmal gesetzt war, und einmal nicht.  Versteckt wurde dieser Umstand durch die Container-Konfiguration.  Diese Mount-Option ist fuer den Betrieb von Informix empfohlen, da diese Datenbank aehnlich wie Oracle oder DB2 ein eigenes Space-Management hat und die "Hilfe" des Dateisystems hier keine Hilfe waere.  Das Anlegen von Datenfiles ist aber offenbar eher eine Dateisystemoperation wie bspw. tar oder cp, und profitiert daher stark von den Puffermechanismen von UFS.  Hier gab es nun also in der Tat einen "Performance=OFF" Schalter.  Je nachdem, ob man ihn betaetigte oder nicht, war das Anlegen der Datenfiles schnell oder langsam.  Mit CMT und dessen Singlethread-Schwaeche hatte das ganze nichts zu tun. 


Warum blogge ich darueber?  Weil dieser Fall ein schoenes Beispiel dafuer ist, dass Performance-Probleme meistens verstanden werden koennen, wenn man sie holistisch angeht und am Anfang keine der Vermutungen glaubt, die im Vorfeld natuerlich entstehen.  Und das Verstehen des Problems ist der Schluessel zur eventuellen Loesung.

Donnerstag Okt 15, 2009

$10 Millionen zu gewinnen

Oracle glaubt an die Performance von Sun Systemen.  Und wettet $10 Millionen, dass es keine amerikanische Firma gibt, deren Datenbankanwendung auf einem Sun System nicht doppelt so schnell sein kann wie auf dem bisher verwendeten System von IBM.  Gewinnen kann jede Fortune 1000 Company der USA.  Die Regeln gibt es unter http://www.oracle.com/features/exadatachallenge.html

Freitag Aug 28, 2009

Rekorde am Horizont

Ob nun gekauft oder nicht, die Zusammenarbeit von Sun und Oracle funktioniert schon lange praechtig.  Dabei kommt immer wieder Hoechstleistung heraus.  Manchmal auch mit ungewoehnlichem wie TPC-C!  Neugierig:  Schon mal spicken ;-)

Dienstag Jun 02, 2009

Performance - was ist das eigentlich?

Ich beschaeftige mich Tag ein, Tag aus mit "Performance".  Und stosse dabei immer wieder auf das Phaenomen, dass eigentlich gar nicht klar ist, was damit gemeint ist.  Kunden sagen "Das System ist zu langsam".  Aber sie koenne nicht genau beschreiben, was "zu langsam" eigentlich bedeutet oder wie schnell "schnell genug" waere.  Immer wieder erlaeutere ich den Unterschied zwischen Durchsatz und Latenz, und immer wieder treffe ich auf Situationen, in denen die tatsaechlichen Anforderungen an Durchsatz und Latenz nicht oder nicht ausreichend genau definiert sind.


Mein liebstes Beispiel zur Veranschaulichung sind Autos, wohl weil die allermeisten ein Auto im weistesten Sinne kennen.  Klar ist ein Porsche ein schnelles Auto.  Und schnell sollen Autos ja sein.  Warum nur gibt es dann auch Kombis, Lieferwagen, LKWs?  Doch sicher nicht, weil der LKW-Fahrer es einfach lieber etwas gemaechlicher hat.  Und wie ist das mit der Performance von Autos?  Messe ich die an der hoechsten zulaessigen Motor-Umdrehungszahl, oder an der maximal erreichbaren Geschwindigkeit, an der Anzahl der Sitzplaetze oder am Gewicht der Nutzlast?  Diese Fragen sind genauso gut wie ihre Entsprechung in der Welt der Computersysteme.  Und das wesentliche dabei sind nicht in erster Linie die Antworten, sondern die Fragen!  Erst, wenn ich die Frage kenne, kann ich die Antwort ermitteln, erst dann ist die Antwort ueberhaupt sinnvoll.  Zurueck in der Welt der EDV: Erst wenn ich die Anforderungen an die Leistung eines Systems genau beschrieben habe, kann ich beurteilen, ob und in welchem Masse das System diese Anforderungen erfuellt.  Erst dann wird klar, ob "Leistung" im konkreten Fall Latenz oder Durchsatz bedeutet und in welchem Masse die erforderlichen Resourcen mit in die Rechnung eingehen. Wobei auch hier schon wieder Genauigkeit gefragt ist:  Zwei Systeme moegen unterschiedlich "schnell" sein, was auch immer das im jeweiligen Fall bedeuten mag.  Ob und in wie weit die von diesen Systemen gebrauchten Resourcen, also Strom, Platz, Kuehlung, Geld zur Anschaffung und Administration etc., zur Bewertung herangezogen werden sollen, ist bereits eine zweite Frage.  Die Systeme bleiben, gemaess definierter Kriterien, immer gleich schnell.  Ihre Effizienz ist erst die Antwort auf die zweite Frage!

Mittwoch Apr 22, 2009

MySQL mit Skalierungsnachhilfe

In das neue Release von MySQL (version 5.4) sind ettliche Verbesserungen, u.A. beigetragen von Google, eingeflossen, die die bisher doch eher beschraenkte Skalierbarkeit deutlich verbessern.  Die Verbesserungen sind erheblich, wie man auf einem Graphen von Allan Packer sieht:



Damit wird MySQL nun auch auf CMT-Platformen einsetzbar.  Allerdings bleibt die absolute Leistung dieser Software auf CMT immer noch weit hinter den Leistungen z.B. auf der neuen, natuerlich auch gut 2 Jahre juengeren Nehalem-CPU zurueck.  2 Intel x5500 in der X4275 schaffen mit sysbench ca. 4500 TPS, zwei UltraSPARC T2Plus in der T5240 nur ca. 1600 (Faktor 2.8).  Dieser Abstand ist deutlich groesser als z.b. bei SPECjbb2005 (554976 zu 388456, Faktor 1.43) oder SPECint_rate2006 (255 zu 157, Faktor 1.62) .  Es scheint also noch einiges an Potential in MySQL zu stecken...

Mittwoch Apr 15, 2009

UltraSPARC T2 haelt auch Nehalem Stand

Die neuen Intel Xeon X5570 Systeme sind da!  Und wer sich die SPECint-Werte der neuen CPU ansieht erwartet sicher viel von ihnen.  Zurecht, wie die ersten Anwendungsbenchmarks zeigen.  Das  Dual-Socket System Sun X4270 stellt einen neuen Weltrekord beim SAP SD 2-Tier Benchmark unter Verwendung von Unicode auf.  Die Verwendung von Solaris 10 und Oracle macht es dabei moeglich, gleichartige Systeme von HP mit Windows und SQL Server auf die nachfolgenden Plaetze zu verweisen.  


Bemerkenswert ist, dass die bereits mehr als ein Jahr verfuegbare CMT-CPU UltraSPARC T2Plus sich in diesem Benchmark aehnlich gut schlaegt.  Zwar ohne Unicode, aber dafuer mit etwas besserer Leistung.   Auch bei SPECweb2005 schneided die aeltere CPU recht gut ab - immerhin 57% der Leistung der X4570 - mit 50% der Sockel ;-)  CMT Rocks - auch ohne tick tock...


Nachtrag:  Die Verwendung von Unicode ist deutlich CPU-Intensiver.  Damit sind Unicode und Non-Unicode Ergebnisse nicht direkt vergleichbar.  Die wenigen Ergebnisse hierzu, die auf vergleichbarer Hardware einmal mit und einmal ohne Unicode veroeffentlicht wurden legen einen Unterschied von ca. 1.6 nahe.  Damit wuerde eine T5240 immer noch geschaetze 13000 Unicode-SAPS liefern...

About

Neuigkeiten, Tipps und Wissenswertes rund um SPARC, CMT, Performance und ihre Analyse sowie Erfahrungen mit Solaris auf dem Server und dem Laptop.

This is a bilingual blog (most of the time). Please select your prefered language:
.
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Categories
Archives
« April 2014
MoDiMiDoFrSaSo
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Heute