Open Source im professionellen Einsatz
Linux-Magazin 07/2013
© Marcel Schauer, 123RF.com

© Marcel Schauer, 123RF.com

Performance-Tuning für PostgreSQL-Datenbankserver

Aufgemotzt

,

Viele Admins lassen PostgreSQL-Installationen im Auslieferungszustand laufen. Das ist oft ein Fehler, denn die Datenbank bringt viele Stellschrauben mit, um dem Server Beine zu machen. Wer die kennt, spart sich den Griff zum Geldbeutel für neue Hardware und erfreut seine Clients, User und Controller.

811

Weit unter seinen Möglichkeiten bleibt, wer einfach die Vorgaben der Distributoren übernimmt. Die Annahme bewahrheitet sich nicht immer, doch gerade Datenbanken bieten dem Admin zahllose Stellschrauben.

Je nach Anwendungszweck, Datenart und auch Art der Datenbank hat der Admin hier viele Optionen. Welche, das zeigt exemplarisch der folgende Artikel.Anhand der Version 9.2 von PostgreSQL nimmt er sich Stellschrauben für effizientes Tuning vor und legt den Fokus auf Maßnahmen, mit denen ein Administrator die Leistungsfähigkeit seiner Datenbankserver schnell und einfach erheblich steigern kann. Außerdem nennt er die umfangreichen, eingebauten Hilfsmittel, die die beliebte Datenbank mitbringt.

Den Erfolg der Maßnahmen zeigt Abbildung 1. Die Messung fand auf einem Quadcore-Xeon-System mit einem Raid 10 aus SAS-Platten mit 10  000 Umdrehungen statt. Darauf lief in einer virtuellen Maschine (KVM, 12 Gbyte RAM) Gentoo mit Kernel 3.8.4 und der neuesten PostgreSQL-Version 9.2.4 [1].

Abbildung 1: Ohne Write-Ahead-Log gibt's bis zu sechs Mal schnellere Ergebnisse - aber wer kann sich das leisten? Sinnvoller sind Speicher-, Kernel- und Datenbanktuning, da sie die Leistung einer PostgreSQL-Datenbank mehr als verdoppeln können.

Kritisch: Die Umgebung

Die Leistung eines PostgreSQL-Servers hängt direkt und entscheidend von der Umgebung ab, in der ihn sein Admin betreibt (Hardware, Betriebssystem, die PostgreSQL-Version und wie darüberliegende Anwendungen das RDBMS nutzen). Der Artikel geht in der Reihenfolge vor, in der die einflussnehmenden Komponenten aufeinander aufbauen – von unten nach oben.

Weil relationale Datenbanken gerne umfangreiche Lese- und Schreibprozeduren veranstalten, ist ein schnelles Plattensubsystem essenziell für die Performance. Dabei sind die erzielbaren IO-Operationen pro Sekunde wichtiger als die Werte für das sequenzielle Lesen oder Schreiben. Je nach zu erwartender Größe der Datenbank gibt es mehrere Möglichkeiten: Am performantesten sind derzeit SSD-basierte Systeme. Sie bieten nicht nur sehr hohe Lese- und Schreibraten, sondern glänzen auch durch kurze Zugriffszeiten. Für SSDs wie herkömmliche, mechanische Platten gilt jedoch gleichermaßen das Datenbank-Credo:

  • Mehr Platten sind besser.
  • Schnellere Platten (10  000 oder 15  000 Umdrehung pro Minute) sind besser.
  • Raid 10 oder 50 ist besser als Raid 5.

Bevor der Admin seine Daten nun an den Server übergibt, sollte er die Anwendung, ihr Verhalten und ihre spezielle Arbeitsweise untersuchen. Erst dann kann er über die richtige Verteilung der Daten im Subsystem entscheiden:

  • Wie groß wird die Datenbank? (Eine kleine fürs Web oder ein DataWarehouse?)
  • Wie schreiblastig arbeitet die Datenbank? (Wie ist das Verhältnis zwischen »SELECT« und »INSERT« oder »UPDATE« ?)
  • Muss der Admin die Daten aufwändig analysieren? (Sind komplexe SQL-Queries nötig?)

Idealerweise erhält der Datenbankserver einen eigenen kleinen Storagebereich auf separaten Platten, in dem er die Transaktionslogs der Datenbank speichert. Diesen Transaktionslogs kommt eine zentrale Rolle bei der ACID-Compliance [2] eines RDBMS zu: Die Schreibbestätigung des Subsystems ist Voraussetzung für den gelungenen Abschluss einer Transaktion. Ein schnelles Subsystem (Kasten "Dm-cache"), das ausreichend Platz für das Log – typischerweise zwischen 50 MByte und 4 GByte – bietet, ist deshalb entscheidend für eine performante Datenbank.

Dm-cache

Mit dem Kernel 3.9 hält das neue Device Mapper Target »dm-cache« Einzug. Es erweitert Linux um die Möglichkeit, große Datenspeicher beispielsweise mit Hilfe von SSDs zu beschleunigen, indem es sie als Cache eines anderen Storage-Devices konfiguriert. Was sonst nur teure Lösungen großer Storage-Anbieter boten, ist so erstmals mit Linux-Bordmitteln möglich. Prinzipbedingt verspricht Dm-cache großen Performancegewinn. Wie gut es sich jedoch grundsätzlich und speziell im Datenbankbereich eignet, muss sich in Zukunft noch zeigen.

RAM, CPU, I/O-Scheduler

Genügend Hauptspeicher ist essenziell für eine Datenbank. Gibt es zu wenig, muss sie für manche Operationen auf temporären Festplattenspeicher ausweichen, was das System ausbremst. Viel Hauptspeicher kann als Cache zudem bis zu einem gewissen Grad ein nicht allzu schnelles Storage-Subsystem kompensieren, zumindest lesend. Je mehr gleichzeitige Verbindungen zu der Datenbank bestehen und je mehr komplexe Abfragen an die Datenbank gestellt werden, desto wichtiger wird die CPU-Power. Als Faustformel gilt: Lieber wenige CPU-Kerne mit einer hohen Taktrate als viele Kerne mit niedriger Taktrate, da eine Abfrage immer nur auf einem Core laufen kann.

Die Auswahl des I/O-Schedulers, also die Art, wie der Linux-Kernel Schreiboperationen auf die Festplatte organisiert, spielt ebenfalls eine große Rolle. Wer Schreibzugriffe für ein Datenbanksystem optimieren will, greift am besten zum Deadline-Scheduler. Den gibt der Kernelparameter »elevator=deadline« beim Booten fest für das System vor, zur Laufzeit aktiviert ihn für ein Gerät:

echo deadline > /sys/block/sda/queue/scheduler

Als Dateisysteme kommen derzeit am ehesten XFS oder Ext4 zum Einsatz, Btr-FS eignet sich noch nicht für Datenbanksysteme. Die Parameter »noatime« und »nodiratime« sind sinnvolle Mount-Optionen für Dateisysteme, auf denen PostgreSQL seine Daten und Transaktionslogs ablegt. Verfügt der Server über ein batteriegepuffertes Plattensubsystem, ergeben die Ext4-Optionen »data=writeback« und »nobarrier« zusätzlich Sinn. Sie helfen, das Dateisystem zu beschleunigen, weil es die Plattencaches besser nutzt.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 5 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • PostgreSQL 9.0

    PostgreSQL beabsichtigt mit der neuen Version 9.0 zurück ins Spiel der großen Datenbank-Engines zu finden. Dazu bringt sie asynchrone Replikation und manch weiteres nützliches Feature fürs Unternehmen mit. Der Artikel zeigt anhand einer Suse-Installation, wie Admins Streaming Replication konfigurieren.

  • ICC für Gentoo

    Das Software-Management von Gentoo Linux fußt auf dem Sourcecode der Programme. Damit eignet sich die Distribution im besonderen Maße für Performance-Experimente mit Compileroptionen. Teile von Gentoo lassen sich sogar mit der ICC übersetzen. Ein Praxistest.

  • PostgreSQL 8.3 mit verbesserter Performance

    Das freie Datenbankmanagementsystem PostgreSQL wurde in Version 8.3 freigegeben. Die Entwickler der PostgreSQL Global Development Group konzentrierten sich bei der neuen Version besonders auf das Leistungsverhalten.

  • PostgreSQL

    Hochverfügbarkeit, Replikation und Skalierung sind in der Datenbankwelt alltägliche Notwendigkeiten. Welche Features bietet PostgreSQL in diesem Zusammenhang und was taugen sie?

  • PostgreSQL 9.1 bringt Neuerungen

    Die PostgreSQL Global Development Group gibt die Verfügbarkeit einer neuen Version ihrer Datenbank, PostgreSQL 9.1, bekannt.

comments powered by Disqus

Ausgabe 11/2017

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.