Donnerstag Mai 14, 2009

Lang lebe Solaris!

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 ;-) )

Mittwoch Mai 13, 2009

CMT auf developers.sun.com

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 ;-)

Dienstag Mai 12, 2009

MySQL jetzt auch mit offiziellem Support in LDoms

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.

;-)
Das Statement gibt es hier.

Freitag Mai 08, 2009

Es gibt ihn doch, den "Performance=ON" Schalter

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 ;-)

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

Donnerstag Apr 02, 2009

Paralleles Patchen von Zonen - Licht am Horizont

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.

Donnerstag Feb 26, 2009

LDoms und Container auf der Schacholympiade

"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


Mit dieser Archtiktur wurde im Laufe der Veranstaltung einiges geleistet:


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

Montag Feb 23, 2009

Oracle jetzt in LDoms supported

Lange erwartet, ist er nun da - der LDoms Support von Oracle.  Sowohl Single Instance als auch RAC sind seit gestern von Oracle fuer den Betrieb in LDoms (1.0.3 oder höher) freigegeben.  Noch sind LDoms nicht als "Hard Partition" im Sinne der Lizenzberechnung anerkannt, aber das ist nur eine Frage der Zeit.  Und schliesslich sind Solaris Container schon lange hierfür akzeptiert, so dass man als Übergangslösung auch einen Container in der LDom verwenden kann...


Die Supportstatements von Oracle findet man z.B. hier:
http://www.oracle.com/technology/products/database/clustering/certify/tech_generic_unix_new.html
oder in Metalink.

Mittwoch Okt 29, 2008

Ein paar Gedanken zu Softwarequalitat

In einer Diskussion ueber den Zusammenhang zwischen der Anzahl der Patches fuer ein Produkt und die Qualitaet dieses Produktes stiess ich auf ein bemerkenswerts Argument:



  1. Die Anzahl der geloggten Bugs und RFEs und die Anzahl veroeffentlicher Patches ist kein Indikator fuer Qualitaet.  Sie sind vielmehr Indikatoren fuer Aktivitaet.

  2. Einige Studien zur Softwarequalitaet zeigen, dass alte Software die zuverlaessigste Software ist.  Oder, andersherum, neue Software hat tendenziell mehr Bugs als alte Software.  Oder, letztendlich, bei alter Software gibt es keine Aktivitaet mehr, und daher auch keine Innovation.

So gesehen sind LaTeX und VMS sehr zuverlaessige Softwareprodukte.  Solaris 10 und OpenSolaris sehr innovative.  Was nicht bedeutet, dass sie nicht dennoch zuverlaessig waeren :-)

Mittwoch Okt 22, 2008

Hardware Crypto Support fuer SSH

Seit es die Cryptoeinheiten der T2 CPUs gibt, wird immer wieder nach Support in SSH/OpenSSH gefragt.  Endlich ist es soweit!  Mein Kollege Jan Pechanec hat die notwendigen Aenderungen in den Code von OpenSSH eingebracht.  Diese sind in Nevada build 99 verfuegbar, an einem Backport fuer Solaris 10 wird derzeit gearbeitet.  Die Details beschreibt Jan in einem Blogeintrag.


Weitere Details zur Cryptoeinheit und wie sie verwendet wird, sammelt Lawrence Spracklen auf einer Seite bei wikis.sun.com.   Diese kann ich nur empfehlen.

Montag Okt 13, 2008

Aus zwei mach vier

Gestern wurde die neue 4-Sockel Maschine T5440 vorgestellt.  Im April war es die T5240 mit zwei Sockeln.  Nun stehen uns mit 4 CPUs mit je 8 Kernen mit je 8 Strands insgesamt 256 Strands zur Verfuegung - mit der entsprechenden Leistungsfaehigkeit.  Dass es da schon schwierig wird, diese Leistung auch zu nutzen, wurde uns bei den Beta-Tests, die es auch diesmal wieder gab bereits deutlich.  Und zwar nicht etwa, weil die Software nicht so gut skaliert, sondern weil es schwierig ist, genug Last zu finden :-)


In einem Fall gingen uns einfach die Lasttreiber aus - es waren nur Loadrunner-Lizenzen fuer 1500 Benutzer vorhanden, und die reichten bei der Datenbank-Anwendung gerade mal fuer 8% CPU-Auslastung.  Die Leistung der Anwendung war dabei natürlich auf dem geforderten Niveau.


Auch bei Strato, einem bekanntermaßen erfolgreichen Anwender der CMT Technologie, war eine T5440 vor Ort.  Das Ergebnis: Eine T5440 ist einfach zu leistungsstark...


"The system was so fast we really had problems to utilize all available
CPU power. Even one of those systems would be fast enough as a pop or
imap server for all our customers, so we had to use it as an http server
 (we are still using old apache 1.3, which does not scale as good as
apache 2.x). So in the future we will have to think about zones or ldoms
to break these large boxes into smaller units that are easier to manage
for us"


Diese Erkenntnis werden sicher auch viele Andere noch haben: Um eine 4-Sockel CMT Maschine voll auszulasten benoetigt man oftmals mehr als nur eine Anwendung.  Und falls man diese nicht gemeinsam im selben Solaris betreiben will oder kann, bieten sich natuerlich Zonen oder LDoms als Virtualisierungsmoeglichkeiten an.  Gut, dass die Maschine auch ausreichen viel RAM unterstuetzt!


Eine Uebersicht weiterer Blogs zur Einfuehrung gibt es bei meinem Kollegen Allan Packer.

Freitag Okt 10, 2008

Unerwartete Parallelisierung - Threads all ueberall

SPECint2006 ist, anders als der auf Skalierung setzende SPECint_rate2006 ein CPU-Benchmark, der die Singlethread-Leistung einer CPU misst.  Doch seit auch Intel und AMD erkannt haben, dass Taktfrequenzsteigerungen keine Leistungssteigerungen mehr bringen, wird in den Entwicklungsabteilungen der Compilerbauer intensiv, und offenbar erfolgreich, an den Parallelisierungsmoeglichkeiten der Compiler gearbeitet.  Und diese Arbeit bringt nun erste Fruechte, zu sehen an den neuesten Ergebnissen von SPECint2006.  Mein Kollege Lawrence Spracklen hat sie untersucht.  Sein Fazit: "So much for single-threaded performance improvements :-)"  Mein Fazit: Die Einsatzgebiete von CMT-Technologie werden durch die Kombination dieser Entwicklung mit der zunehmenden Verbreitung paralleler Programmiertechniken immer universeller werden.  Und daß sich auch bei diesen Programmiertechniken einiges tut, kann man an der baldigen Verfuegbarkeit von Transactional Memory sehen...

Donnerstag Okt 02, 2008

LDoms IO Best Practices

Es gibt einen neuen Blueprint zum Thema LDoms und Netzwerk, insbesondere hochverfuegbaresNetzwerk.


Zu finden auf dem neu gestalteten Blueprint Portal.

Mittwoch Sep 24, 2008

Netzwerkperformance, Memoryperformance und wie sie zusammenhaengen koennen

In Solaris 10 update 6 wird der nxge Treiber (fuer 10GBit Ethernet) "Software Large Segment Offload" unterstuetzen.  Damit wird der Netzwerk-Durchsatz erhoeht, und gleichzeitig die hierfuer noetige CPU-Last verringert.  Welche Leistung damit erreichbar wird, ist im Blog von Pure See nachzulesen.


Interessantes Detail dabei ist, dass der Netzwerkperformance hierbei auch von den verwendeten DIMMs abhaengt.  Die Memoryleistung bei 4GB DIMMs ist deutlich besser als bei 2GB DIMMs, was der Netzwerkleistung direkt zugute kommt.  Andere Anwendungen, die Memorybandbreite benoetigen, profitieren natuerlich genauso hiervon.

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