SharePoint Performance Monitoring - Performance Counter für den Prozessor
SharePoint Adventskalender - 9. Türchen
Performance Tuning - Performance Monitoring - Best-Practices für SP-SQL-Konfigurationen - BLOB Management - Backup & Recovery
-------------------------------------------------------------
Nachdem wir nun eine Menge für die Performance getan haben und unser SharePoint jetzt „rennt“ wie nie zuvor, wollen wir auch dafür sorgen, dass es dabei bleibt. Dazu müssen wir die Performance mit geeigneten Indikatoren überwachen. Die Auswahl der richtigen Messgrößen ist dabei sehr wichtig, weil jede Plattform, System oder Applikation die verschiedenen Parameter der zugrundeliegenden Hardware unterschiedlich belastet. Überwache ich beispielsweise die Prozessorauslastung für eine Applikation, die hauptsächlich über den RAM Speicher arbeitet, dann „monitore“ ich am Ziel vorbei.
Heute und in den nächsten Tagen möchte ich daher Performance Counter aus dem Microsoft Windows Performance Monitor vorstellen, die Messgrößen überwachen, welche besonders wichtig für einen schnellen SharePoint sind. Den Anfang sollen dafür die CPU-Counter machen.
-------------------------
Prozessorprobleme treten auf, wenn die CPU voll ausgelastet ist und daher Anfragen nicht schnell oder sogar gar nicht mehr abgearbeitet werden können. Eine hohe Prozessoraktivität ist dazu zwar ein erstes Indiz, aber beispielsweise eine dauerhaft lange „Warteschlange“ für Prozessoranfragen (12. Türchen) ist noch aussagekräftiger.
% Interrupt Time
Dieser Indikator gibt an, wie viel Prozent die CPU ihrer Zeit für Prozessunterbrechungen verliert. So kann beispielsweise eine alte Netzwerkkarte auf einem sehr stark ausgelastetem IIS Server (SharePoint Web Front End) diesen Wert nach oben treiben. Aber grundsätzlich auch fehlerhafte Hardware kann den Wert nach oben bringen. Generell sollte dieser Wert nicht dauerhaft 30% übersteigen. Andernfalls sollten sie herausfinden, was die Ursache dafür ist, da es die SharePoint Performance negativ beeinflusst.
% Privileged Time
Gewöhnlich sollte der Prozessor seine Operationen im User Mode (siehe unten) ausführen, da dieser für Applikationen, Teilsysteme und integrierte Teilsysteme gedacht ist. Der „Privileged“ oder auch „Kernel“ Mode hingegen ermöglicht den Zugriff auf system-spezifische Operationen, wie z.B. Gerätetreiber-Aufrufe oder Deferred Procedure Calls (DPC siehe unten). Diese speziellen Aktionen können im schlimmsten Fall auch das gesamte System zum Absturz bringen. Ein zeitlich hoher prozentualer Anteil an diesen Kernel-Mode Operationen (>30%) deuten auf schlechte Gerätetreiber oder fehlerhafte Hardware hin. Dies allein ist schon nicht optimal, aber im Hinblick auf unsere Performance bleibt so weniger Zeit, um SharePoint-Operationen im User-Mode ausführen zu können.
% User Time
Die abgearbeiteten Threads im User Mode sind hingegen in einer sicheren „Einheit“ und können nicht andere Programme und Applikationen beeinflussen. Dies ist ein ähnlicher Ansatz, wie wir es aus SharePoint 2010 mit den Sandbox Solutions kennen. Die User Time für sich sagt noch nicht so viel aus. Interessanter wird es, wenn wir es in Kombination mit der Privilege Time vergleichen. Viel Privilege und wenig User kann auf obige Probleme hindeuten. Wenig Privilege und viel User ist zunächst in Ordnung. Wird die User Time aber besonders groß, kann dies auch darauf hindeuten, dass Sie schlecht oder fehlerhaft programmierte Anpassungen wie JaveScripts oder ähnliches in Ihrem SharePoint laufen haben. Achten Sie daher darauf, dass die Werte für diesen Indikator nicht 70% übersteigen.
% Processor Time
Dieser Indikator ist der Hauptindikator für die Prozessoraktivität und gibt an, welchen Teil seiner Zeit der Prozessor damit beschäftigt war, Threads abzuarbeiten. Dieser Wert wird nicht direkt gemessen. Stattdessen wird die Leerlaufzeit gemessen, also das Warten, bis ein nächster Thread fertig ist, abgearbeitet zu werden. Zieht man nun die prozentuale Leerlaufzeit von 100% ab, erhalten wir die % Processor Time. Grundsätzlich ist eine Auslastung von mehr als 70% nicht optimal und würde daher seinen Anteil zu einer schlechten SharePoint Performance beitragen.
Noch ein Hinweis zur Zeitmessung: Dies ist ein internes Standardintervall von 10 ms. Besonders neuere Prozessoren arbeiten sehr schnell. Zum Messpunkt können Sie zwar kurzzeitig im Leerlauf sein, aber sie haben vielleicht trotzdem innerhalb des Zeitintervall Threads abgearbeitet. Das Intervall wird dennoch ganzheitlich als Leerlauf in die Brechnung aufgenommen und daher kann die Prozessorauslastung geringer ausfallen, als sie tatsächlich ist.
% DPC Time
Ein Deferred Procedure Call ist eine Operation im Privilege Mode (siehe oben), jedoch mit geringer Priorität. Er wird ausgelöst, wenn z.B. ein Hardware-Gerät den Prozessor unterbricht und der „Interrupt Handler“ entscheidet, dass noch offene und notwendige aber weniger wichtige Operationen erst später ausgeführt werden. So kann z.B. verhindert werden, dass schlechte Gerätetreiber mit weniger wichtigen Operationen, nicht andere wirklich kritische Aktionen blockieren. Die prozentuale DPC Time ist also ein zusätzlicher Indikator für die prozentuale Interrupt Time und bestätigt, ob schlechte Hardware und deren Treiber viele unwichtige Unterbrechungen und Operationen ausführen möchten und damit die Abarbeitung von User Mode Aktionen blockieren. Da eine dauerhafte % DPC Time über 30% nicht optimal ist, sollten Sie also auch diesen Indikator ernst nehmen.
Für alle Counter gilt, dass sie mit einem Account ausgeführt werden müssen, der über die notwendigen berechtigungen verfügt, um die Daten sammeln zu können, wie z.B. Nutzer der Gruppe Performance Monitor Users. Zudem können Sie die Indokatoren auch ganz gezielt für einzelne Prozessor(-kerne) konfigurieren, um beispielsweise im Problemfall noch gezielter die Ursache zu finden. Achten Sie also darauf, wenn Sie sich ein Collector Set konfigurieren, dass Sie nicht die Werte über alle Kerne messen (_Totel), wie in meinem Screenshots unten, sondern selektieren Sie die Kerne 1 bis n einzelnd.
Viel Spaß beim „SharePointen“!
-------------------------------------------------------------
Weitere Türchen:
- 1. Türchen: SharePoint Performance Tuning - Cluster Größe der SQL Festplatten
- 2. Türchen: SharePoint Performance Tuning - SQL Speicherzuweisung
- 3. Türchen: SharePoint Performance Tuning - SQL MAXDOP
- 4. Türchen: SharePoint Performance Tuning - SQL AutoGrowth-Einstellungen
- 5. Türchen: SharePoint Performance Tuning - SQL Datenbanken vor konfigurieren
- 6. Türchen: SharePoint Performance Tuning - SQL TempDB Einstellungen
- 7. Türchen: SharePoint Performance Tuning - Der Papierkorb
- 8. Türchen: SharePoint Performance Tuning - Warm Up Skripte
- 9. Türchen: SharePoint Performance Monitoring - Performance Counter für den Prozessor
- 10. Türchen: SharePoint Performance Monitoring - Performance Counter für Speicherlaufwerke
- 11. Türchen: SharePoint Performance Monitoring - Performance Counter für den Arbeitsspeicher
- 12. Türchen: SharePoint Performance Monitoring - Performance Counter für System und Netzwerk
- 13. Türchen: SharePoint Configuration Best Practices - SQL Alias
- 14. Türchen: SharePoint Configuration Best Practices - Benamte SQL Instanzen und dedizierte Ports
- 15. Türchen: SharePoint Configuration Best Practices - Super User und Super Reader
- 16. Türchen: SharePoint Configuration Best Practices - Distributed Cache Service
- 17. Türchen: SharePoint Configuration Best Practices - Request Management Service
- 18. Türchen: SharePoint BLOB Management - BLOB Cache
- 19. Türchen: SharePoint BLOB Management - BLOB Storage (EBS und RBS)
- 20. Türchen: SharePoint BLOB Management - Shredded Storage
- 21. Türchen: SharePoint BLOB Management - Shredded Storage und RBS “Better Together”
- 22. Türchen: SharePoint BLOB Management - Archivierung
- 23. Türchen: SharePoint Backup & Recovery - Von RTO, RPO und RLO zum fertigen Disaster Recovery Plan (1/2)
- 24. Türchen: SharePoint Backup & Recovery - Von RTO, RPO und RLO zum fertigen Desaster Recovery Plan (2/2)