Diesen Post habe ich heute auf www.sharepointadvent.de gepostet, ein Gemeinschaftsprojekt der deutschsprachigen MVPs. Ich will ihn euch nicht vorenthalten 
Sehr oft wird SharePoint eingesetzt, ohne dass durchwegs bekannt wäre, welche Komponenten alle berücksichtigt werden müssen. Mit dem Begriff “SharePoint” wird dann vor Allem eine Office ähnliche Software gemeint, mit welcher man zusammenarbeiten kann.
Nicht weniger oft wird dann SharePoint mit weiter, weiter, Fertigstellen installiert, und damit hat sich’s dann. Best Practices werden zwar im Bereich AD, Windows Server usw. bereits vielerorts angewandt, aber SharePoint ist oft ein Buch mit sieben Siegeln. Auch dafür gibt es ganz viele Grundlagen, die man berücksichtigen muss. Auf eine dieser Grundlagen will ich heute eingehen.
Es gibt eine ganz einfache Grundregel im Bereich Performance und die heisst SQL Server langsam = SharePoint langsam. SharePoint ist eine Webapplikation und von dieser erwartet der Enduser eine Klick and Run Experience. Wenn er diese nicht erhält, dann wird sofort auf SharePoint geschimpft, obwohl das Problem in den meisten Fällen an einem anderen Ort liegt. Ein Frontend kann 15 bis 20’000 User bedienen mit einer 10% Concurrency. Heisst, alle Kleinen und mittleren Unternehmen könnten mit einem starken Frontend auskommen. Das zweite Frontend wird meist nur für die Ausfallsicherheit eingesetzt.
Wo liegt also oft das Problem? Primär an zwei Orten:
- Dem SQL Server
- Dem Disksubsystem
Es gibt Regeln, wie ein SQL Server aufgesetzt werden sollte, um die Performance zu erhöhen. Auch gibt es Regeln, wie ein Disksubsystem sein sollte, wenn man SharePoint Datenbanken darauf hosten will.
Der SQL Server
Hier ein paar Grundregeln, wie der SQL Server konfiguriert werden muss:
Beginnen wir einmal bei der Aufteilung der Datenbanken. Wir unterscheiden High und Low Traffic Datenbanken, verschiedene Zugriffsmuster und die Logfiles.
Die Suchdatenbank ist grundsätzlich die User DB mit dem grössten Traffic Read und Write. In grösseren Umgebungen macht es sinn, diese komplett in eine eigene Instanz auszulagern, um die restliche SharePoint Installation nicht zu gefährden. In kleinen bis mittleren Farmen kann diese auch in die normale SharePoint Instanz integriert sein. Grundsätzlich sollte aber in einer SharePoint Instanz nichts anderes laufen als SharePoint.
Stellen Sie sicher, dass Transaction Log, User DBs und die Temp DB auf eigenen LUNs in ihrem SAN liegen, d diese ein komplett unterschiedliches Zugriffsmuster haben. T-Log ist Sequential Write, User DBs sind verschieden: Content DBs sind Moderate Read und die Search ist Heavy Read/Write. Die Temp DB ist die schlimmste und ist Heavy Read/Write. Wenn nicht zumindest die Aufteilung wie oben erwähnt gemacht wird, werden sich die verschiedenen Daten gegenseitig ausbremsen.
Kommen wir zu den Einstellungen auf dem SQL Server:
Multiple Datafiles
Stellen Sie sicher, dass alle Datenbanken auf mehrere Datenfiles aufgeteilt sind. Dies erhöht die Performance erheblich. Erstellen Sie die DBs per Script und nicht per “Create New Content DB” Button. Details dazu in meinem nächsten Post später im Advent.
Fill Factor auf 70% setzen
Diese Einstellung stellt sicher, dass Ihr Index weniger schnell fragmentiert. Wenn neue Datensätze eingefügt werden müssen, so werden diese in die leeren 30% eingefügt. Normalerweise ist der Fillfactor auf 100% und somit fragmentiert der Index beim ersten Insert. Jede Fragmentierung verlangsamt den SQL Server
T-Log Backup alle 15min bis max. 24h
Dies ist weniger ein Performance Issuer als ein Platzfresser. SharePoint Datenbanken sind per Standard auf Fullrecovery Mode eingestellt. Wenn Sie keine Log Backups machen, wird Ihnen das Logfile unter Umständen immer weiter wachsen. Ein Logbackup stellt sicher, dass alles in die DB geschrieben wurde und gibt das Log frei zum überschreiben. Zudem haben Sie eine zusätzliche Sicherheit zu Ihren Backups im Desasterfall.
Disable Boost SQL Server Priority
Diese Einstellung verleitet oft zum einschalten, ist aber im SharePoint Umfeld aufgrund der speziellen Konstellation von SharePoint eher hinderlich.
Max Degree of Parallelism 1 (für SharePoint only Instanzen)
Hier wird geregelt, wie viele Threads gleichzeitig für eine Query auf die Prozessoren verteilt werdne. Normalerweise ist die Einstellung auf 0, und der SQL entscheidet. Für SharePoint ist es besser, wenn eine Query immer nur auf eine Thread läuft, dies hat sich in Tests gezeigt.
Min und Max Memory konfigurieren
Stellen Sie sicher, dass der SQL Server genügend Memory bekommt, dass das Betriebssystem aber nicht zu leiden beginnt. Faustregel ist Memory Installed – 3GB = Max Memory. Wenn man die automatische Einstellung lässt, nimmt sich SQL was er bekommt. Wenn das Betriebssystem anfängt zu schreien, gibt er nach und nach frei, doch dann ist es meist bereits zu spät.
Temp DB auf 10GB und 4 Files verteilen, Autogrowth 1GB
Die Temp DB ist die meist belastete DB bei SharePoint, da jede Liste die in irgendeiner Art gruppiert oder sortiert ist, zuerst durch die Temp DB läuft. Machen Sie diese genug gross und verteilen Sie die DB auf mehrere Datenfiles. So wird die DB beim Start immer 10GB sein und wird somit durch die Wachserei und dadurch die Fragmentierung nicht langsam.
Lock Pages in Memory (für SQL Std. –T845) und Perform Volume Maintennance Tasks für SQL Account setzen
Lock Pages in Memory erlaubt dem SQL Server direkt Memory zu allozieren. Perform Volume Maintennance Tasks gibt SQL das Recht, beim Erstellen der DB Start und Endpunkt auf der Disk zu setzen, die Erstellung wird dadurch erheblich schneller. wird der Diskspeicher mit lauter Nullen aufgefüllt.
Traceflag 1117 (-T1117) für gleichmässigen Filegrowth
Dies ist ein Undocumented Flag und wird in den Startup Parametern der SQL Instanz gesetzt. Es garantiert den gleichzeitigen Growth mehrerer Datenfiles. Warum man mehrere Datenfiles machen sollte und wie, dazu später im Adventsblog. Wird dieses Flag nicht gesetzt, so füllt SQL alle Files gleichzeitig, wenn alle voll sind wächst File 1 und wird zuerst wieder gefüllt dann wächst File 2 etc… Das ist gerade nicht der Effekt, den man sich von mehreren Datenfiles erhofft.
Backupcompression einschalten
Das Backup wird schneller und kleiner. Was will man mehr? Dies geht zu Lasten der CPU, doch das ist vernachlässigbar.
Index Maintennance <=30% Reorganisation, sonst Rebuild
Der Index trägt nachhaltig zur Geschwindigkeit der Datenbanken bei. Man sollte darauf achten, dass periodisch die Indizes geprüft werden. Unter 30% Fragmentierung ist eine Reorganisation möglich, sonst muss der Index rebuildet werden.
Für den Indexrebuild empfhiehlt es sich, Max Degree of Parallelism wieder auf 0 zu stellen, da die Reorganisation bzw. der Rebuild schneller über die Bühne geht. Danach wieder zurück auf 1.
Update Statistics täglich, DBCC Checkdb vor Fullbackup
Mit Update Statistics wird der Einstiegspunkt festgelegt, damit nicht immer ein Fulltablescan gemacht werden muss. DBCC Checkdb verifiziert die Datenbanken auf ihre Konsistenz. ACHTUNG Repair with Dataloss ist im SharePoint nicht supportet!
To BLOB or not to BLOB
Zu guter letzt sollte man sich auch Gedanken über RBS machen. Es gab eine Studie, wonach Files < 1MB schneller vom SQL und >1 MB schneller vom Filesystem gestreamt werden. Auch kann der RBS auf günstigeren Disks liegen, was die Gesamtkosten der Infrastruktur senkt. Bitte aber genau prüfen, bevor man da einsteigt. Die Backup Restore Szenarien verkomplizieren sich nämlich durch RBS 😉
Und noch was zum Schluss: Never Virtualize an SQL Server (meine persönliche Meinung, die ein paar Cracks der Microsoft Consulting Services mit mir teilen…)
Das Disksubsystem
Disk Alignement
Auch auf dem Disksubsystem gibt es einiges zu beachten. Wenn nämlich mal der SQL mal sauber aufgesetzt und konfiguriert ist, kommt noch das Disksubsystem, auf welchem die Daten liegen. Of wird dies als “Grosser Kübel” hingestellt und gut ist. Dass sich aber Threads gegenseitig ausbremsen, daran denkt niemand. Beginnen wir mal ganz unten, nämlich beim Disk Alignement. Wurde das Disk Alignement falsch gemacht, verursachen sie dem Disksubsystem Schmerzen, da es defakto die selbe Info zweimal schrieben muss. Einmal auf die Partition und dann noch auf die physische Disk. Stellen Sie sicher, dass die Partitionierung mit einer Blockgrösse von 64KB gemacht wurde. Ältere Systeme haben eine Blockgrösse von 4KB was denkbar schlecht ist.
Hier die Performanceunterschiede mit Aligned und Unaligned Disks:
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 detailiert aufgezeigt.
Hier der Link: http://download.microsoft.com/download/C/E/7/CE7DA506-CEDF-43DB-8179-D73DA13668C5/DiskPartitionAlignment.docx
Performance, IOPS und Anzahl Disks
Es gibt ganz viele Hersteller, die behautpen, das beste Disksubsystem für SharePoint zu haben. Ich sage dazu nur eines: Kein RAID10, kein gutes Disksubsystem für SharePoint. Grundsätzlich geht es um Performance, und da ist RAID10 nicht zu überbieten, auch wenn es notabene das verschwenderischste ist, da die zwei Platten welche zusammen mehr performance ergeben und zusätzlich noch gespiegelt werden. Man kann also genau 50% des eingekauften Speicherplatzes effektiv nutzen, was eigentlich eine schlechte Ausbeute ist.
Wir wollen aber Performance und daher wird auch von Microsoft dringend RAID10 empfohlen. Dann können Sie auch als Grundregel nehem, was unter 140 MB/s Throughput hat ist zu langsam. Diese Rechenmethode hat ihre Grenzen, denn sie sagt alleine nicht viel aus.
Sicherer ist mit IPOS zu rechnen. Hier ist die Faustregel 2 IOPS pro GB Daten. Da wird schnell klar, dass wir schnell mal ein paar IOPS auf unserem Disksubsystem brauchen.
Wichtige Grundregel beim Disksubsystem ist auch die Anzahl Disks, nicht nur der benötigte Platz sonder die Anzahl Spindeln, welche den IO verarbeiten sind hier die wichtigen Faktoren.
Es empfiehlt sich, einige Tests mit SQLIO zu machen.
Zum Tool: http://www.microsoft.com/download/en/details.aspx?id=20163
zur Beschreibung: http://technet.microsoft.com/en-us/library/cc966412.aspx
So, nun habe ich erstmal genug losgelassen, ich lass euch das ganze erst mal verdauen.
So long, Samuel
sharepointszu 