OS X Server: Leistungsbeurteilung

In diesem Artikel wird beschrieben, wie du mit einem Skript die Leistung deines Servers mit Mac OS X Server 10.4 oder neuer zu beurteilen. Der Schwerpunkt liegt auf der Identifizierung der Nutzung wichtiger Ressourcen: CPU, Festplattenspeicher und Netzwerkbetrieb.

Ressourcennutzung

Mit diesem Perl-Skript (mit Namen „top_guide.pl“) kannst du die Nutzung wichtiger Ressourcen auf deinem Server im Laufe der Zeit beurteilen. Dieses Skript funktioniert mit Mac OS X Server 10.4 und neuer.

Das Skript führt den Befehl top -d aus, extrahiert und fasst die Nutzung wichtiger Ressourcen im Laufe der Zeit zusammen. Ohne Argumente sieht das Ergebnis von top_guide.pl etwa folgendermaßen aus:

-------- ----------- ------------ ------------- ------------- ------------- ------------- ------ CPU usage: 300-s Reads/sec: Writes/sec: Net in/sec: Net out/sec: kernel Time: user sys Idle avg. number MB number MB pkts Mb pkts Mb CPU% -------- ----- ----- ----- ----- ------ ------ ------ ------ ------ ------ ------ ------ ------ 08:44:36 0.1 0.1 99.8 99.8 0 0.0 0 0.0 11 0.0 0 0.0 0.4 08:44:46 0.1 0.3 99.6 99.8 0 0.0 0 0.1 12 0.0 0 0.0 0.4 08:44:56 0.0 0.2 99.8 99.8 0 0.0 0 0.0 17 0.0 0 0.0 0.4 08:45:06 0.0 0.2 99.8 99.8 0 0.0 0 0.0 6 0.0 0 0.0 0.4 08:45:16 0.0 0.2 99.8 99.8 0 0.0 0 0.0 9 0.0 0 0.0 0.4 08:45:26 8.7 24.6 66.7 98.6 43 0.8 98 0.6 803 1.0 1399 1.1 5.0 08:45:37 5.7 83.6 10.7 95.7 48 0.4 1085 116.9 95366 1053.1 61830 35.4 72.4 08:45:47 11.5 88.5 0.0 92.4 23 0.2 3228 426.9 337955 3843.6 207872 114.0 284.8 08:45:58 4.6 95.4 0.0 89.0 4 0.0 594 596.7 447499 5215.5 266449 140.9 370.0

Die drei aufgeführten Schlüsselbereiche sind: CPU, E/A der Festplatte und Netzwerkbetrieb. Die Spalten sind:

• Time: Die Endzeit der letzten Summenzeile. Standardmäßig sind es 10 Sekunden zwischen den Samples.

• CPU usage: Benutzer: CPU-Nutzung im Benutzermodus. Der Wert ist ein Prozentsatz der gesamten auf diesem System verfügbaren CPU-Ressourcen. Auf einem 8-Prozessor-System würde beispielsweise 50 % Benutzer-CPU bedeuten, dass die gesamte CPU-Nutzung aller laufenden Anwendungen 4 Prozessoren entspricht.

• CPU usage: sys: CPU-Nutzung im Kernel-Modus als Prozentsatz der gesamten verfügbaren CPU.

• Idle: Inaktive CPU als Prozentsatz der insgesamt verfügbaren Ressourcen.

• 300-s avg: Geglätteter Durchschnitt der ungenutzten CPU während der letzten 300 Sekunden in Prozent. (Hinweis: Das Ergebnis ändert sich, wenn man die -roption verwendet, um das Mittelwertintervall anzupassen; der Spaltentitel ändert sich entsprechend.)

• Reads/sec - number: Die Anzahl der eindeutigen Festplattenlesevorgänge während des Sample-Zeitraums.

• Reads/sec - MB: Die während des Sample-Zeitraums insgesamt von den Festplatten gelesenen Megabyte.

• Writes/sec - number: Die Anzahl der eindeutigen Schreibvorgänge während des Sample-Zeitraums.

• Writes/sec - MB: Die während des Sample-Zeitraums insgesamt geschriebenen MB.

• Net in/sec - pkts: Gesamtzahl der während des Sample-Zeitraums eingegangenen Pakete.

• Net in/sec - Mb: Gesamter Netzwerkeingang in Megabit pro Sekunde während des Sample-Zeitraums.

• Net out/sec - pkts: Gesamtzahl der während des Sample-Zeitraums gesendeten Netzwerkpakete.

• Net out/sec - Mb: Gesamter Netzwerkausgang in Megabit pro Sekunde während des Sample-Zeitraums.

Weitere Optionen, die das Skript bietet, sind:

• -h: Anzeige sämtlicher Nutzungsinformationen.

• -o Dateiname: Eine tabulatorgetrennte Kopie der Ausgabeergebnisse in eine Datei schreiben. Diese Form der Ausgabe eignet sich für den Import in eine Tabelle oder andere Datenanalyseskripte. Die erste Zeile enthält die Spaltenüberschriften, um sicherzustellen, dass die Ausgabe immer selbsterklärend ist.

• -d: Anzeige von Datums- und Zeitstempel. Dies ist besonders nützlich für die langfristige Protokollierung auf einem Server, auf dem der Administrator einen Verlaufsdatensatz wünscht.

• -S Prozessnamen: Überwachen von Prozessen mit nur einer Instanz. Dies ist hilfreich, wenn ein bestimmter Dienst, der nur über eine einzige Prozess-ID verfügt, auf einem Server von besonderem Interesse ist. Dabei könnte es sich um einen Server handeln, der hauptsächlich als AFP-Server genutzt wird. In diesem Fall kannst du die Argumente -S AppleFileServer verwenden, um eine separate Spalte für die Benutzer-CPU-Nutzung des AppleFileServer-Prozesses hinzuzufügen. Wenn die Prozessnamen durch Kommas getrennt werden, können mehrere Prozesse aufgelistet werden.

• -M Prozessnamen: Wie -S, aber nur, wenn die Anwendung mehrere Prozesse verwendet. Ein Beispiel ist smbd, die einen pro Verbindung verwendet. Auf einem stark für Samba genutzten System kannst du -M smbd verwenden, um eine Spalte abzurufen, die die Benutzer-CPU aller Samba-Aktivitäten zusammenfasst.

Obwohl eine vollständige Analyse der Serverleistung über den Rahmen dieses Artikels hinausgeht, erstellt top_guide.pl eine Nutzungsübersicht der CPU-, Festplatten- und Netzwerkressourcen auf dem System. Durch einen Abgleich mit der Hardware und der Systemlast, kann ein Administrator entscheiden, welcher Bereich genauer untersucht werden soll. Einige zusätzliche Tools, die die Untersuchung der einzelnen Bereiche unterstützen können, werden im Folgenden behandelt.

CPU-Nutzung

Bei starker CPU-Nutzung zielt die Untersuchung primär darauf ab, die Effizienz der Anwendung zu verbessern. Das wird in diesem Artikel nicht behandelt; mitunter wird die CPU allerdings nicht ausgelastet. Es stehen mehrere Tools zur Verfügung, mit deren Hilfe du die Situation untersuchen kannst, in der ausreichend Netzwerk- und Festplattenressourcen für eine höhere Last zur Verfügung stehen, ein erheblicher Teil der CPU aber ungenutzt bleibt.

Zwei Gründe können eine nicht voll ausgelastete CPU bedingen:

• Application Thread Locking

• Kernel Resource Locking

Der in Mac OS X 10.5 Leopard eingeführte Befehl plockstat(1) kann für eine bestimmte Anwendung ausgeführt werden, um pthread-Sperrkonflikte zu untersuchen. Du kannst Prozesse mit möglichen pthread-Sperrkonflikten identifizieren, indem du das Ergebnis von top -d für Prozesse mit vielen Kontextwechseln (CSW-Spalte) untersuchst. Sobald du einen Prozess identifiziert hast, den du auf pthread-Sperrkonflikte untersuchen möchtest, verwende: # plockstat -C -e 10 -p .

Mutex block Count nsec Lock Caller ------------------------------------------------------------------------------- 8540 29622 0x805eb0 a.out`process_request+0x3d1 8361 28284 0x805eb0 a.out`release_block+0xac R/W reader block Count nsec Lock Caller ------------------------------------------------------------------------------- 1 3014987 0xa781e8 a.out`key_find+0x121 5 78831 0xa3d158 a.out`key_find+0x121 2 120532 0xa3d158 a.out`key_delete+0x137 R/W writer block Count nsec Lock Caller ------------------------------------------------------------------------------- 10 5336318 0xa781e8 a.out`key_replace+0x80 13 3827632 0xa75fe8 a.out`key_replace+0x80 3 3644946 0xa5fde8 a.out`key_create+0x37 6 161055 0xa3d158 a.out`key_replace+0x80 1 785267 0xa37758 a.out`key_create+0x37

Du kannst dieses Ergebnis untersuchen und die Gesamtmenge der hinter zahlreichen Locks blockierten nsec überprüfen. Ist dieser Wert im Verhältnis zur Gesamtmenge hoch, wird die Ausführungszeit durch den Sperrkonflikt beeinflusst. Diese Informationen können für den Programmierer hilfreich sein, um die Leistung der Anwendung zu isolieren und zu verbessern. Sind Symbole verfügbar, so enthält das Feld „Caller“ den symbolischen Namen der blockierenden Funktion. Außerdem kommt es bei einer hohen Gesamtzahl an Sperren, mehr als ca. 250 pro Sekunde, beim Verschieben zwischen den Threads zu Effizienzverlusten. Auch wenn es nicht ausreicht, um daraus einen begrenzenden Faktor für die Leistung abzuleiten, rechtfertigen hohe Sperrquoten eine Untersuchung, da sie in der Regel ein Indiz dafür sind, dass die Anwendung nicht so effizient ist, wie sie sein könnte.

Manchmal betreffen Probleme mit Ressourcenkonflikten Ressourcen innerhalb des Kernels. Der Mac OS X-Kernel verwaltet die meisten Multi-Thread-Ressourcen mit Kernel-Mutexen und Lese-Schreib-Sperren. Mutex-Konflikte können mithilfe von dtrace(1M)-Skripten ausgewertet werden, z. B.:

lockstat:::adaptive-block { @often[arg0, stack(5)] = count(); } profile:::tick-5sec { normalize(@often, 5); printa(@often); }

Gibt eine sortierte Liste mit den häufigsten Sperren und Pfaden am Ende jedes Ausgabeblocks, der im Anschluss an 5-Sekunden-Samplings ausgedruckt wird, aus. Ein Beispiel:

375517140 mach_kernel`lck_mtx_lock_wait_x86+0x1c7 mach_kernel`lck_mtx_lock+0x217 mach_kernel`ip_output_list+0xd34 mach_kernel`tcp_setpersist+0x18b mach_kernel`tcp_output+0x17a0 0 375571960 mach_kernel`lck_mtx_lock_wait_x86+0x1c7 mach_kernel`lck_mtx_lock+0x217 mach_kernel`vnode_ref+0x32 mach_kernel`fcntl_nocancel+0x4b3 mach_kernel`unix_syscall64+0x26d 0

In diesem Fall meldet das Skript, dass der Kernel-Mutex bei 375517140 über einen Pfad blockiert wird, in dem tcp_output() die Funktion tcp_setpersist() aufruft, die wiederum ip_output_list() aufruft. Die Anzahl der Blöcke pro Sekunde ist bei beiden Sperren 0, sodass der Sperrkonflikt kein Problem darstellt. Hinweis: Diese Form des Skripts summiert nicht alle Instanzen gegen eine einzelne Sperre. Würde das Skript wie folgt geändert:

lockstat:::adaptive-block { @often[arg0] = count(); } profile:::tick-5sec { normalize(@often, 5); printa(@often); }

Könnte das Ergebnis wie folgt lauten:

1301055072 9 1417504384 9 353318336 10 359381776 10 1301055088 11 5387344 165

Dies deutet darauf hin, dass nur die Sperre an der Kernel-Adresse 5387344 einen nennenswerten Konflikt hat, und selbst dann besteht kein Grund zur Besorgnis, da die Anzahl unter 250 liegt.

Abschließend kann das Skript Lese-Schreib-Sperren des Kernel in den Fokus nehmen, indem es geringfügig geändert wird:

lockstat:::rw-block { @often[arg0, stack(4)] = count(); } profile:::tick-5sec { normalize(@often, 5); printa(@often); clear(@often); }

Wichtige Informationen für die Verwendung von dtrace(1M) lockstat-Skripten und plockstat(1):

• Das Erfassen von Sperrstatistiken wirkt sich auf die Leistung aus. Diese Tools können das System verlangsamen. Führe sie mit Bedacht aus, und denke daran, dass die Leistungsbeeinträchtigung zusätzliche Konflikte verursacht, die es im Normalbetrieb nicht gibt.

• Einige Designs werden durch das einfache Blockieren von Sperren nicht beeinträchtigt. Betrachte eine Sperre für eine sich sehr langsam ändernde Ressource, zu deren Verwaltung du dich für eine Sperre entscheiden kannst. Die Sperre kann beibehalten werden, bis ein langwieriger Vorgang abgeschlossen ist.

Solche Instanzen können lange Wartezeiten haben, die die Leistung unter Umständen nicht wirklich beeinträchtigen.

Festplattennutzung

iopending(1) gibt einen Hinweis auf die Tiefe der E/A-Warteschlangen in Form eines Histogramms der Warteschlangentiefe. Beispiel:

2008 May 21 10:35:26, load: 0.99, disk_r: 0 KB, disk_w: 392 KB

value ------------- Distribution ------------- count < 0 | 0 0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 9298 1 | 12 2 | 5 3 | 4 4 | 2 5 | 3 6 | 2 7 | 2 8 | 3 9 | 2 10 | 3 11 | 2 12 | 2 13 | 2 14 | 2 15 | 0

Dies deutet auf eine gewisse Festplattenaktivität hin, stellt aber kein Problem dar, da fast alle E/A-Warteschlangen eine Tiefe von 0 haben. Darüber hinaus kannst du dich mit dem Befehl iopending auf eine bestimmte Festplatte oder ein bestimmtes Dateisystemvolume konzentrieren. Wenn du beispielsweise /Volumes/MyRAID genauer betrachten möchtest, verwende iopending -m MyRAID.

Schließlich kannst du einem speziellen Prozess E/A zuweisen und die Latenz mithilfe des Befehls fs_usage(1) beurteilen. Weitere Informationen zur Verwendung von Shark und fs_usage(1) findest du in diesem Developer Connection-Artikel.

Netzwerknutzung

Viele Server können mehrere, unterschiedlich weit entfernte Netzwerkschnittstellen und Clients im gesamten Netzwerk haben. Eine Leistungsanalyse kann komplex sein. In LANs jedoch, in denen Clients über eine Fabric mit einer bekannten Geschwindigkeit direkt verbunden sind, geben die von top_guide.pl sowie netstat -i gemeldeten Metriken einen Einblick in die tatsächliche Nutzung der Kapazität. Beachte bei der Auswertung dieser Zahlen folgende Richtlinien:

Gigabit-Netzwerke: Vollduplex, 1500 Byte MTU

Höchstraten: kleine Pakete: 1488 Kpps 762 Mbit/s

Maximale Paketrate: 1500 Byte-Pakete: 81 Kpps 987 Mbit/s

(Kpps = Tausend Pakete pro Sekunde)

Bei der Analyse der Netzwerkleistung ist es auch hilfreich, die Ausgabe von netstat -s auf Probleme, wie ungewöhnlich hohe Paket-Neuübertragungsraten, zu überprüfen (was über den Rahmen dieses Artikels hinausgeht).

Weitere Informationen

• Weitere Informationen zur Überwachung der Dateisystemnutzung findest du hier: Examining File-System Usage.

• Informationen zum Shark-Zeitprofilierungstool findest du hier: Shark User Guide.

• Weitere Informationen zur Verwendung von Dtrace findest du hier: How To Use Dtrace.