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

Dienstag Feb 24, 2009

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

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

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.

Dienstag Okt 14, 2008

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

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

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


Zu finden auf dem neu gestalteten Blueprint Portal.

Mittwoch Sep 24, 2008

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.

Montag Sep 22, 2008

CMT ist nicht beschränkt auf Niagara.  Auch ROCK ist eine CMT CPU.  Inzwischen gibt es einige Veröffentlichungen über ROCK.  Hier zwei lesenswerte Links:


Mittwoch Jul 30, 2008

Kuerzlich hatte ich Anlass, mir die Leistungssteigerung von UltraSPARC T1 auf UltraSPARC T2 noch einmal anzusehen.  Hier ein paar Ergebnisse - auch wenn die Werte natuerlich "alt und bekannt" sein sollten.







































Benchmark UltraSPARC T1 UltraSPARC T2 Einheit Skalierungsfaktor
SPECweb2005 16407 41847 SPECweb2005 2,55
SPECjbb2005 74365 192055 bops 2,58
Lotus R6iNotes 16061 36240 NotesMark 2,26
SAP SD2 5530 10950 SAPS 1,98

Rechtlichs: Die offiziellen Benchmark-Ergebnisse fuer die genannten SPEC-Benchmarks sind verlinkt.  Die SAP-Ergebnisse sind auf der Benchmark Seite von SAP zu finden, die Zertifikate haben die Nummern 2007051 und 2007059.  Die Lotus-Ergebnisse finden sich auf notesbench.org.

Donnerstag Jul 24, 2008

Immer wieder werde ich gefragt, ob sich die CMT-Server denn auch fuer Datenbanken, insbesondere Oracle, eignen.  Meine Antwort darauf ist schon fast stereotyp: "Es kommt auf die Last an."  Ist die Last gut parallelisiert oder parallelisierbar, und sind die Antwortzeiten einer einzelnen Transaktion nicht das kritische Erfolgskriterium, dann sind die Server ideal.  So wie bei jeder anderen durchsatzorientierten Anwendung :-)


Wie man einige Standard-Szenarien bei Oracle ohne grossen Aufwand parallel, und damit fuer CMT Systeme ideal, ausfuehren kann, hat mein Kollege Glenn Fawcett in einer Serie von Blogeintraegen beschrieben.  Sie sind es wert, gelesen und ggf. als Bookmark gespeichert zu werden. 

Dienstag Jul 15, 2008

Endlich ist es geschafft! Seit heute werden LDoms als Knoten im SunCluster unterstuetzt. Ja, richtig, Gast-Domains. Die Details gibt es


  • in einem Blog von Ashutosh Tripathi

  • in den Release Notes der aktuellen Version von SunCluster.  Dort gibt es auch anschauliche Bildchen, die die verschiedenen Szenarien darstellen.


Hohe Verfuegbarkeit!

Donnerstag Jul 03, 2008

Nicht, dass wir das nicht alle schon lange wuessten.  Aber ab und zu gibt es lesenswerte Blogs oder Artikel, die diese Wahrheit erneut aussprechen und die Folgen fuer die Entwickler und die Programmiermodelle klarmachen.  Jetzt gibt es einen Blogeintrag von Intel, der den Entwicklern den "Unwillkommenen Rat" gibt, sich nicht mit 4, 8 oder 16 Cores abzugeben, sondern gleich richtig anzufangen und sich auf hunderte von Threads einzustellen.

In einem Artikel bei ars technica wird dazu noch vermerkt:  "Intel and AMD alike have been saying for several years that the days of "free" performance scaling from faster processors are behind us".  Sun sagt das auch schon eine ganze Weile - und baut CPUs mit 64 Threads ;-)

Das Parkinsonsche Gesetz, zitiert aus Wikipedia: "Arbeit dehnt sich in genau dem Maß aus, wie Zeit für ihre Erledigung zur Verfügung steht - und nicht in dem Maß, wie komplex sie tatsächlich ist. (Work expands (so as) to fill the time available for its completion.)"

Ein Kollege von mir hat sich vor kurzem recht eindeutig zu einem Phaenomen geaeussert, das mir immer wieder begegnet: Code, der wenig gut skaliert, oder zumindest trotz eigentlich guter Skalierbarkeit Elemente hat, die an der Singlethread-Leistung einer CPU haengen.  Er meinte dazu: "A T2 is basically an E10000 replacement.  Much of what does not run adequately on an E10000 is simply "bad code".  Coincidentally, a lot of what customers want to scale up is bad code that was prototyped on a fast notebook- or workstation-class system with reckless OO programming. This is one modern manifestation of Parkinson's Law, and I believe a primary reason for customer attraction to very-fast single-thread CPUs."

Auf gut Deutsch: Wenn ein Entwickler auf seiner Entwicklungsplatform (dem Notebook...) Singlethread-Leistung im Ueberfluss vorfindet, wird er sie laut Parkinsonschem Gesetz auch nutzen, unabhaengig davon, ob die so entstehende Software danach in der Lage ist, die Resourcen des Produktivsystems effektiv zu nutzen.  Als Ausweg aus dieser Situation bietet sich eine andere Sichtweise an:  Ein Programm besteht dann aus "gutem Code", wenn es auf effizienten CMT-CPUs gut skalierend laeuft.

Will man also Platzbedarf, Strom und Kuehlung in den Griff bekommen, sollte man von Entwicklern fordern, dass die entwickelte Software sich fuer CMT eignet.  Wendet man das Parkinsonsche Gesetz auch hier wieder an, laesst man die Entwickler am besten gleich auf CMT-Maschinen entwickeln ;-)

Freitag Jun 27, 2008

Ja, richtig, fuer HPC :-)  Die RWTH Aachen hat die UltraSPARC T2 ja ebenfalls schon als durchaus brauchbar befunden.  Aber jetzt gibt es in Kanada einen Cluster, der im Endausbau fast 10000 Threads fuer ca. 130 Forschungsgruppen in Kanada zur Verfuegung stellt - auf Basis von UltraSPARC T2 Plus.  Die Begruendung fuer die Hardware-Entscheidung: Durchsatz-Anforderungen sowie bessere Effizienz - sowohl innerhalb der CPU als auch im RZ.  Nachahmenswert, finde ich ;-)

...ist nicht einfach.  Das weiss jeder, der es schon einmal versucht hat.  Und nachdem es inzwischen jedem klar ist, dass Leistungssteigerung nur durch Parallelisierung zu erreichen ist, beschaeftigen sich immer mehr auch grosse Gremien mit der Frage, wie man hier sowohl in Forschung als auch in der "Produktion von Software" sinnvoll vorgehen kann.  Ein interessanter Blog zu diesem Thema ueber einen Workshop mit dem Titel "from Petascale to Exascale" findet sich hier.  Der Author geht dabei ganz klar davon aus, dass die Zukunft den massiv-parallelen Anwendungen gehoert - und erwartet heterogene Chips, die z.B. Netzwerk, Crypto, Bildverarbeitung und optische Interconnects auf einem Chip integrieren.  Klingt irgendwie vertraut ;-)

Nebenbei bemerkt: Auch Microsoft hat die Multicore-Herausforderung erkannt...