Kapitel 18 Der Provider lockstat

Der Provider lockstat stellt Prüfpunkte zur Verfügung, die zur Unterscheidung von statistischen Daten über Lock-Contentions oder zur Untersuchung nahezu jedes Aspekts des Sperrverhaltens eingesetzt werden können. Der Befehl lockstat(1M) ist eigentlich ein DTrace-Verbraucher, der den Provider lockstat zum Abrufen der Rohdaten benutzt.

Überblick

Der Provider lockstat stellt zwei Arten von Prüfpunkten zur Verfügung: „contention-event-Prüfpunkte“ und „hold-event-Prüfpunkte“.

Contention-event-Prüfpunkte sprechen auf Konkurrenzsituationen (Contentions oder Kollisionen) an einer Synchronisierungsgrundeinheit an und werden ausgelöst, wenn ein Thread gezwungen ist, zu warten, bis eine Ressource verfügbar wird. Solaris ist allgemein für den konkurrenzfreien Betrieb (also ohne Contentions) optimiert. Länger andauernde Konkurrenzsituationen sind folglich nicht zu erwarten. Diese Prüfpunkte helfen Ihnen, Fälle zu verstehen, in welchen es trotzdem zu Konkurrenz kommt. Da Konkurrenzsituationen relativ selten sind, beeinträchtigt die Aktivierung von contention-event-Prüfpunkten die Leistung in der Regel kaum.

Hold-event-Prüfpunkte sprechen auf das Erhalten, Freigeben oder eine andere Art der Manipulation von Synchronisierungsgrundeinheiten an. Diese Prüfpunkte können helfen, beliebige Fragen über die Art und Weise der Manipulation von Synchronisierungsgrundeinheiten zu beantworten. Da in Solaris sehr häufig Synchronisierungsgrundeinheiten erhalten und freigegeben werden (auf belasteten Systemen bewegen wir uns hier in einem Größenbereich von mehreren Millionen Mal pro Sekunde und CPU), bewirkt die Aktivierung von hold-event-Prüfpunkten eine wesentlich höheren Prüfaktivität als die Aktivierung von contention-event-Prüfpunkten. Die Aktivität kann zwar beträchtlich ausfallen, ist aber nicht schädlich. Diese Prüfpunkte können trotzdem gefahrlos auf Produktionssystemen aktiviert werden.

Der Provider lockstat stellt Prüfpunkte zur Verfügung, die auf die verschiedenen Synchronisierungsgrundeinheiten in Solaris ansprechen. Der Rest dieses Kapitels befasst sich mit diesen Grundeinheiten und den auf sie ansprechenden Prüfpunkten.

Prüfpunkte für adaptive Sperren

Adaptive Sperren (adaptive locks) schützen einen kritischen Abschnitt durch Mutex (gegenseitiger Ausschluss) und können in den meisten Kontexten im Kernel erworben werden. Da für adaptive Sperren nur wenige Kontextbeschränkungen gelten, stellen sie die große Mehrheit der Synchronisierungsgrundeinheiten im Solaris-Kernel dar. Diese Sperren weisen ein in Bezug auf Konkurrenzsituationen adaptives (dynamisches) Verhalten auf: Wenn ein Thread eine belegte adaptive Sperre fordert, stellt er fest, ob der besitzende Thread derzeit auf einer CPU läuft. Wenn der Besitzer auf einer anderen CPU läuft, wird der fordernde Thread in den Wartezustand versetzt. Wenn der Besitzer nicht läuft, wird der fordernde Thread blockiert.

Die vier lockstat-Prüfpunkte für adaptive Sperren sind in Tabelle 18–1 aufgeführt. arg0 enthält für jeden Prüfpunkt einen Zeiger auf die kmutex_t-Struktur, die den adaptiven Lock darstellt.

Spinlock-Prüfpunkte

In einigen Kernel-Kontexten wie beispielsweise Interrupts auf hoher Ebene oder in jedem den Dispatcher-Zustand manipulierenden Kontext können Threads nicht blockiert werden. In diesen Kontexten wird die Verwendung von adaptiven Sperren durch diese Einschränkung verhindert. Stattdessen wird der Mutex in diesen Kontexten anhand von Spinlocks ausgesprochen. Das Verhalten dieser Sperren bei Konkurrenz besteht im Durchlaufen einer Warteschleife, bis die Sperre vom Besitzer-Thread freigegeben wird. Die drei Prüfpunkte im Zusammenhang mit Spinlocks sind in Tabelle 18–2 beschrieben.

Adaptive Sperren sind sehr viel häufiger als Spinlocks. Um diese Beobachtung auf Daten zu stützen, greifen wir auf das folgende Skript zurück, das die Gesamtzahl beider Lock-Typen anzeigt.

lockstat:::adaptive-acquire
/execname == "date"/
{
	@locks["adaptive"] = count();
}

lockstat:::spin-acquire
/execname == "date"/
{
	@locks["spin"] = count();
}

Führen Sie dieses Skript in einem Fenster aus und den Befehl date(1) in einem anderen. Wenn Sie das DTrace-Skript beenden, erhalten Sie eine Ausgabe wie im nächsten Beispiel:

# dtrace -s ./whatlock.d
dtrace: script './whatlock.d' matched 5 probes 
^C
spin                                                             26
adaptive                                                       2981

Wie diese Ausgabe zeigt, sind über 99 Prozent der bei der Ausführung des Befehls date erlangten Sperren adaptive Sperren. Es überrascht Sie vielleicht, dass bei einer einfachen Aktion wie date so viele Sperren erlangt werden. Die große Anzahl der Sperren ist ein natürlicher Nebeneffekt der in einem so extrem skalierbaren System wie dem Solaris-Kernel erforderlichen feinkörnigen Sperrstrukturen.

Threadsperren

Threadsperren sind eine spezielle Form des Spinlocks, die dazu dienen, einen Thread zu sperren, damit sein Status geändert werden kann. Während Hold-Ereignisse von Threadsperren als hold-event-Prüfpunkte für Spinlocks zur Verfügung stehen (d. h. als spin-acquire und spin-release), gibt es für spezifisch auf Threadsperren bezogene Konkurrenzereignisse einen eigenen Prüfpunkt. Der Prüfpunkt für Threadsperren-Hold-Ereignisse ist in Tabelle 18–3 beschrieben.

Prüfpunkte für Leser/Schreiber-Sperren

Leser/Schreiber-Sperren setzen eine Richtlinie um, die entweder mehrere Leser (reader) oder einen einzigen Schreiber (writer) in einem kritischen Abschnitt zulässt - nicht aber beides. Diese Sperren kommen in der Regel in Strukturen vor, die häufiger durchsucht als geändert werden und für die im kritischen Abschnitt viel Zeit vorgesehen ist. Wenn nicht viel Zeit im kritischen Abschnitt zur Verfügung steht, werden Leser/Schreiber-Sperren implizit über den für die Implementierung der Sperre genutzten gemeinsamen Speicher serialisiert. Dabei wird ihnen kein Vorrang gegenüber adaptiven Sperren eingeräumt. Unter rwlock(9F) finden Sie weitere Informationen zu Leser/Schreiber-Sperren.

Tabelle 18–4 zeigt die Prüfpunkte für Leser/Schreiber-Sperren. arg0 enthält für jeden Prüfpunkt einen Zeiger auf die krwlock_t-Struktur, die den adaptiven Lock darstellt.

Stabilität

Der Provider lockstat beschreibt die verschiedenen Stabilitäten anhand des DTrace-Stabilitätsmechanismus gemäß der folgenden Tabelle. Weitere Informationen zum Stabilitätsmechanismus finden Sie in Kapitel 39Stabilität.