Ich werde gelegentlich von den unterschiedlichsten Leuten immer wieder mal unterschiedliche Fragen zum Thema Performance auf Solaris gefragt. Zuletzt kam eine Diskussion im Sun Userforum
Sonnenblen.de auf, in der jemand wissen wollte, was eigentlich die Werte für den
load average einer Maschine aussagen, wie sie z. B. von dem Kommando
uptime ausgespuckt werden.
Ich werde hier jetzt nicht anfangen, eine Abhandlung über Performance-Messung eines Unix-Systems zu schreiben. Aber es gibt eine Menge Links zu den Grundlagen des Solaris-Kernels und es gibt auch Werkzeuge, die helfen, die passenden Zahlenwerte zu sammeln, um ein Performance-Problem verstehen zu können.
Für Solaris <10, genau genommen sogar <8 gibt es ein recht gutes Buch zum Thema:
Adrian Cockcroft, Richard Pettit
Sun Performance and Tuning: Java and the Internet (2nd edition, 1999)
http://www.pearsonhighered.com/educator/academic/product/0,3110,0130952494.html,00.html
Das Buch müsste z. B. bei Amazon US noch neu zu kriegen sein. In dem Buch wird recht schön beschrieben, wie welche Messwerte zusammen spielen und worauf man schauen muss, wenn ein bestimmter Wert aus der Reihe tanzt. Oft genug darf nämlich ein einzelner Wert auch mal länger gehörig aus der Reihe tanzen, solange es den anderen Parametern allen gut geht.
In dem Buch ist außerdem die Rede von einem
SE Toolkit. Das ist eine Sammlung nützlicher Scripts und Tools, um der Performance eines Systems auf den Grund zu gehen. Es gibt bunte graphische Outputs und man bekommt Hinweise, wo man tunen kann oder sollte. Das SE Toolkit ist natürlich auch unabhängig vom Buch zu bekommen.
Der Buchautor Adrian Cockroft ist nach wie vor im Performance-Bereich unterwegs und schreibt darüber gelegentlich in seinem
Blog.
Wer noch weiter zurück gehen muss, sei auf das sog.
Solaris White Album verwiesen. Das ist im Prinzip eine Sammlung von Whitepapers und technischen Aufsätzen anlässlich verschiedener Konferenzen, in denen die Architektur des Kernels und kernelnaher Subsysteme für Solaris 2.x beschrieben sind. Es gibt dazu einen
Blogeintrag, der viele der Papers verlinkt.
Für Solaris 8 gibt es dann das erste
Solaris Internals Buch, das im wesentlichen Kernel-Strukturen beschreibt, und das sehr ausführlich:
Jim Mauro and Richard McDougall
Solaris Internals (2000)
http://www.sun.com/books/catalog/mauro_mcdougall.xml
Irgendwann zwischen Solaris 7 und Solaris 10 hat das Benchmark Center von Sun in Langen eine
ToolsCD heraus gegeben mit einem Sammelsurium an unterschiedlichsten Werzeugen für Benchmarks und Performance-Untersuchungen. Die CD ist nach wie vor bei Sun
zum Download verfügbar. Zur CD gibt es auch einen
Post auf opensolaris.org, wo die ToolsCD 3.0 angekündigt wird. Da stehen dann auch ein paar mehr Details zur CD und zu den darauf enthaltenen Werkzeugen. Und es gibt auch eine
Präsentation dazu, wo die CD ausführlicher vorgestellt wird.
Etwa in die selbe Zeit wie die ToolsCD fällt eine Präsentation von Uli Gräf zu üblichen Performance-Probleme wie sie bei Kunden damals häufig vorkamen. In der Präsentation werden auch Lösungsansätze aufgezeigt. Mittlerweile evangelisiert Uli ja überwiegend mit OpenSolaris, insbesondere ZFS. Im Archiv des LinuxTags gibt es besagte Präsentation von Uli
zum Download.
Und damit sind wir dann bei Solaris 10 angelangt. Das bringt mit DTrace zwar ein sehr umfangreiches Instrumentarium mit, aber auch dazu muss man erstmal verstehen, was man messen will. Natürlich gibt es auch hier die passende Literatur:
Richard McDougall and Jim Mauro
Solaris Internals, Second Edition: Solaris 10 and OpenSolaris Kernel Architecture (2006)
http://www.sun.com/books/catalog/solaris_internals.xml
Und ja, das ist die zweite Auflage des oben bereits genannten Buches. Allerdings stark erweitert.
Richard McDougall, Jim Mauro and Brendan Gregg
Solaris Performance and Tools: DTrace and MDB Techniques for Solaris 10 and OpenSolaris (2006)
http://www.sun.com/books/catalog/solaris_perf_tools.xml
Passend zu den Büchern gibt es auch ein
Solaris Internals Wiki.
Bereits genannt habe ich DTrace als Werkzeug. DTrace ist sehr mächtig, aber auch sehr umfangreich und gerade für Einsteiger nicht eben leicht zu überblicken. Die "offizielle" Dokumentation dazu ist der
Solaris Dynamic Tracing Guide. Ähnlich dem oben genannten SE-Toolkit gibt es auch für DTrace eine Sammlung fertiger Scripts, die man entweder out of the box verwendet oder als Ausgangspunkt für eigene Modifikationen nimmt. Das Ding heißt dann auch
DTrace Toolkit.
Das Bigadmin-Portal bei Sun bietet auch eine eigenen
Einstiegsseite zu DTrace mit allerlei interessanten und hilfreichen Links dazu. Und es gibt im Bigadmin-Portal auch eine generelle Seite zu
Solaris Performance. Übrigens greifen eine ganze Reihe der Statistik-Werkzeugen in Solaris 10 auf DTrace-Mechanismen zurück (lockstat, plockstat, vmstat, mpstat...).
Wer gerne mal so zwischendurch ein bisschen auf dem laufenden bleibt, was sich in der Performance- und Benchmarkingwelt so tut, für den habe ich drei Blogs aus dem Sun-Universum parat:
BMSeer liest sich gelegentlich wie Sun Propaganda (höher, schneller, weiter). Die Berichte taugen immerhin, um herauszufinden, wo IBM seine Schwächen hat. Es gibt umgekehrt auch einen ähnlichen Blog von IBM. Der ist aber noch viel mehr gehirngewaschen, deshalb ist er wieder aus meinem RSS-Reader gefallen. Brendan Gregg macht im Moment viel mit dem Storage 7000 rum, einigen hier sollte er aus dem Video bekannt sein, wo er in ein JBOD rein brüllt und mittels DTrace zeigt, dass die Latenz bei denjenigen Platten deutlich ansteigt, die durch das Brüllen in Vibration versetzt wurden. Generell lohnt sich, mal auf
den Sun-Blogs nach Stichworten rund um Performance, DTrace etc. zu suchen. Ich kenne keinen anderen Hersteller aus der IT-Welt, wo so viele Engineers so exzellente, hochwertige Blogartikel abliefern.
Und wer gerne mal was von außerhalb Suns lesen will, der kann sich ja mal bei
SPEC umschauen. Die veröffentlichten Ergebnisse zu SPECfp und SPECint (Detailberichte, beides z. B. aus SPEC2000) sind gelegentlich nicht uninteressant. Darin müssen nämlich z. B. auch Compileroptionen veröffentlicht werden, mit denen die Benchmarks gefahren werden. Weil Benchmarking eigentlich Voodoo ist, ist es für einen aussagekräftigen Vergleich der Ergebnisse unabdingbar, sich auch die jeweils konkrete Messmethode mit anzuschauen.
So, viel Material für die Osterwoche. Ich wünsche viel Spaß bei der Sekundärliteratur
:-)
| 
