Montag Jun 07, 2010

prstat und microstate accounting

Man lernt nie aus.  Als Reaktion auf meinen letzten Blogeintrag bekam ich den Hinweis, bei prstat doch die Option "-m" zu verwenden, um mich von den traegen und unzuverlaessigen Durchschnittswerten zu befreien.  Was dahinter steckt, wollte ich natuerlich genauer wissen, und wurde bei Eric Schrock fuendig.  Hier eine kurze Zusammenfassung:


Die herkoemmliche Ausgabe von prstat (und einigen anderen Kommandos) gibt Durchschnittswerte aus, die auf regelmaessigen Stichproben beruhen.  Je hoeher der CPU-Takt, desto hoeher ist auch die Wahrscheinlichkeit, dass einige Ereignisse selbst bei langen Messintervallen von keiner Stichprobe erfasst werden - die Ergebnisse werden immer unpraezieser, je hoeher der CPU-Takt und je kuerze die Ereignisse.  Bei Microstate-Accounting werden die Ereignisse direkt "am Objekt" erfasst.  Durch einige Aenderungen in der Implementierung wurde dies in Solaris 10 ausreichend effizient, um staendig aktiv sein zu koennen.  Verwendet man nun bspw. bei prstat diese praezieseren Werte, erscheint ein CPU-Fresser tatsaechlich sofort mit 100%.  Damit eruebrigt sich die Umrechnung der CPU-Anzahl in Auslastungs-Anteile.  Ein von der Singlethread-Leistung begrenzter Prozess wird so viel schneller und einfacher sichtbar.


Auch die Praesentation habe ich natuerlich entsprechend angepasst.


Vielen Dank fuer den Hinweis!  An solchen Dingen merke ich, dass ich Kommandos wie prstat schon viel zu lange (und durchaus erfolgreich) verwende.  Dieses neue Feature ging, aehnlich wie in dem Eintrag von Eric erwaehnt, auch bei mir wegen ZFS, Containern, SMF etc. unter.

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

Threadbar

Dieses Tool ist einen Blogeintrag ueber den Blogeintrag wert.  Wer kennt ihn nicht, den guten alten perfbar? Thrbar (eigentlich wohl Threadbar) ist ein Perfbar fuer die Threads eines Prozesses.  Damit wird es endlich moeglich, den Unterschied zwischen einem aktiven und einem existierenden Thread zu visualisieren.  Warum mussten wir eigentlich bis 2010 auf dieses Tool warten?  Dabei ist die Idee wirklich naheliegend.  Aber so ist es ja oft mit guten Ideen - wenn sie mal bekannt sind, schlagen wir uns alles ans Hirn und wundern uns, warum wir da nicht selbst schon lange darauf gekommen sind.  Deswegen meine doppelt ausgesprochene Hochachtung an Rickey Weisner fuer dieses Tool!

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