PostgreSQL gilt seit Jahren als das fortschrittlichste Open-Source-Datenbankmanagementsystem und ist millionenfach im Einsatz. Ein Thema, das PostgreSQL-Administratoren unter anderem beschäftigt, ist Performance-Tuning – also die Frage, wie Anfragen und SQL-Befehle schneller gemacht werden können. Dieser Frage und anderen widmen sich auch die Autoren Peter Eisentraut und Bernd Hemle in ihrem Buch „PostgreSQL-Administration„. Wie man Enpässe oder Flaschenhälse, die die Ausführung eines SQL-Befehls verlangsamen, richtig erkennt und optimiert, erfahren Sie im ersten Teil des Buchauszugs. Heute geht es um CPU, RAM und Festplattendurchsatz. Im zweiten Teil wird es dann um Festplattenlatenz, Festplattenrotation und Netzwerkverbindungen gehen.
CPU
PostgreSQL startet pro Datenbankverbindung einen Prozess, und moderne Betriebssysteme verteilen diese Prozesse dann auf mehrere CPU-Kerne, falls vorhanden. Generell kann aber somit ein SQL-Befehl nur auf maximal einem CPU-Kern laufen. Sehr rechenintensive SQL-Befehle können einen CPU-Kern schon eine Weile auslasten. Das kann man dann einfach mit Betriebssystemwerkzeugen wie ps oder top beobachten. In der Praxis ist die CPU aber im Gegensatz zu den anderen aufgeführten Kandidaten eher selten das Problem. Wenn doch, dann bleibt einem in der Regel nichts anderes übrig, als die Anfrage oder das Datenbankschema umzuschreiben, und zum Beispiel andere Datentypen zu verwenden.
RAM
Beim RAM ist das Problem normalerweise nicht die Geschwindigkeit, sondern die Menge. Zu wenig RAM bedeutet zu wenig Cache, und zu wenig Cache bedeutet zu viele langsame Festplattenzugriffe. Generell ist eine Analyse des Cacheverhaltens in einem laufenden PostgreSQL-Datenbanksystem schwierig. Deshalb sollte man hier vorsorgen: Im Idealfall wird man das RAM so groß einbauen, wie die Datenbank ist, mindestens aber so groß, dass alle aktiven Indexe gleichzeitig im RAM gehalten werden können. Alternativ oder ergänzend sollte man auch die Indexe so setzen oder ändern, dass sie ins RAM passen. Das könnte zum Beispiel bedeuten, dass mehrspaltige Indexe reduziert und redundante entfernt und partielle Indexe verwendet werden.
Festplattendurchsatz
Der Festplattendurchsatz, also die Menge der Daten, die pro Zeiteinheit von der Festplatte gelesen werden kann, liegt gegenwärtig bei herkömmlichen mechanischen Festplatten bei bis zu 150 MByte/s, bei SSDs bei bis zu 300 MByte/s, bei RAID-Systemen und RAMgepufferten Speicherverfahren bei bis zu 500 MByte/s und mehr. Beobachten kann man den aktuellen Durchsatz des Festplattensystems zum Beispiel mit dem Programm iostat. Dabei kann man darauf achten, ob die Hardware auch wirklich den erhofften Durchsatz bringt oder nicht optimal konfiguriert ist.
Generell ist der Festplattendurchsatz subjektiv immer viel zu langsam, weswegen einerseits darauf abgezielt werden sollte, viel RAM als Cache zur Verfügung zu stellen, und andererseits passende Indexe erstellt werden sollten, um die Menge der zu lesenden Daten von vornherein zu reduzieren. Diese beiden sind letztlich die üblichsten, aussichtsreichsten und verlässlichsten Maßnahmen bei der Optimierung von SQL-Anfragen in PostgreSQL.
Zu bemerken ist, dass die Datenmenge, die in Datenbanksystemen gespeichert werden soll, in der letzten Zeit sehr viel schneller gewachsen ist als der Festplattendurchsatz. Durch verbesserte Indexmethoden und gewachsene Ausbaumöglichkeiten beim RAM fällt dieser Umstand bei Suchanfragen und OLTP-artigen Anwendungen weniger ins Gewicht. Bei Anfragen aber, die ganze Tabellen betrachten (wie statistische Auswertungen, Data Mining oder Datensicherungen mit SQL-Dumps), ist der Festplattendurchsatz meist der begrenzende Faktor. So dauert das Lesen einer 50 GByte großen Tabelle, etwa zwecks count(*), bei 150 MByte/s praktisch erreichbarem Durchsatz beispielsweise mindestens fünf inuten. Anwendungen, die hier Antworten »sofort« benötigen, haben also keine Chance ohne anwendungsspezifische Umgehungsmaßnahmen. Schnellere Hardware kann Verbesserungen um einstellige Faktoren ermöglichen (bei überproportionalen Kosten), aber das Problem nicht gänzlich aus der Welt schaffen. An dieser Stelle ist dann also die Kreativität des Anwendungsentwicklers gefragt.
Im O’Reilly Verlag ist soeben die zweite Auflage des Buchs „PostgreSQL-Administration“ von Peter Eisentraut und Bernd Helmle erschienen. In der komplett aktualisierten Auflage erläutern die Autoren, wie der Zustand und das Verhalten eines PostgreSQL-Servers überwacht und analysiert werden können, wie man SQL-Befehle schneller machen kann oder wie Daten vor unberechtigtem Zugriff abgesichert werden können.
Teil 1/2