Montag Dez 05, 2011

Hard Partitioning!

Gute Nachrichten fuer alle Nutzer von Oracle VM Server fuer SPARC (aka LDoms) mit Oracle Software:  Seit 2. Dezember gelten LDoms als "Hard Partitioning".  Damit ist es moeglich, nur die tatsaechlich benoetigten Kerne eines Servers fuer Oracle-Software zu lizenzieren.  Auskunft ueber die Details bekommt man bei License Management Services.

Donnerstag Okt 28, 2010

Ist T3 nun doppel so schnell oder halb so teuer ?

Eigentlich ist es ja unfein, andere die Arbeit machen zu lassen und dann nur darueber zu berichten.  Diesmal jedoch bin ich einfach dankbar, dass jeman anderes die etwas muehsame Arbeit der Preis- und Leistungsvergleiche uebernommen hat, und verweise deswegen gerne auf einen Artikel im "Register", in dem die neuen T3 Systeme in Bezug auf Preis und Leistung mit ihren Vorgaengern verglichen werden.  Bleibt eigentlich nur noch die Frage: Ist T3 nun doppelt so schnell oder halb so teuer? Was fuer eine angenehme Frage!

Dienstag Sep 21, 2010

Keine Entschuldigung fuer keine Sicherheit

Schon seit der UltraSPARC T2 gibt es eigentlich keine Entschuldigung mehr, einen Web- oder Applicationserver nicht mit sicherem SSL zu betreiben.  Die in die CPU integrierte Crypto-Beschleunigung, die kostenfrei verwendet werden kann, ermoeglicht schon seit Jahren Sicherheit per SSL.  Mit der neuen T3 CPU wurden nicht nur die moeglichen Algorithmen modernisiert.  Auch die Anleitungen, wie dieses Feature zu nutzen ist, wurden auf den neuesten Stand gebracht.  Hier die ersten beiden - mehr kommt vermutlich in Kuerze:


Frohes Verschluesseln!

Dienstag Jun 01, 2010

Eignung einer Anwendung fuer CMT

CMT-CPUs gibt es ja nun schon eine ganze Weile.  Und die Tatsache, dass diese CPUs fuer parallele, durchsatzorientierte Anwendungen entwickelt wurden, wurde auch schon haeufig diskutiert und beschrieben.  Die Frage, ob eine spezielle Anwendung nun aber geeignet ist oder nicht, bleibt bestehen und wird mir immer wieder gestellt.  Ich will hier versuchen, ein paar Hilfestellungen zu geben, wie man diese Frage selbst beantworten kann.


Erstes und letztlich wichtigstes Kriterium sind immer die Antwortzeiten der Anwendung.  Sind diese zufriedenstellend, ist die Anwendung CMT-geeignet.  Sind sie es nicht, und liegt der Grund dafuer in der CPU und nicht etwa in der Latenz sonstiger Komponenten (remote Database, etc.) muessen andere CPU-Architekturen getestet werden.

Darueber hinaus ist es natuerlich von Vorteil, wenn die Anwendung multi-threaded ist, und die einzelnen Threads der Anwendung auch wirklich \*parallel\* Arbeit verrichten.  Nur dann kann die Anwendung eine CMT-CPU auch wirklich auslasten. Dabei ist es wichtig zu verstehen, dass Server-Auslastung niemals als Kriterium fuer gute Anwendungsleistung gelten kann.  Diese kann nur mit Anwendungs-Mitteln festgestellt werden, indem man den Durchsatz oder die Antwortzeiten oder beides misst.  Server- oder CPU-Auslastung kann lediglich ein Hinweis dafuer sein, ob die verfuegbaren Resourcen auch tatsaechlich genutzt werden, um Anwendungsleistung zu liefern.


Um festzustellen, ob eine Anwendung multi-threaded ist, und die Threads auch parallel beschaeftigt sind, kann man bspw. das Tool threadbar verwenden.  Alternativ kann man das Kommando "prstat -L" verwenden.  Dabei werden die einzelnen Threads der Prozesse nach Ihrer CPU-Belastung sortiert angezeigt.  Wuenschenswert sind hier viele Threads, die mehr als 0% CPU-Auslastung anzeigen.  Wichtig ist jedoch auch festzustellen, ob einzelne Threads durch die Single-Thread Leistung der CPU  begrenzt wird.  Dies kann man naeherungsweise ebenfalls mit prstat beobachten.  Die "%CPU"-Spalte von prstat  bezieht sich auf alle im System aktiven CPUs.  Bei einer T5120 sind das bspw. 64.  D.h. dass ein Strand 1/64, oder ca.  1.5% entspricht.  Wichtig ist nun, dass kein einzelner Thread der Anwendung dauerhaft 1.5% der CPU belegt.  Dies  waere ein Hinweis darauf, dass die Prozessleistung durch die Single-Thread Leistung begrenzt wird.


Diese Hinweise und ein paar Beispiele dafuer habe ich in einer kleinen Praesentation zusammengefasst.  Vielleicht hilft es ja dem einen oder anderen ;-)

Freitag Jan 22, 2010

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.

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

Donnerstag Apr 10, 2008

Da waren's ploetzlich 128...

Gestern wurden die ersten Systeme mit UltraSPARC T2 Plus CPU angekuendigt.  Oder anders gesagt, es wurde der Grundstein fuer die weitere Thread-Vervielfaeltigung gelegt: Vorgestern 32 Threads, gestern 64 Threads, heute 128 Threads, und es duerfte nahe liegen zu vermuten, dass bei 128 noch nicht Schluss ist...

 Die Details der Ankuendigung gibt es hier:

  • 128 Threads in einer Hoeheneinheit: T5140
  • 128 Threads in zwei Hoeheneinheiten: T5240

Wer mag, kann sie mittels Try&Buy selbst testen :-)

Donnerstag Mrz 06, 2008

$20000 zu Gewinnen!

Wo sind die besten Parallel-Programmierer?  Sie sollten das hier lesen! Im Rahmen des Community Innovation Awards Programms von Sun werden unter Anderem $20000 fuer die beste Anpassung einer single-thread Anwendung an die CMT-Architektur ausgelobt.  Mit "Adoption" ist wohl am ehesten "Portierung" oder "Neu-Implementierung" gemeint.

Schade, dass ich kein Programmierer bin.  Aber dann auch wieder nicht so schade, denn Sun Mitarbeiter duerfen natuerlich nicht mitmachen.  Ich hoffe ja sehr, dass es viele gute Einreichungen geben wird.  Wer weiss, vielleicht ist das ja nicht nur ein Programmierwettbewerb... ;-)

Mittwoch Okt 10, 2007

Und jedem Anfang wohnt ein Zauber inne

Zwei Stufen Es muß das Herz bei jedem Lebensrufe
Bereit zum Abschied sein und Neubeginne,
Um sich in Tapferkeit und ohne Trauern
In andre, neue Bindungen zu geben.
Und jedem Anfang wohnt ein Zauber inne,
Der uns beschützt und der uns hilft, zu leben.


Aus "Stufen" von Hermann Hesse



2005 brauchten Server schon 1.2% des Stroms der USA. Seitdem hat sich der Traffic im Internet versechsfacht. Sparsamere Server müssen her - doch Rettung naht. Denn eins haben alle Internet-Anwendungen gemein: Sie reden mit vielen Benutzen gleichzeitig, und passend parallele Rechner können glücklicherweise sehr ressourceneffizient arbeiten.

Die erste Generation solcher Rechner, CoolThreads Server mit acht Kernen und 32 Threads in einer CPU, sind seit Ende 2005 bei vielen Anwendern erfolgreich im Einsatz. Gestern kam die zweite Generation auf den Markt: Noch stärker. Noch sparsamer. Noch cooler.

Diese CoolThreads Server sind wahrlich eine neue "Stufe" in der Server-Evolution. Jedoch: Auf 64 Threads, Fließkomma, Verschlüsselung, Virtualisierung, Mulithreaded 10GBE-Netzwerk - Darauf muß man sich einlassen, eine Bindung eingehen, damit der Zauber gelingt, möglichst viele Benutzer mit möglichst wenig Ressourcenaufwand zu bedienen.

Dabei soll dieses Blog helfen. Der Name "Kernspalter" ist natürlich kein Zufall: Denn dieses Blog ist nicht mein Blog (ich bin Rolf Kersten und vermarkte die ganzen Kerne), sondern das Blog der Sun CoolThreads Community in Deutschland. Hier werden die Techniker schreiben, und jedes Detail der neuen CoolThreads Server mit all ihren Kernen haarspalterisch analysieren. Es gibt also nicht nur weiße Kaninchen zu sehen, sondern die Zaubersprüche selbst. Und deswegen nennen wir das ganze ab sofort auch nicht mehr mit seinem Marketingname "CoolThreads", sondern dem technischen Namen "CMT" (Chip-Multi-Threading), OK?

Zum Einlesen in das Thema "CMT Next Generation" empfehle ich die "CMT comes of age" Blogsammlung mit fast so vielen Zaubersprüchen wie Threads im UltraSPARC T2. Viel Spaß!
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