Ist Ihr SharePoint zu langsam? Mit diesen 5 Schritten optimieren Sie die SQL-Datenbank

SharePoint erfordert wie jede komplexe Software einen permanenten Wartungsaufwand. Zu den Problemen, die im Alltag immer wieder auftauchen, gehört auch die bei den Benutzern wahrgenommene Verarbeitungsgeschwindigkeit. Eine simple Google-Suche offenbart, dass dieses Thema offenbar zu den Top-Ärgernissen zählt: „Why is SharePoint… so slow“? Verständlich, dass eine Arbeitsumgebung, die langsam reagiert, wenig Begeisterung hervorruft. Doch es gibt eine Reihe von Maßnahmen, um dem abzuhelfen und den Server wieder schneller zu machen. (von Robert Mulsow*)

Das Problem ist jedoch weder neu, noch unlösbar. Als Hauptursache für einen langsamen SharePoint lassen sich meist die Inhaltsdatenbanken identifizieren. Diese sind für eine Vielzahl von Aufgaben zuständig wie beispielsweise Suche, ECM, Workflows, Collaboration (Co-Authoring) und vieles mehr. Falls die Wartung hier nicht sorgfältig durchgeführt wird, können solche Operationen die Systemleistung enorm beeinflussen. Als erschwerender Umstand kommt hinzu, dass SharePoint-Inhaltsdatenbanken darauf ausgelegt wurden, ohne großes Eingreifen zu funktionieren – also, einfach installieren und los. Und dabei erweisen sich die vergebenen Standardwerte mit der Zeit als Bremser. Passt man sie nicht an, wird SharePoint langsam.

Mit 5 Standardeinstellungen zum schnelleren SharePoint

Folgende fünf Standardeinstellungen lassen sich einfach anpassen und ermöglichen es, die SharePoint-Performance um bis zum Vierfachen zu steigern:

1. MAXDOP-Wert

2. Memory Allocation

3. AutoGrowth-Einstellungen

4. TempDB-Einstellungen

5. Cluster-Größe der SQL-Festplatten

1. MAXDOP: Parallelität anpassen

Der maximale Grad der Parallelität (MaxDegreeOfParallelism) kann beschränken, wie viele Prozessorkerne gleichzeitig für Anfragen genutzt werden. Je mehr Kerne, desto schneller arbeitet SQL. Das ist gut, so lange es um reine Datenbankaufgaben geht, weil SQL die Anfragen intelligent verteilt.

Kompliziert wird es aber, wenn SharePoint ins Spiel kommt. Denn SharePoint optimiert die Anfragen, bevor sie tatsächlich an den SQL gesendet werden. Das heißt, der erneute Versuch seitens SQL, die eingehenden Anfragen zu optimieren, lässt das ganze ineffizient werden. Daher sollte der Wert auf 1 gesetzt werden, damit die Anfragen so abgearbeitet werden, wie sie von SharePoint kommen.

2. Memory Allocation: Maximaler Arbeitsspeicher

Kommt Ihnen die Zahl 2147483647 bekannt vor? Dies ist der Speicherwert in MB, der SQL maximal vom Arbeitsspeicher zur Verfügung steht – also 2,1 PB (PetaByte!).

SQL nimmt sich so viel Arbeitsspeicher, wie er braucht und wie er kriegen kann, egal, ob dem Betriebssystem noch etwas übrig bleibt. Hat SQL einmal so viel Arbeitsspeicher genommen, dass selbst das Betriebssystem keine weiteren Prozesse und Threads bearbeiten kann, so hängt der Server. Die CPU-Nutzung und Disk I/O erhöhen sich stark, weil Windows beginnt, mehr und mehr RAM auf die Festplatte auszulagern. Dadurch erhöhen sich die Antwortzeiten und SharePoint wird langsam, oder er fällt ganz aus, wenn die Datenbankserver neu gestartet werden müssen, um das Problem zu lösen.

Daher sollte man den maximalen Wert der Arbeitsspeicherzuteilung so einstellen, dass stets ein Rest für das Betriebssystem bleibt. Bei kleineren Servern sind etwa 80-85 Prozent des maximal verfügbaren Speichers zu empfehlen. Bei sehr viel verfügbarem Speicher (> 64 GB) sollten etwa 8 GB für das Betriebssystem reserviert werden.

Auch wenn der minimale Wert keine großen Probleme macht, so empfehle ich, diesen auf 1-2 MB zu setzen, damit SQL immer eine Grundlast hat. SQL läuft damit stabiler und ist schnell auf „Betriebstemperatur“.

3. AutoGrowth: Weniger Vergrößerungsoperationen

Auch bei den AutoGrowth-Einstellungen sind die Standardwerte leider alles andere als optimal gewählt. Aufgrund einer kleinen Startgröße und kleiner automatischer Vergrößerungsschritte, können Daten nicht fortlaufend in die Blöcke (Extents) und Seiten (Pages) geschrieben werden.

Dies geschieht bei allen INSERT-, UPDATE- und DELETE-Vorgängen. Es kommt zur Fragmentierung, die zu einer schlechteren Performance führt.

Weiterhin werden bei jedem AutoGrowth-Vorgang Server-Ressourcen verbraucht. Bei prozentualen Änderungen kommen noch Kalkulationsvorgänge hinzu. Dies sind alles zusätzliche Operationen, die der SQL nebenbei ausführen muss, bevor er die eigentlichen SharePointAnfragen abarbeiten kann. Wir erkennen also, dass wir mit den AutoGrowth-Einstellungen viel beeinflussen können.

Idealerweise sind Datenbanken (durch Datenbankadministratoren) für die SharePoint-Installation schon vorkonfiguriert. Die Initialgrößen sollten dabei ausreichend groß gewählt werden, in Hinblick auf die zu erwartende Größe der Inhaltsdatenbanken. Dies muss aber noch nicht die von Microsoft empfohlene Maximalgröße sein. Denn eine initial große Datenbankdatei würde natürlich auch die Backup-Größe und -Zeit beeinflussen. Ein paar Wochen sollten die Datenbanken daher ab Ihrer Erstellung ohne Vergrößerung auskommen.

Ist die Maximalgröße dann erreicht, wird die automatische Vergrößerung aktiv.

Je nach Größe der zugehörigen Datenbank sollte die inkrementelle Zuwachsrate einen festen und keinen prozentualen Wert haben. Der Wert der Vergrößerung sollte etwa 10 % der Datenbankgröße betragen. Bei einer Inhaltsdatenbank von 10 GB wäre somit der Autozuwachs auf 1 GB einzustellen. (Soll die Datenbank 100 GB und größer werden, können auch größere Zuwachsschritte gewählt werden.) Für die Log-Datei kann dies ähnlich konfiguriert werden.

Als Ergebnis werden wir weniger Vergrößerungsoperationen haben, welche die Serverleistung reduzieren. Weiterhin haben wir eine geringere Fragmentierung, sodass SharePoint-Anfragen schneller bearbeitet werden können.

4. TempDB-Einstellungen

Die TempDB des SQLs kann man im weitesten Sinne wie den RAM-Speicher des Betriebssystems verstehen. Sie speichert unter anderem temporäre Benutzerobjekte wie Tabellen und Prozeduren, interne Objekte z.B. für das Speichern von Zwischenergebnissen und Zeilenversionen zum Beispiel für Datenänderungstransaktionen. Die TempDB wird bei jedem Start von SQL neu erstellt und alle gespeicherten Daten werden beim Trennen der SQLVerbindung wieder gelöscht.

Mit dieser Analogie zum RAM-Speicher ist also leicht zu verstehen, dass Optimierungen der TempDB auch zur Verbesserung des gesamten SQLs führen und damit auch unseren SharePoint beschleunigen. Die verschiedenen Möglichkeiten, um die TempDBs zu optimieren, möchte ich hier auflisten:

– Das Recovery Model sollte auf SIMPLE gestellt werden

– Die TempDB kann auf mehrere Dateien aufgeteilt werden o bei bis zu acht logischen Prozessoren: #Kerne = #TempDB-Dateien o bei mehr als acht Prozessoren genau acht TempDB-Dateien konfigurieren o wenn Speicherkonflikte (In-Memory-Contention) auftreten, sollten die TempDB-

Dateien jeweils um vier erweitert werden, bis die Konflikte auf ein normales Niveau absinken

*Hinweis: Daumenregel besagt #Kerne = ½ bis ¼ TempDB-Dateien o alle TempDB-Dateien sollten die gleiche Größe und gleichen Einstellungen haben o jede Datei sollte 25 % der Größe der größten Inhaltsdatenbank haben o die Dateien können auch über mehrere Spindeln verteilt werden, um eine noch bessere Performance zu erzielen

*Hinweis: Da alle zusätzlichen Datendateien per Definition SECONDARY-Dateien sind, sollten Sie das Format *.ndf zuweisen anstelle des *.mdf für die initiale PRIMARY-Datei.

– Die TempDBs sollten auf den schnellsten Laufwerken platziert werden

– Auf den TempDB-Laufwerken sollte mehr als 25 % freier Speicher zur Verfügung stehen, um zu Peak-Zeiten das Anwachsen der Dateien zu ermöglichen (AutoGrowth ähnlich konfigurieren wie für Inhaltsdatenbanken siehe oben)

5. Cluster-Größe der SQL-Festplatten

Sie haben Ihre SQL-Datenbanken auf einer Standard-NTFS-Partition installiert und haben nun Performance-Probleme? Dann könnte auch die Cluster-Größe der zugrundeliegenden Speicherpartition eine Ursache sein. Wussten Sie nämlich, dass die standardmäßige ClusterGröße bei der Erstellung eines NTFS-Laufwerks bei 4 KB liegt? Dies ist ein weiteres schönes Beispiel für Standardwerte, die leider für unseren SQL nicht gut funktionieren.

SQL bevorzugt nämlich eine Cluster-Größe von 64 KB. Dies ist darauf zurückzuführen, wie SQL seinen Speicher innerhalb seiner Datendateien (MDF oder NDF) verwaltet. Dazu wird dieser logisch in 8 KB große Seiten (Pages) unterteilt. Dies ist die grundlegende Einheit für die Datenspeicherung im SQL. Für eine effizientere Speicherverwaltung werden zudem immer acht physisch zusammenhängende Seiten zu Blöcken (Extents) zusammengefasst. Die Rechnung ist also einfach: 8 Seiten x 8 KB = 64 KB.

Wenn Sie also Performance-Probleme haben, denken Sie darüber nach, Ihre Datenbankdateien auf Laufwerke mit 64 KB Cluster-Größe zu verschieben. Selbst mit einer VM innerhalb der IaaS-Lösung von Microsoft Azure ist durch diese Cluster-Größe eine 20 % bessere Festplatten-Performance zu messen. Auch diese Möglichkeit sollten Sie also berücksichtigen, wenn Sie Ihre SharePoint-Performance verbessern möchte.

Es ist somit nicht immer SharePoint allein, der langsam ist. Außerdem muss man nicht immer sofort auf bessere und teurere Hardware zurückgreifen, um die Performance zu verbessern. So kann es sich empfehlen, beispielsweise in den Peripherie-Technologien zu SharePoint (SQL, Windows Server etc.) nicht die Standardwerte zu verwenden. Konfigurieren Sie stattdessen die optimalen Werte für eine optimale Performance. Dies wird Ihnen mit Sicherheit dabei helfen, die Nutzerakzeptanz gegenüber SharePoint zu steigern.

*Autor: Robert Mulsow, Technical Solutions Professional bei Avepoint Deutschland GmbH