Der Microsoft SQL-Server ist eine performante und leistungsfähige Datenbank-Engine, welche von CodX PostOffice teilweise sehr intensiv genutzt wird.
Wir stellen im täglichen Betrieb teilweise Performance-Probleme fest, welche im Zusammenhang mit dem Microsoft SQL-Server und dessen Installation und Konfiguration zusammenhängt. Dieser WS-Artikel soll ein paar Tipps und Tricks beschreiben, welche für den performanten Einsatz für CodX PostOffice wichtig sind.
Zutaten für einen performanten SQL-Server für CodX PostOffice
Wir beschreiben hier die wichtigsten Zutaten für einen performanten SQL-Server für den Einsatz mit CodX PostOffice. Andere Anwendungen setzen unter Umständen andere Prioritäten.
1. RAM, RAM, RAM
Die wichtigste Zutat für einen performanten SQL-Server ist RAM. Mit heutigen 64-Bit-Servern ist es keine grosse Sache mehr, mehrere Giga-Bytes an RAM nutzen zu können. Wir empfehlen mindestens die Hälfte der Grösse der installierten Datenbanken dem SQL-Server an RAM zur Verfügung zu stellen. Hat also die Datenbank eine Grösse von 20 GB, so soll der Server mindestens 10 GB RAM dem SQL-Server bereitstellen können.
Der SQL-Server nutzt so viel RAM er kann um Daten zwischen zu speichern. Können Daten aus dem RAM genommen werden, ist dies viel schneller als wenn diese von der Disks gelesen werden müssen. Je mehr RAM dem SQL-Server zur Verfügung steht, umso weniger Diskzugriffe sind nötig und je schneller wird der SQL-Server.
Teilweise fällt auf, dass der SQL-Server alles verfügbare RAM besetzt. Dies ist ein gutes Zeichen, denn damit schöpft dieser das gesamte Potential des Servers aus. Aufgrund der natürlichen Speicher-Fragmentierung sollte jedoch der SQL-Server alle paar Wochen rebooted werden. Werden die normalen Windows-Updates alle 4 Wochen nachgezogen, so ergibt sich dies automatisch.
2. Disks, Disks, Disks
Die zweite wichtige Zutat sind Disks. Wenn sich die Daten nicht im RAM befinden, so müssen diese von der Disk gelesen werden. Werden Daten in die Datenbank geschrieben, so müssen die Disks damit beschäftigt werden.
Der SQL-Server hat immer mehrere Dateien geöffnet. Mindestens ein Datenbank-File (mdf) und das Log-File (log) ist immer vorhanden. Der SQL-Server liest und schreibt jedes File immer unabhängig von den anderen.
Je mehr Files also im Einsatz sind, desto schneller wird der SQL-Server. Aus diesem Grund haben wir früher immer empfohlen mindestens drei Datenbank-Files und ein Log-File anzulegen. Der Nutzen ist jedoch nur dann da, wenn mehrere 'Spindeln' eingesetzt werden, denn es sind die Spindeln oder die Leseköpfe der Disks, welche den Flaschenhals darstellen. Wird also eine grosse Disks in drei Partitionen aufgeteilt und die Files darauf verteilt, ist der Nutzen sehr bescheiden.
Besser ist der Einsatz eines RAID 1 (zwei Disks parallel) pro File. Das ergibt dann zusammen mit den System-Disks 8 Disks, welche parallel im Einsatz stehen. Damit erzielt man die grösste Performance.
Das Log-File und die Datenbank-Files werden komplett unterschiedlich genutzt. Während der Zugriff auf die Datenbank-Files immer zufällig ist (viel Bewegung der Leseköpfe), ist der Zugriff auf das Log-File streng sequenziell (wenig Bewegung der Leseköpfe). Wird nun also das Log-File auf eine Disk gelegt, wo die Datenbank-Files (oder andere häufig zugegriffene Files) befinden, so muss auch für das Schreiben des Log-Files der Lesekopf viel bewegt werden, was zu schlechter Schreib-Performance führt. Aus diesem Grund empfehlen wir, mindestens das Log-File auf eine separate Disk (RAID 1) zu legen.
Das beste Mittel um die Auslastung von Disks zu messen ist die Länge der Datenträgerwarteschlange (Disk Queue). Diese kann einfach durch den Ressourcenmanager angezeigt werden (Tab Datenträger). Diese Warteschlange zeigt an, wie viele Befehle auf die Ausführung warten. Je mehr Befehle warten und nicht bearbeitet werden können, je langsamer ist das System. Die Datenträgerwarteschlage sollte im Mittel den Wert 2 nicht übersteigen!
Wie sieht das nun aus mit SSDs? Bei SSDs ist die Zugriffszeit kein Thema mehr, jedoch noch immer der Datendurchsatz. Nur sehr schnelle (und teure) Server-SSDs schaffen heute den maximalen Datendurchsatz von mehreren PCI-Lanes. Zudem ist die Anzahl der Schreibzugriffe noch immer beschränkt, auch wenn diese in den letzten Jahren stark zugenommen haben.
Werden für Logs und Datenbank-Files SSDs eingesetzt, so ist die Performance des SQL-Servers sehr gut. Dies schlägt sich jedoch in den Investitionskosten nieder.
Aus Kostengründen kann ein Mix aus SSDs und magnetischen Disks gefahren werden. In diesem Fall empfehlen wir, zumindest die Logs auf eine SSD zu legen. Wird die Online-Datenbank auf eine SSD gelegt, so beschleunigt dies das System zusätzlich. Das Archiv oder die Image-Datenbank auf SSDs zu legen, macht aus Kostengründen wenig Sinn. Diese Datenbanken sind gross und werden meist wenig gebraucht.
Wichtig bei SSDs ist, dass diese nicht mehr als ca. 60% gefüllt werden. Eine SSD, welche nahezu randvoll ist, beschäftigt sich selber mit der Reorganisation und ist dadurch nicht mehr viel schneller als eine normale magnetische Disks.
3. CPU, CPU, CPU?
Der SQL-Server unter CodX PostOffice braucht nur sehr wenig CPU. Wir hören von Kunden vielfach, dass sie die Auslastung des SQL-Servers anhand der CPU-Auslastung gemessen haben und keine Last feststellen konnten. Trotzdem ist der SQL-Server sehr langsam. Das hängt damit zusammen, dass die CPUs auf die langsamen Disks wartet und somit wenig Last anzeigen. Die Gesamtperformance des SQL-Servers bleibt jedoch schwach.
Die Last des SQL-Servers unter CodX PostOffice kann nicht durch die Auslastung der CPU gemessen werden!
Sind die CPUs durch den SQL-Server hoch ausgelastet, so weist dies auf einen Konfigurationsfehler oder auf einen fehlenden Index hin.
4. Server, Server, Server?
CodX PostOffice unterstützt den Einsatz von mehreren Applikations- und Datenbank-Servern. So kann pro Datenbank (Online, Archiv und Image) unterschiedliche Datenbank-Server eingesetzt werden. Auch der Service von CodX PostOffice lässt sich auf mehrere Server verteilen um die Performance des Gesamtsystems zu steigern.
Dies ist jedoch nur bei sehr grossen Systemen im Einzelfall nötig. Im Normalfall können bei richtiger Konfiguration alle Datenbanken und der Applikations-Service auf dem selben (virtuellen) Server installiert werden (Variante A). Voraussetzung ist, dass die obenstehenden Tipps befolgt wurden und das System richtig konfiguriert ist.
5. DBMaintenance-Server
CodX PostOffice hat ein DBMaintenance-Server eingebaut. Dieser Server führt zyklisch Optimierungen an der Datenbanken von CodX PostOffice durch. Diese Optimierungen sind auf die Anwendung von CodX PostOffice zugeschnitten und wirken besser, als die allgemeinen Optimierungen, welche durch die SQL-Agent-Jobs ausgeführt werden.
Wir empfehlen die Optimierungs-Jobs des SQL-Agents zu deaktivieren und die Wartungsarbeiten durch den DBMaintenance-Servers ausführen zu lassen. Bitte beachten Sie dazu die entsprechende Online-Hilfe.
6. Reboot
Ab und zu ist ein Reboot des SQL-Servers (inkl. Windows Server) hilfreich. Normalerweise wird dies einmal pro Monat am Patchday von Microsoft durchgeführt.
Zusammenfassung
Hier nochmals die Kurzfassung:
- RAM: Mindestens die Hälfte der Grösse der installierten Datenbanken an RAM dem SQL-Server zur Verfügung geben!
- Disks: Getrennte RAID 1 - Systeme für Datenbank- und Log-File einsetzen oder SSD für Log und Online-Datenbank und RAID 1 - Systeme für Image und Archiv
- Disks: Disks Queue beobachten: sollte im Mittelwert pro Disk nicht grösser als 2 sein!
- CPU: Auslastung des SQL-Servers nicht anhand der CPU-Auslastung messen!
- Kleine Systeme: Variante A einsetzen: alles auf einem Server installieren und Server korrekt konfigurieren
- Grosse Systeme: Variante B einsetzen: (virtueller) Server für Applikation; (virtueller) Server für alle Datenbanken
- DBMaintenance-Server von CodX PostOffice gemäss den Empfehlungen der Online-Hilfe einstellen.
- Reboot