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.

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