Einrichten einer optimalen Umgebung für PostgreSQL

Willkommen bei PostgreSQL, einem leistungsstarken Open-Source-Datenbanksystem, das alles von einigen Megabytes an Kundendaten für ein Kleinstadtunternehmen bis hin zu Hunderten von Terabytes an „Big Data“ für multinationale Konzerne hosten kann. Unabhängig von der Anwendung ist es wahrscheinlich, dass etwas Setup- und Konfigurationshilfe benötigt wird, um die Datenbank einsatzbereit zu machen.

Wenn ein neuer Server installiert wird, sind die Einstellungen von PostgreSQL sehr gering, da sie darauf ausgelegt sind, auf möglichst wenig Hardware ausgeführt zu werden. Sie sind jedoch sehr selten optimal. Hier werden wir eine grundlegende Einrichtung für neue Projekte durchgehen und PostgreSQL so einrichten, dass es in neuen Projekten optimal läuft.

Hosting

Lokales Hosting

Bei einer On-Premise-Datenbank ist die beste Option ein Bare-Metal-Host, da virtuelle Maschinen im Allgemeinen langsamer arbeiten, es sei denn, es handelt sich um High-End-VMs auf Unternehmensebene. Dies ermöglicht auch eine strengere Kontrolle über CPU-, Arbeitsspeicher- und Festplatten-Setups. Dies geht jedoch mit der Notwendigkeit einher, einen Experten zur Hand zu haben (oder einen Vertrag abzuschließen), um die Serverwartung durchzuführen.

Wolke

Das Hosten einer Datenbank in der Cloud kann in mancher Hinsicht wunderbar oder in anderen ein Alptraum sein. Sofern die gewählte Cloud-Plattform nicht hochgradig optimiert ist (was im Allgemeinen einen höheren Preis bedeutet), kann sie Probleme mit Umgebungen mit höherer Last haben. Achten Sie darauf, ob der Cloud-Server gemeinsam genutzt oder dediziert ist (dediziert, um die volle Leistung des Servers für die Anwendung zu ermöglichen), sowie die IOPS-Stufe (Input/Output Operations Per Second), die von einem Cloud-Server bereitgestellt wird. Wenn (oder falls) die Anwendung so weit anwächst, dass die meisten Daten nicht mehr im Arbeitsspeicher gespeichert werden können, ist die Festplattenzugriffsgeschwindigkeit entscheidend.

Allgemeine Host-Einrichtung

Die wichtigsten Säulen, die zum zuverlässigen Einrichten von PostgreSQL benötigt werden, basieren auf den CPU-, Arbeitsspeicher- und Festplattenfähigkeiten des Hosts. Abhängig von den Anforderungen der Anwendung haben ein ausreichender Host sowie eine gut abgestimmte PostgreSQL-Konfiguration einen erstaunlichen Einfluss auf die Leistung des Datenbanksystems.

Auswahl eines Betriebssystems

PostgreSQL kann auf den meisten Unix-ähnlichen Betriebssystemen sowie auf Windows kompiliert werden. Die Leistung unter Windows ist jedoch nicht einmal mit einem Unix-ähnlichen System vergleichbar. Wenn es sich also nicht um ein kleines Wegwerfprojekt handelt, ist das Festhalten an einem etablierten Unix-ähnlichen System der richtige Weg. Für diese Diskussion bleiben wir bei Linux-basierten Systemen.

Die anscheinend am häufigsten verwendete Linux-Distribution, die zum Hosten von PostgreSQL verwendet wird, ist ein Red Hat-basiertes System wie CentOS oder Scientific Linux oder sogar Red Hat selbst. Da sich Red Hat und CentOS auf Stabilität und Leistung konzentrieren, arbeitet die Community hinter diesen Projekten hart daran, sicherzustellen, dass wichtige Anwendungen, wie z. B. Datenbanken, auf der sichersten und zuverlässigsten Linux-Version ausgeführt werden.

HINWEIS:Linux hat eine Reihe von Kernel-Versionen, die für die Ausführung von PostgreSQL nicht optimal sind, daher wird dringend empfohlen, diese nach Möglichkeit zu vermeiden (insbesondere bei Anwendungen, bei denen Spitzenleistung von größter Bedeutung ist). Benchmarks haben gezeigt, dass die Anzahl der Transaktionen pro Sekunde von Kernel-Version 3.4 – 3.10 abfällt, sich aber in Kernel 3.12 erholt und deutlich verbessert. Dies schließt leider die Verwendung von CentOS 7 aus, wenn Sie die CentOS-Route gehen. CentOS 6 ist immer noch eine gültige und unterstützte Version des Betriebssystems, und CentOS 8 wird voraussichtlich veröffentlicht, bevor 6 nicht mehr unterstützt wird.

Installation

Die Installation kann entweder über die Quelle oder über Repositories erfolgen, die entweder von der gewählten Linux-Distribution oder noch besser von der PostgreSQL Global Development Group (PGDG) verwaltet werden, die Repositories für Red Hat-basierte Systeme (Red Hat, Scientific Linux, CentOS, Amazon Linux AMI, Oracle Enterprise Linux und Fedora) sowie Pakete für Debian und Ubuntu. Die Verwendung der PGDG-Pakete stellt sicher, dass Updates für PostgreSQL bei der Veröffentlichung verfügbar sind, anstatt darauf zu warten, dass die integrierten Repositories der Linux-Distribution sie genehmigen und bereitstellen.

Prozessor

Heutzutage ist es nicht schwer, mehrere Kerne für einen Datenbankhost zur Verfügung zu haben. PostgreSQL selbst hat erst kürzlich damit begonnen, Multithreading-Fähigkeiten auf Abfrageebene hinzuzufügen, und wird in den kommenden Jahren noch viel besser werden. Aber auch ohne diese neuen und bevorstehenden Verbesserungen erzeugt PostgreSQL selbst neue Threads für jede Verbindung eines Clients mit der Datenbank. Diese Threads verwenden im Wesentlichen einen Kern, wenn sie aktiv sind, sodass die Anzahl der erforderlichen Kerne von der Ebene der erforderlichen gleichzeitigen Verbindungen und gleichzeitigen Abfragen abhängt.

Eine gute Basis für den Anfang ist ein 4-Kern-System für eine kleine Anwendung. Unter der Annahme, dass Anwendungen zwischen der Ausführung von Abfragen und dem Ruhezustand tanzen, kann ein 4-Kern-System ein paar Dutzend Verbindungen bewältigen, bevor es überlastet wird. Das Hinzufügen weiterer Kerne hilft bei der Skalierung mit zunehmender Arbeitslast. Es ist nicht ungewöhnlich, dass sehr große PostgreSQL-Datenbanken über 48 Kerne haben, um viele hundert Verbindungen zu bedienen.

Tuning-Tipps: Selbst wenn Hyper-Threading verfügbar ist, sind die Transaktionen pro Sekunde im Allgemeinen höher, wenn Hyper-Threading deaktiviert ist. Für Datenbankabfragen, die nicht zu komplex, aber häufiger sind, sind mehr Kerne wichtiger als schnellere Kerne.

Erinnerung

Der Arbeitsspeicher ist ein äußerst wichtiger Aspekt für die Gesamtleistung von PostgreSQL. Die Haupteinstellung für PostgreSQL in Bezug auf Speicher ist shared_buffers, ein Teil des Speichers, der direkt dem PostgreSQL-Server für das Daten-Caching zugewiesen wird. Je höher die Wahrscheinlichkeit ist, dass die benötigten Daten im Arbeitsspeicher vorhanden sind, desto schneller werden Abfragen zurückgegeben, und schnellere Abfragen bedeuten eine effizientere CPU-Kernkonfiguration, wie im vorherigen Abschnitt erläutert.

Abfragen benötigen manchmal auch Speicher, um Sortiervorgänge an Daten durchzuführen, bevor sie an den Client zurückgegeben werden. Dies verwendet entweder zusätzlichen Ad-hoc-Speicher (separat von shared_buffers) oder temporäre Dateien auf der Festplatte, was viel langsamer ist.

Tuning-Tipps: Ein grundlegender Ausgangspunkt für die Einstellung von shared_buffers ist die Einstellung auf 1/4 des Werts des verfügbaren System-RAM. Dadurch kann das Betriebssystem auch seine eigenen Daten zwischenspeichern sowie andere laufende Prozesse als die Datenbank selbst.

Eine Erhöhung von work_mem kann Sortiervorgänge beschleunigen, eine zu starke Erhöhung kann jedoch dazu führen, dass dem Host der gesamte Arbeitsspeicher ausgeht, da der Wertesatz teilweise oder vollständig mehrmals pro Abfrage ausgegeben werden kann. Wenn mehrere Abfragen mehrere Speicherblöcke zum Sortieren anfordern, kann dies schnell zu mehr Speicher führen, als auf dem Host verfügbar ist. Halten Sie ihn niedrig und erhöhen Sie ihn langsam, bis die gewünschte Leistung erreicht ist.

Verwenden Sie den Befehl „free“ (z. B. „free -h“) und legen Sie Effective_cache_size auf die Summe des freien und zwischengespeicherten Speichers fest. Dadurch weiß der Abfrageplaner, welche Ebene des OS-Cachings möglicherweise verfügbar ist, und kann bessere Abfragepläne ausführen.

Festplatte

Die Festplattenleistung kann eines der wichtigsten Dinge sein, die beim Einrichten eines Systems zu berücksichtigen sind. Eingabe-/Ausgabegeschwindigkeiten sind wichtig für große Datenlasten oder das Abrufen großer zu verarbeitender Datenmengen. Es bestimmt auch, wie schnell PostgreSQL den Speicher mit der Festplatte synchronisieren kann, um den Speicherpool optimal zu halten.

Einige Vorbereitungen auf Datenträgern können dazu beitragen, die potenzielle Leistung sofort zu verbessern und das Datenbanksystem zukunftssicher für Wachstum zu machen.

• Separate Datenträger

  Eine Neuinstallation von PostgreSQL erstellt das Datenverzeichnis des Clusters irgendwo auf dem (und möglicherweise einzigen) verfügbaren Hauptlaufwerk des Systems.

  Ein grundlegendes Setup mit mehr Laufwerken wäre das Hinzufügen eines separaten Laufwerks (oder einer Gruppe von Laufwerken über RAID). Es hat den Vorteil, dass die gesamte datenbankbezogene Datenübertragung auf einem anderen E/A-Kanal als das Hauptbetriebssystem abläuft. Außerdem kann die Datenbank wachsen, ohne befürchten zu müssen, dass zu wenig Speicherplatz Probleme und Fehler an anderer Stelle im Betriebssystem verursacht.

  Für Datenbanken mit extrem viel Aktivität kann das Verzeichnis PostgreSQL Transaction Log (xlog) auf einem weiteren Laufwerk platziert werden, wodurch umfangreichere E/A-Vorgänge auf einen anderen Kanal vom Hauptbetriebssystem sowie vom Hauptdatenverzeichnis getrennt werden. Dies ist eine fortschrittliche Maßnahme, die dazu beiträgt, mehr Leistung aus einem System herauszuholen, das andernfalls an seine Grenzen stoßen könnte.

• RAID verwenden

  Das Einrichten von RAID für die Datenbanklaufwerke schützt nicht nur vor Datenverlust, sondern kann auch die Leistung verbessern, wenn die richtige RAID-Konfiguration verwendet wird. RAID 1 oder 10 gelten allgemein als die besten, und 10 bietet Parität und Gesamtgeschwindigkeit. RAID 5 weist jedoch ein höheres Maß an Redundanz auf, leidet jedoch unter einem erheblichen Leistungsabfall aufgrund der Art und Weise, wie Daten auf mehrere Festplatten verteilt werden. Planen Sie die beste verfügbare Option mit viel Platz für Datenwachstum, und dies wird eine Konfiguration sein, die nicht oft geändert werden muss, wenn überhaupt.

• SSD verwenden

  Solid State Drives sind wunderbar für die Leistung, und wenn sie das Budget einhalten, können Enterprise-SSDs schwere Datenverarbeitungslasten Tag und Nacht schneller machen. Kleinere bis mittlere Datenbanken mit kleineren bis mittleren Workloads sind vielleicht übertrieben, aber wenn es um die kleinste prozentuale Steigerung bei großen Anwendungen geht, kann SSD die Wunderwaffe sein.

Tuning-Tipps: Wählen Sie eine Laufwerkskonfiguration, die für die jeweilige Anwendung am besten geeignet ist und über viel Platz verfügt, um mit der Zeit zu wachsen, wenn die Datenmenge zunimmt.

Wenn Sie eine SSD verwenden, ist das Festlegen von random_page_cost auf 1,5 oder 2 (der Standardwert ist 4) für den Abfrageplaner von Vorteil, da das zufällige Abrufen von Daten viel schneller ist als auf sich drehenden Festplatten.

Erste Konfigurationseinstellungen

Wenn Sie PostgreSQL zum ersten Mal einrichten, gibt es eine Handvoll Konfigurationseinstellungen, die je nach Leistung des Hosts leicht geändert werden können. Da die Anwendung die Datenbank im Laufe der Zeit abfragt, kann basierend auf den Anforderungen der Anwendung eine spezifische Optimierung vorgenommen werden. Das wird aber das Thema für einen eigenen Tuning-Blog sein.

Speichereinstellungen

shared_buffers:Auf 1/4 des Systemspeichers gesetzt. Wenn das System über weniger als 1 GB Gesamtspeicher verfügt, stellen Sie ihn auf ~ 1/8 des gesamten Systemspeichers

work_mem:Der Standardwert ist 4 MB und kann für die betreffende Anwendung sogar ausreichend sein. Wenn jedoch häufig temporäre Dateien erstellt werden und diese Dateien ziemlich klein sind (zig Megabyte), kann es sich lohnen, diese Einstellung zu erhöhen. Eine konservative Einstiegseinstellung kann (1/4 Systemspeicher / max_connections) sein. Diese Einstellung hängt stark vom tatsächlichen Verhalten und der Häufigkeit der Abfragen der Datenbank ab und sollte daher nur mit Vorsicht erhöht werden. Seien Sie bereit, es wieder auf das vorherige Niveau zu reduzieren, wenn Probleme auftreten.

Effective_Cache_Size:Wird auf die Summe des freien und zwischengespeicherten Speichers gesetzt, der vom Befehl „free“ gemeldet wird.

Checkpoint-Einstellungen

Für PostgreSQL 9.4 und niedriger:
checkpoint_segments:Eine Reihe von Checkpoint-Segmenten (jeweils 16 Megabyte), um das Write-Ahead-Log-System bereitzustellen. Der Standardwert ist 3 und kann selbst für kleine Datenbanken problemlos auf 64 erhöht werden.

Für PostgreSQL 9.5 und höher:
max_wal_size:Dies ersetzt checkpoint_segments als Einstellung. Der Standardwert ist 1 GB und kann hier bleiben, bis weitere Änderungen erforderlich sind.

Sicherheit

listen_address:Diese Einstellung legt fest, auf welchen persönlichen IP-Adressen / Netzwerkkarten Verbindungen überwacht werden sollen. In einem einfachen Setup wird es wahrscheinlich nur eine geben, während fortgeschrittenere Netzwerke möglicherweise mehrere Karten haben, um sich mit mehreren Netzwerken zu verbinden. * Bedeutet alles hören. Wenn die Anwendung, die auf die Datenbank zugreift, jedoch auf demselben Host wie die Datenbank selbst laufen soll, reicht es aus, sie als „localhost“ zu belassen.

Protokollierung

Einige grundlegende Protokollierungseinstellungen, die die Protokolle nicht überlasten, sind wie folgt.

log_checkpoints = on
log_connections = on
log_disconnections = on
log_temp_files = 0