SharePoint 2013 Performanceoptimierung

In SharePoint-Projekten wird in den meisten Fällen viel Aufwand für die Wahl der richtigen SharePoint-Architektur gesteckt. Diese wird angepasst an die Anforderungen und Bedürfnisse des Kunden. Auch das Thema Informationsarchitektur und die damit verbundene Frage der Struktur der Sites wird mittlerweile in den meisten Projekten berücksichtigt.

Die Themen die in der Einführungsphase von SharePoint betrachtet werden, sind in der folgenden Abbildung exemplarisch dargestellt:

Das Thema Performanceoptimierung wird in vielen Projekten eher stiefmütterlich behandelt und oft erst nach GoingLive der SharePoint-Farm thematisiert.

Folgende Themen bzw. Fragestellungen werden in diesem Zusammenhang betrachtet:

• Sicherstellen der hohen Performance einer SharePoint-Infrastruktur
• Gewährleisten der Skalierbarkeit ohne Performanceverlust bezüglich Datenmenge und Zugriffshäufigkeit
• Messen und Überwachen dieser Qualitätsmerkmale
• Hohe SharePoint-Performance wird primär durch hohe SQL Server-Performance erreicht
• SQL Server-Performance wird primär durch Disk-Zugriffszeiten bestimmt

Hierbei muss noch zwischen den unterschiedlichen „Stakeholdern“ und ihren Anforderungen bzgl. Performance unterschieden werden. So haben die Benutzer mit Sicherheit eine andere Sicht auf die Thematik und stellen Aspekte wie der Erstaufruf einer Seite oder der Upload von Dokumenten innerhalb einer bestimmten Zeit in den Vordergrund. Aus Sicht der IT stehen Meßkriterien wie Latenz, Durchsatz, Datenvolumen, Datenwachstum und Zuverlässigkeit im Vordergrund und beeinflußen im Wesentlichen das Thema Performance.

Grundsätzlich gibt es für SharePoint-Farmen mehrere Stellen, an denen eine Optimierung möglich ist:

• Server
  • Memory, CPU und Festplatten
  • Internet Information Server
  • SQL-Performance
  • SAN und IOPS
• Netzwerk
  • Infrastruktur
  • Proxy Server
  • WAN-Latenzen
  • Komprimierung
• Client
  • Cachingmechanismen
  • Page Optimierungen
  • Browser Rendering
  • Hardware, Treiber, Betriebssystem- und Browser-Updates

In diesem Artikel werde ich die möglichen Optimierungen darstellen und mich hierbei auf den wichtigsten Faktor SQL-Sever beschränken. Eine ausführliche Performanceanalyse muss selbstveständlich immer im Kontext des jeweiligen Kunden bzw. dessen Umgebung durchgeführt werden.

SQL-Server

Beginnen möchte ich mit dem wichtigsten Punkt, der Optimierung des SQL-Servers. In vielen Projekten ist der SQL-Server der Flaschenhals der für Performanceprobleme in der SharePoint-Farm verantwortlich ist.

SQL-Alias

Grundsätzlich sollten immer SQL Alias anstelle des SQL-Servernamens verwendet werden. Das hat nicht unbedingt etwas mit Performanceoptimierung zu tun, macht einem aber später das Leben leichter, wenn man sich aufgrund von Performanceproblemen beispielsweise mit dem Thema Skalierung des SQL-Servers befasst und die von SharePoint verwendeten Datenbanken auf mehrere SQL-Server aufteilen möchte. Hat man von Anfang an eine sinnvolle Aufteilung der SQL-Aliase vorgenommen und die Datenbanken aus SharePoint nur über den jeweiligen Alias angesprochen, ist es relativ einfach an dieser Stelle in die Optimierung einzusteigen und die Datenbanken zu verteilen.

Installation

Die SharePoint-Datenbanken sollten immer in einer separaten Instanz liegen, werden die Access-Services eingesetzt, sollten diese ebenfalls ihre Datenbanken in einer separaten Datenbank ablegen. Für größere Suchanwendungen empfiehlt es sich eine separate SQL Instanz für die Suche zu verwenden, da beispielsweise die Suchdatenbank völlig andere Zugriffsmuster haben als die Content-Datenbanken.

Bei der Installation des SQL-Servers sollten die aktuellsten Service Packs und SQL-Patches verwendet werden.

Stehen für den SQL-Server Plattensubsysteme mit unterschiedlicher Geschwindigkeit zur Verfügung empfiehlt sich folgende Reihenfolge für die Priorisierung von Daten (in absteigender Reihenfolge der Plattengeschwindigkeit):

1. Tempdb-Datendateien und Transaktionsprotokolle
2. Datenbank-Transaktionsprotokolldateien
3. Suchdatenbanken, ausgenommen die Suchverwaltungsdatenbank
4. Datenbankdatendateien

Bei einer Portalwebsite mit vorwiegend Lesezugriffen sollten die Daten Vorrang vor Protokollen haben.

NTFS Allocation Unit Size

Die NTFS Allocation Unit Size muss vor der Installation des SQL-Servers richtig konfiguriert werden, da diese nur durch eine Neuformatierung der Festplatten geändert werden kann. An dieser Stelle gibt es oft Diskussionen mit den SAN-Administratoren über die Sinnhaftigkeit der Einstellung, da aus deren Sicht auf ein SAN anders zugegriffen wird als auf im Server verbaute Festplatten. Aus eigener Erfahrung in diversen Projekten empfiehlt es sich trotzdem diese Einstellung anzupassen, die Default-Einstellung liegt bei 4k. Der optimale Wert für einen SQL-Server liegt bei 64k, eine inkorrekte Einstellung bis zu 30% Performanceverlust bedeuten.

Geprüft werden kann die Einstellung mit dem Befehlt chkdsk , geändert wird die Einstellung mit dem Befehl format /Q /FS:NTFS /A:64K /V:
/Y

Windows “Sector Alignment”

Microsoft hat ein Whitepaper zum Disk Alignement und SQL Server 2008 bereitgestellt, welches exakt zeigt, wie man es einstellt, prüft und korrigiert. Auch werden die Auswirkungen detailliert aufgezeigt. Eine inkorrekte Einstellung kann bis zu 50% Performanceverlust bedeuten, da dieselben Daten zweimal schrieben muss. Die Daten werden einmal auf die Partition und dann auf die physische Platte geschrieben. Daher muss sichergestellt sein, dass die Partitionierung mit einer Blockgrösse von 64KB gemacht wurde, seit Windows Server 2008 ist dies die Defaulteinstellung.

Das Dokument finden man hier: http://download.microsoft.com/download/C/E/7/CE7DA506-CEDF-43DB-8179-D73DA13668C5/DiskPartitionAlignment.docx

Die folgende Grafik zeigt die Performanceunterschiede mit Aligned und Unaligned Disks.

Aufteilung der Datenbanken

Die Aufteilung der Datenbanken auf verschiedene Plattensubsysteme ist ebenfalls ein wichtiger Aspekt, da wir es in einer SharePoint-Farm mit Datenbanken zu tun haben, die sehr unterschiedliche Zugriffsmuster haben. Außerdem sind die Logfiles und die TempDB weitere Elemente die gesondert betrachtet werden müssen. Die nachfolgende Abbildung zeigt eine mögliche Verteilung der unterschiedlichen Datenbanken auf verschieden Plattensubsysteme, besonders wichtig ist hierbei, dass es sich um unterschiedliche LUN’s oder Spindeln handelt und somit keine konkurrierenden Datenzugriffe erfolgen, die sich negativ auf die Performance auswirken.

Die Suchdatenbank erzeugt grundsätzlich sehr viele Schreib-/Lesezugriffe und sollte in größeren Umgebungen in eine eigene Instanz gelagert werden.

Das Transaction Log, die Content Datenbanken sowie die Temp DB sollten nach Möglichkeit immer auf einer eigenen LUN liegen, da diese ein komplett unterschiedliches Zugriffsmuster haben. Vor allem die Temp DB mit sehr hohen Schreib-/Lesezugriffen kann hier schnell zu einer Performancebremse werden, wenn die o.a. Aufteilung nicht berücksichtigt wird und diese beispielsweise mit den Content Datenbanken auf einer LUN gespeichert wird. Zum Thema Performanceoptimierung der Temp DB komme ich in einem späteren Abschnitt nochmal separat.

Multiple Datafiles

Die Datenbanken sollten nach Möglichkeit immer auf mehrere Datenfiles verteilt werden, da durch die Round Robin Zugriffe hier eine erhebliche Erhöhung der Performance erreicht werden kann. Da beim Anlegen der Datenbanken über die SharePoint GUI diese Optimierungsmöglichkeit leider nicht genutzt wird, ist es umso wichtiger die Datenbanken vor ab per Script zu erstellen.

Fill Factor der Datenbanken

Standardmäßig steht die seEinstellung auf 100%, was eine Fragmentierung des Index beim ersten Insert zur Folge hat. Jede Fragmentierung wirkt sich negativ auf die Performance des SQL-Server auas und sollte daher vermieden werden. Aus diesem Grund sollte der Wert auf 70% oder 80% eingestellt werden, um sicherzustellen, dass der Index weniger schnell fragmentiert. Neue Datensätze so in die leeren 20% oder 30% eingefügt.

T-Log Backup alle 15min bis max. 24h

Viele SharePoint Datenbanken sind im Standard auf Fullrecovery Mode eingestellt. Wenn keine Datenbankwartungspläne vorhanden sind und keine regelmäßigen Logfile Backups erstellt werden, wird das Logfile immer weiter wachsen und unter Umständen den gesamten zur Verfügung stehenden Speicherplatz belegen. Ein regelmäßiges Logfile Backup stellt sicher, dass alles in die Datenbank geschrieben und das Logfile zum Überschreiben freigegeben wird. Wenn keine regelmäßigen Logfile Backups erstellt werden, sollte zwingend der Recovery Mode auf Simple umgestellt werden, allerdings nimmt man sich im Recoveryfall einige Optionen zur granularen Wiederherstellung der Daten.

Max Degree of Parallelism

In SharePoint 2010-Umgebungen wurde dieser Parameter oft falsch gesetzt, SharePoint 2013 lässt sich nicht mehr installieren, wenn der Parameter falsch gesetzt ist. Der Wert geregelt, wie viele Threads gleichzeitig für eine Query auf die Prozessoren verteilt werden. Die Standardeinstellung ist 0 was bedeutet, dass der SQL entscheidet. Da SharePoint hat eine sehr hohe Anzahl an gleichzeitig zu verarbeitenden Abfragen aufweist, ist ein möglichst tiefer Wert zu setzen, deshalb ist der optimale Wert für eine SharePoint-Umgebung 1.

Min und Max Memory konfigurieren

Der SQL Server ist besonders Ressourcenhungrig und sollte immer über Speicher verfügen. Allerdings sollte auch das Betriebssystem noch über genügend Ressourcen verfügen. Als Faustregel hat sich bewährt den Wert für Max Memory auf den installierten Speicher – 3GB für das Betriebsystem einzustellen. So wird verhindert dass der SQL Server den gesamten zur Verfügung stehenden Speicher allokiert und das Betriebssystem Probleme bekommt.

Mit der folgenden Formel kann der Speicherbedarf für eine SharePoint-Instanz berechnet werden:

SQL Max Memory = TotalPhyMem – (NumOfSQLThreads * ThreadStackSize) – (1GB * CEILING(NumOfCores/4))

NumOfSQLThreads = 256 + (NumOfProcessors*- 4) * 8 (* If NumOfProcessors > 4, else 0)

ThreadStackSize = 2MB on x64 or 4 MB on 64-bit (IA64)

Temp DB

Die Temp DB ist ein der wichtigsten und am stärksten belasteten SharePoint-Datenbanken, da Datenbankengne sie für temporäre Benutzerobjekte, interne Objekte, als Versionsspeicher für Datenänderungstransaktionen sowie als Service Broker, für Datenbankmail und Query notifications nutzt. Thorsten Schüßler hat die Temp DB in seinem Vortrag beim SQL Saturday zum Thema „Performance & Manageability der tempdb“ die gut organisierte Kramschublade der Database Engine genannt, was es glaube ich ganz gut trifft. Wichtig ist hierbei dass die Temp DB groß genug ist und die Datenbank auf mehrere Datenfiles verteilt ist. Als Faustregel gilt hier dass bei weniger als 8 Kerne die Anzahl der Datenfiles gleich der Anzahl der Kerne sein sollte. Bei mehr als 8 Kerne sollte die Anzahl der Datenfiles nicht größer als 8 sein. Die Größe der Temp DB lässt sich wie folgt berechnen:

• Datendatei = (Volumengröße * 80%) / (n Datendateien + 2)
• Protokolldatei = Datendatei * 2
• Beispielrechnung für 100GB Volumen, 1 Datendatei pro CPU , 8 logische CPUs:
• Datendatei = (100 GB * 80%)/(8+2) = 8GB
• Protokolldatei = 8GB * 2 = 16GB

Folgende Konfigurationsparameter haben sich hier als erfolgreich erwiesen:

• 1:1 vs 1:2 oder 1:4
• Datendateien und Protokolldateien vorher skalieren
• Datendateien der gleichen Größe und Einstellungen
• Sofortige Dateiinitialisierung
• Trace flag: -T1118 und/oder –T1117
• Regelmäßige Kontrolle der tempdb – Größe und Latches
• RAM und Festplatten-System in Einklang bringen

Lock Pages in Memory (für SQL Std. –T845) für SQL Account setzen

Lock Pages in Memory erlaubt dem SQL Server Speicher direkt Memory zu allokieren und verhindert das OS Paging für von SQL Server belegten Arbeitsspeicher.

Perform Volume Maintennance Tasks für SQL Account setzen

Perform Volume Maintennance Tasks gibt dem SQL-Server das Recht, beim Erstellen einer Datenbank Start und Endpunkt auf der Disk zu setzen und die Zero File Initialization für Datenbankdateien zu verhindern. Die Erstellung von Datenbanken wird hierdurch erheblich schneller.

Traceflag 1117 (-T1117) für gleichmässiges Dateiwachstum

Hierbei handelt es um ein Undocumented Flag, welches in den Startup Parametern der SQL Instanz gesetzt werden muss. Es sorgt dafür dass die Datenfiles bei Verwendung mehrerer Datenfiles gleichmäßig wachsen. Wird dieses Flag nicht gesetzt, so füllt der SQL-Server alle Files gleichzeitig, wenn alle voll sind wächst File 1 und wird zuerst wieder gefüllt dann wächst File 2. Das Wachstum der Datenbank-Dateien erfolgt durch das Setzen des Traceflags synchron.

Backupcompression einschalten

Das Backup wird durch die Komprimierung schneller und kleiner. Allerdings geht diese Option zu Lasten der CPU, was bei den meisten der heute eingesetzten Server vernachlässigbar sein sollte.

Index Maintennance <=30% Reorganisation, sonst Rebuild

Die Indizes sollten regelmäßig defragmentieren werden, da sich dies nachhaltig auf die Performance auswirkt. Hierzu sollte man Zeiten mit geringer Last auswählen und die periodische Prüfung der Indizes einplanen. Unter 30% Fragmentierung ist eine Reorganisation möglich, sonst muss der Index neu erstellt werden. Es sind SharePoint Health Analyzer-Rules hierfür vorhanden, deren Durchführungszeitpunkt optimiert werden sollte. Zusätzlich sollte dbo.Proc_DefragIndexes jeder SharePoint-Datenbank per SQL Server Agent-Task nächtlich ausgeführt werden. Sollte ein Indexrebuild erforderlich sein, empfiehlt es sich, Max Degree of Parallelism wieder auf 0 zu stellen, da die Reorganisation bzw. der Rebuild schneller abgeschlossen wird. Anschließend muss der Wert weder auf 1 umgestellt werden.

Update Statistics

Es ist besonders wichtig richtige Statistiken zu haben, da von Aktualität und Richtigkeit der Statistiken die Auswahl des richtigen Index-Modells abhängt. Daher sollte täglich über einen Wartungsplan ein Update Statistics erfolgen.

DBCC Checkdb

Vor jedem Full Backup sollte die Konsistenz der Datenbanken mittels DBCC CHECKDB geprüft werden, um zu verhindern dass inkonsistente Daten gesichert werden. Die Prüfung sollte in Zeiten mit wenig Last durchgeführt werden.

Performance, IOPS und Anzahl Disks

Bei jedem Server, der eine SQL Server-Instanz hostet, ist es sehr wichtig, dass das E/A-Subsystem dem Server die schnellstmögliche Reaktionszeit liefert. Das Platten-Sub-System sollte über ausreichende Leistungsreserven verfügen, um die Anforderungen großer Inhaltsdatenbanken verarbeiten zu können. Microsoft gibt hierfür einen Richtwert von 0,75 IOPs pro GB bzw. 2 IOPs pro GB für den optimalen Betrieb an.

Typ	RAID Level	IOPS	SAN Optimimierung
Tempdb	RAID-10	2 IOPS/GB	Write optimized
Transaction logs (ldf)	RAID-10	2 IOPS/GB	Write optimized
Search Database (mdf, ndf)	RAID-10	2 IOPS/GB	Read/Write optimized
Content Databases (mdf, ndf)	Raid-10*	0,75 IOPS/GB	Read optimized

* Raid-5 bei statischen Inhalten ausreichend

• AntiVirus KonfigurationFür SQL-Server sollten folgende Verzeichnisse von der Virenprüfung ausgeschlossen werden:
• Ein Punkt der immer wieder gerne vergessen wird ist, beim Einsatz eines Virenscanners auf dem SQL-Server (aber auch auf dem SharePoint-Server) die entsprechenden Ausnahmen zu definieren.

• Datenbanken
• Transaction Log
• Backup Dateien

Für SharePoint Server findet man die Ausnahmen in diesem KB-Artikel http://support.microsoft.com/kb/952167/de