Web-Notizen von Stefan Hinker SPARC, Solaris, Performance und der ganze Rest

Das neue Release 5 der SunRay Server Software ist verfuegbar.  Das hat zwar wenig mit meinem "eigentlichen" Thema CMT oder Performance zu tun.  Da ich aber meist an einer SunRay arbeite, der Server dazu auf meinem Laptop laeuft und ich die beiden PreView-Versionen der Software zumindest installiert hatte, ist mir das dennoch einen Blogeintrag wert.  Ich bin seit 1997, als ich die erste Beta-Unit einer SunRay zu sehen bekam, ein grosser Fan dieser Technik und wundere mich immer wieder, warum es immer noch so viele PCs in den Bueros dieser Welt gibt...  Aber in letzter Zeit ist Desktop-Virtualisierung ja etwas mehr in Mode gekommen - vielleicht erlebe ich es noch, dass SunRay ein allgemein bekanntes Produkt wird

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

Endlich gibt es sie - die Uebersicht ueber alle Powercalulatoren fuer Sun Systeme.  Von der kleinen T5120 bis zur grossen M9000-64 sind sie alle dabei - ebenso Speichersysteme und Tapelibraries.  Sehr zu empfehlen!

(An dieser Stelle meinen Dank an den Kollegen Joachim Krebs fuer den Hinweis )

Am Anfang war es nur der Apache, inzwischen unterstuetzen immer mehr Web- und Applicationserver die PKCS#11-Schnittstelle und damit auch die Hardwareunterstuetzung der SSL-Operationen auf UltraSPARC T2 CPUs.  Wie dies mit Websphere richtig konfiguriert wird, ist nun in einem neuen Blueprint kurz, knapp aber anschaulich beschrieben - einschl. einer kleinen Messung der Geschwindigkeitsgewinne.

Die Leistungsfaehigkeit der 8 Crypto-Beschleuniger im UltraSPARC T2 Prozessor ist enorm, leider ist es teilweise immer noch recht aufwendig, sie zu nutzen. Mit dem Update 7 Release fuer Solaris 10 (Solaris 10 5/09) gibt es hier Fortschritte: Aus dem "What's New" (Seite 11) geht hervor, dass die SunSSH, die Sun-Implementierung der SSH mitsamt dem Abkoemmling scp jetzt die Hardware-Beschleunigung unterstuetzt.  Und sie erreicht damit recht gute Werte.  Ein weiterer Grund, einen Upgrade zu machen - und Systeme der T-Serie entsprechend zu konfigurieren.  Jan Pechanec hat die entsprechenden Aenderungen recht ausfuehrlich beschrieben.

Im April hatte ich ja schon gesagt, dass es fuer das doch recht langwierige Patchen von Zonen Licht am Ende des Tunnels gibt.  Jetzt sind wir durch diesen Tunnel durch - sozusagen im vollen Sonnenschein   Mit dem Patch Nr. 119254-66 bzw. 11255-66 wird patchadd parallelisiert.  Der Grad der Parallelitaet ist in  /etc/patch/pdo.conf konfigurierbar, haengt jedoch auch von der Anzahl der tatsaechlich verfuegbaren CPUs ab.  Wie gross die Zeitgewinne sind, haengt natuerlich auch von der Leistungsfaehigkeit des IO-Subsystems ab.  Aber das ist ja nichts Neues, und wurde bezogen auf paralleles Patchen von Jeff Victor bereits beschrieben.  Dennoch - die Zeitgewinne sind erheblich, und Solaris ist wieder ein Stueckchen besser geworden.

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!

Oder vielmehr - Lange lebt Solaris

Solaris 9 wurde im Mai 2002 angekuendigt, das ist jetzt sieben (7) Jahre her.  Am 28.  April war das offizielle "End of Life Announcement", am 30.10.2009 ist also "Last Ship Date".  Damit ist Solaris 9 nach 7 Jahren in die erste Supportphase eingetreten.  Wenn es am 30.10.2014 den Status "End of Supported Life" bekommt, wird es 12 Jahre am Markt gewesen sein.  Die genauen Daten zu den einzelnen Phasen findet man hier, eine Uebersicht ueber den "Life Cycle" aller Solaris-Versionen hier.

Solaris 8 gibt es seit Februar 2000, nach etwas ueber 12 Jahren am Markt wird es am 31.3.2012 EOSL sein.  Die Details zu diesem Release gibt es hier.

Solaris 10 war am 5.3.2005 erstmalig verfuegbar.  Der frueheste Zeitpunkt fuer eine Vorankuendigung ist 4 1/2 Jahre spaeter, als fruehestens am 5.9.2009.  Dann waeren es noch 6 1/2 Jahre bis zum EOSL, also mindestens bis zum 5.3.2016.  Das waeren dann insgesamt 11 Jahre, die Solaris 10 am Markt gewesen sein wird - mindestens.  Denn die Vorankuendigung muss ja nicht zum fruehestmoeglichen Zeitpunkt kommen...

Solaris 8 - 12 Jahre
Solaris 9 - 12 Jahre
Solaris 10 - mindestens 11 Jahre

Das macht sonst keiner.  Wir mit Solaris schon - Solaris macht es uns moeglich.

(Wer einen Vergleich sehen will, kann z.B. auf Seite 6 einer Praesentation von Volker Wetter zum Thema SAP und Solaris nachsehen )

Seit gestern gibt es auf developers.sun.com eine eigene Seite fuer CMT Systeme.  Dort sind all die Dokumente verzeichnet, die man bisher mehr oder weniger muehevoll zusammensuchen musste.  Ein wenig Marketing ist sicher auch dabei, aber der Gedanke von "One Stop Shopping" wurde schoen umgesetzt.

Nebenbei kann ich nicht umhin zu bemerken, dass auch dieser mein Blog dort verzeichnet ist --- das ist schon ein wenig schmeichelhaft

Funktioniert hat es natuerlich bisher auch schon.  Aber fuer alle diejenigen, die ein offizielles Supportstatement brauchen, ist dieses nun verfuegbar.  MySQL ist in einer LDom supported.

Anfang der Woche war ich bei einem Kunden, um mal wieder das unmoegliche Moeglich zu machen und die Antwortzeit einer Transaktion eines Applicationservers zu beschleunigen.  Es ging um eine Java-Anwendung auf einer T5140, und normalerweise ist hier zwar durch GC-Optimierung der JVM der Durchsatz noch zu steigern, an den Antwortzeiten einer einzelnen Transaktion ist jedoch selten etwas zu gewinnen.  Das liegt einfach in der Natur der Dinge...  Anders hier:

Der erste Ansatz war natuerlich, erst einmal generisch sinnvolle Parameter zum Aufruf der JVM zu verwenden, wie sie sich z.B. erst kuerzlich wieder bei einem grossen Benchmark bewaehrt haben.  Was mich ja immer wieder wundert, ist warum auch nach ueber 10 Jahren Java immer noch "-server" so oft fehlt... Erstaunlicherweise war das Ergebnis jedoch schlechter als vorher!  Erst ein genauerer Blick auf die sonstigen, oft ja sehr vielfaeltigen Optionen auf der Kommandozeile der JVM half weiter:  Dort war ein "-Djava.compiler=NONE" zu finden.  Das Ersetzen von "NONE" durch "jitc" wirkte die Sorte Wunder, die es sonst kaum noch gibt:  Die Antwortzeiten halbierten sich, der Durchsatz liess sich vom bisherigen Maximum von 35 TPS auf 130 TPS steigern.  Wenn das nicht Spass macht!  Fast schade, dass so etwas nicht oefter vorkommt

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...

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...

CMT-Systeme sind eine ideale Virtualisierungsplatform.  Und Solaris Container sind die preiswerteste und effizienteste Virtualisierungstechnik.  Ein Pferdefuss dabei war bisher, dass das Patchen grosser Anzahl von Containern nicht gerade schnell war.  Hier ist endlich Abhilfe in Aussicht: Zonen koennen bald parallel gepatched werden.  Was das an Performance bringt, beschreibt Jeff Victor ein seinem excellenten Blog-Beitrag.

"Brauchen .... 1.000.000  gleichzeitig gehaltene TCP Verbindungen" war die erste aber nicht letzte interessante Information bei der Unterstützung der Schacholympiade in Dresden.  Die Zahl basiert auf dem Ansturm von geschaetzten 1 Million gleichzeitiger "Zuschauer". Um diesen Zahlen  weltweit gewachsen zu sein, hat Sun den Veranstaltern der Schacholympiade 2008 in Dresden zwei T5240 zur Verfuegung gestellt.  Damit wurde der gesamt Webverkehr bedient, der durch die Liveuebertragung der Partien ueber das Internet entstand.  Es war die erste Schacholympiade, die vollstaendig live im Internet uebertragen wurde. 

Derartige Schätzunge basieren zumeist ersteinmal auf reinen Annahmen zur Anzahl von Benutzern. Im Falle der Schacholympiade war der Wert bestimmt nicht zu Tief angesetzt, da ein stabieler und performanter Auftritt auch entsprechend mit "headroom" geplant werden will. Nun lässt sich nicht immer direkt von der Anzahl der Benutzer auf die gleichzeitig gehaltenen TCP-Verbindungen schliessen, in dem vorliegenden Fall war allerdings die Anwendung welche die Darstellung bei den Zuschauern übernimmt entsprechend hinsichtlich des Netzwerkverkehrs optimiert. Zudem spielt auch noch die Antwortszeit auf einen Request eine signifikante Rolle, dazu aber später. 

Technisch ist das Hauptproblem bei einem solchen Webauftritt die Anzahl der gleichzeitig zu haltenden TCP-Verbindungen.  Ein einzelner TCP-Stack kann zwar rein theoretisch eine fast unbegrenzte Anzahl an eingehenden Verbindungen gleichzeitig halten, allerdings wird die Verwaltung der Sessions als auch der einzelnen Verbindungen zunehmend aufwändiger und damit langsamer. Je langsamer der Zugriff auf die einzelnen Sessiondaten, desto länger braucht der einzelne HTTP-Request innerhalb der TCP-Verbindung, desto mehr TCP-Sessions stehen am System an, desto.... will man mehr, benoetigt man mehrere TCP-Stacks (siehe auch die Warteschlangentheorie) .  Um hier Abhilfe zu schaffen bleibt eigentlich nur übrig, den Clients mehr TCP-Stacks zur Verfügung zu stellen. Das wird in solchen Faellen z.B. durch Reverse-Proxies erledigt, die dem eigentlichen Webserver vorgeschaltet werden.  Es könnten auch mehrere Web-Server zum Einsatz kommen, allerdings haben die Proxies diverse andere Vorteile wie z.B. die Verwaltung von grösseren Content-Caches als es dem normalen Web-Server möglich ist.

Um ausreichend viele solcher Proxies konfigurieren zu koennen, wurden die beiden T5240 mit je einer LDom mit 12 Cores konfiguriert.  In diesen beiden LDoms liefen jeweils 9 Solaris Container mit dedicated IP Stacks, womit dann ausreichend viele IP Stacks verfuegbar waren.  Die notwendigen Netzwerkverbindungen wurden ueber das "interne" Netzwerk der LDoms geliefert - extern waren pro Server eine 10GBit Ethernetverbindung im Einsatz.  Insgesamt sah die Konfiguration einer der beiden T5240 also so aus:

• Eingesetzte Software:




• JES Proxie- und Webserver


• Solaris 10


• ZFS


• LDoms 1.0.3

• 960 Millionen Requests in 1.5 Wochen


• 500000 eindeutig identifizierbare Hosts


• Zusaetzlich natuerlich viele Zugriffe ueber die Proxies der grossen ISPs


• Peak Leistung:




• 11000 neue TCP-Sessions pro Sekunde


• 200000 gehaltene Verbindungen


• mittlere Antwortzeit 20ms




• Hier noch ein Schnappschuss der Routerstatistiken von der Turnierwoche:

Die Auslastung der Server war dabei moderat:

• Proxies: 15%  (96 Strands)


• Service Domains: 6% (32 Strands)

Die erfreulich geringen Antwortzeiten waren ein direkter Erfolg der Gesamtarchitektur.  Die JES Proxie-Server hielten ihren Cache in einem ZFS Filesystem der LDom.  Der ARC des ZFS hatte nach einer gewissen Anwaermphase fast den gesamten Content gecached, so dass ein Grossteil der Anfragen direkt aus dem RAM der Server beantwortet werden konnte - es wurde also Antwortzeit durch RAM "gekauft".  Damit wurde es moeglich, die Anzahl der zu haltenden Verbindungen deutlich unter dem vorab geschaetzen Wert von 1 Million Sessions zu halten.

Ein sich ankuendigender Engpass war die Last auf dem einen VSwitch, der die Container mit virtuellen Netzwerkanschluessen versorgte und den gesamten Netzwerkverkehr bewaeltigen musste.  Hier konnte auf dem einzelnen Strand eine Auslastung von bis zu 80% beobachtet werden.  Waere die Last weiter gestiegen, haette die Konfiguration eines zweiten VSwitches und die Verteilung der vnet Ports auf beide VSwitches natuerlich schnell Abhilfe geschaffen.

Die Veranstalter waren nach Abschluss des Turniers hoch zufrieden mit der Leistung der Maschinen, die einen fluessigen und stabilen Webauftritt lieferten.  Dass dieser Webauftritt mit nur 2 Servern in insg. 4 Hoeheneinheiten realisiert werden konnte zeigt sehr anschaulich, wie effizient man mit Solaris, Containern, LDoms und ein wenig CMT-Hardware einen leistungsfaehigen Webauftritt realisieren kann.