Warten auf Postgres 18: Schnellere Festplattenlesevorgänge mit asynchronem I/O

• Postgres 18, derzeit in Beta 1, führt Unterstützung für asynchrones I/O (Asynchronous I/O) ein und verbessert damit insbesondere die Leseleistung in Cloud-Umgebungen deutlich
• Über den neuen Parameter io_method kann man neben der klassischen sync-Methode auch worker- und io_uring-Modi auswählen
• Benchmarks auf AWS zeigen: Mit io_uring lässt sich die Leistung beim Lesen von Datenträgern um bis zu das 3-Fache steigern
• Durch die Asynchronität wird allerdings die Interpretation der I/O-Timings in der bisherigen Query-Analyse (EXPLAIN ANALYZE) schwieriger
• Für die Leistungsoptimierung sind die neue Monitoring-View pg_aios sowie Tuning-Parameter wie effective_io_concurrency wichtig

---

Einführung von asynchronem I/O in Postgres 18

• Traditionell verwendet Postgres ein blockierendes I/O-Modell, bei dem auf den Abschluss jedes Festplatten-Lesevorgangs gewartet wird
• Durch die hohe Latenz netzwerkbasierter Storage-Systeme (wie EBS) entstehen in Cloud-Umgebungen Engpässe
• Asynchrones I/O ermöglicht es, mehrere Lesevorgänge parallel zu verarbeiten, was die CPU-Auslastung und den Gesamtdurchsatz erhöht

Vorarbeit in Postgres 17: Read Stream API

• In Postgres 17 wurde die read_stream-API eingeführt, um die Abstraktion von Leseoperationen zu standardisieren
• Sie stützt sich jedoch weiterhin auf den OS-Seitencache und spiegelt sich nicht direkt im Shared Buffer von Postgres wider
• In Postgres 18 sind nun direkte asynchrone Lesevorgänge statt bloßer Kernel-Hinweise möglich

Neue Einstellung: io_method

• Postgres 18 ergänzt in postgresql.conf die Einstellung io_method und bietet dabei drei Optionen:

io_method = sync

• Die bisherige synchrone Methode wie in älteren Postgres-Versionen
• Verwendet ein Verfahren für vorgezogene Leseanforderungen auf Basis von posix_fadvise()

io_method = worker (Standard)

• Dedizierte I/O-Worker-Prozesse lesen Daten asynchron ein und übergeben sie an den Shared Buffer
• Der Hauptprozess kann ohne Unterbrechung durch Lesevorgänge weiterlaufen
• Standardmäßig sind 3 Worker aktiv; anpassbar über io_workers

io_method = io_uring

• Hochleistungs-I/O-Schnittstelle, verfügbar ab Linux-Kernel 5.1
• Führt asynchrone Lesevorgänge direkt über einen mit dem Kernel geteilten Ringpuffer aus, ohne Worker-Prozesse
• Erfordert einen aktuellen Kernel, ein passendes Dateisystem und entsprechende Konfiguration

Performance-Benchmarks für asynchrones I/O (AWS-Basis)

• Testumgebung:
  • AWS c7i.8xlarge (32 vCPU, 64GB RAM)
  • 100GB io2 EBS, 20.000 IOPS
  • Ausführung von SELECT COUNT(*) auf einer Tabelle mit 3,5GB Größe

Vergleich der Cold-Cache-Leistung:

Version/Einstellung	Ausführungszeit (ms)
Postgres 17 (sync)	15.831
Postgres 18 (sync)	15.071
Postgres 18 (worker)	10.052
Postgres 18 (io_uring)	5.723

• io_uring bringt gegenüber sync eine 2,8-fache Leistungssteigerung
• Besonders wirksam, um Festplattenlatenzen in der Cloud zu reduzieren

Tuning von effective_io_concurrency

• In Postgres 18 beeinflusst dieser Parameter die Anzahl interner asynchroner Read-Ahead-Anfragen
• Der Standardwert wurde von 1 auf 16 angehoben; zusammen mit io_combine_limit bestimmt er den maximalen Lesebereich
• In Cloud-Umgebungen mit hoher Latenz können größere Werte vorteilhaft sein, Benchmarks pro Workload bleiben aber notwendig

Neues Monitoring-Werkzeug: pg_aios

• In pg_stat_activity erscheinen asynchrone Vorgänge als Event AioIoCompletion, was die Analyse von Wartezuständen im Backend erschwert
• Bei io_uring gilt zudem: Da der Kernel die Verarbeitung direkt übernimmt, ist der I/O-Status in Postgres nicht sichtbar
• Über die View pg_aios lassen sich detaillierte Informationen zu aktuell laufenden asynchronen Anfragen einsehen

  SELECT * FROM pg_aios;  
  

• Statuswerte wie SUBMITTED, COMPLETED_IO sowie Informationen zu den Zielblöcken sind dort einsehbar

Achtung: Veränderte Interpretation von I/O-Timing-Informationen

• Die in EXPLAIN ANALYZE angezeigten I/O Timings sind nur bei synchroner Ausführung zuverlässig
• Bei asynchronen Modi wie worker und io_uring wird die Interpretation der Timing-Daten durch Parallelisierung und Verteilung auf Worker verzerrt
• Um den tatsächlichen I/O-Aufwand zu bewerten, empfiehlt sich die Nutzung der Anzahl von shared read-Buffern und pg_aios

Fazit

• Postgres 18 leistet einen spürbaren Beitrag zur Performance bei leseintensiven Workloads
• Besonders bei Festplatten mit hoher Latenz in Cloud-Umgebungen sind deutliche Vorteile zu erwarten
• Gleichzeitig ist ein Umdenken bei der Interpretation von Metriken, beim Performance-Tuning und bei der Anwendung der Konfiguration erforderlich
• Für Postgres 19 wird zudem Unterstützung für asynchrone Schreibvorgänge erwartet

[jujumilk3]

Postgres ist wirklich einfach das Allerbeste.

[GN⁺]

Hacker-News-Kommentare

• Unter Linux kann man mit preadv2(..., RWF_NOWAIT) asynchrone Lesevorgänge aus dem Page Cache durchführen. Das könnte nützlich sein, um die Latenz bei io_method = worker zu verringern.
  • Vorgeschlagen wird, im Main-Thread zunächst mit NOWAIT zu lesen und nur bei einem Fehlschlag an einen Worker-Thread auszulagern.
• Es wird gefragt, ob diese neue Async-I/O-Funktion nur für Linux verfügbar ist.
  • Windows hat IOCP und eine eigene IORing-Implementierung, und macOS unterstützt POSIX AIO.
  • Es wird darauf hingewiesen, dass über die IORing-Implementierung von Windows nicht viel gesprochen wird.
• In FreeBSD wurde viel Arbeit in aio(4) gesteckt, und da es die Nachteile von Linux/glibc aio nicht hat, dürfte seine Funktionsweise interessant sein.
• Es gibt eine Frage nach Ähnlichkeiten zu InnoDB von MySQL.
• Es bestehen Bedenken wegen der Sicherheitsprobleme von io_uring, und es wird gefragt, ob viele Linux-Administratoren oder Distributionen es deshalb deaktivieren.
• Es gibt die Meinung, dass man diese Funktion gern in der Produktion auf NVMe einsetzen würde, und die Hoffnung, dass große Cloud-Anbieter sie so schnell wie möglich bereitstellen.
  • Der Performance-Gewinn ist sehr attraktiv.
• Es wird von Erfahrungen mit dem Deployment von Postgres auf einem Hetzner-EX-44-Server berichtet.
  • Das Preis-Leistungs-Verhältnis ist hervorragend und bietet Kapazität auf Enterprise-Niveau zu geringen Kosten.
  • Mit TailScale wird die Sicherheit erhöht und die Exponierung ins öffentliche Netzwerk vollständig entfernt.
  • Zum Optimierungsansatz gehören workload-spezifische Konfiguration mit PGTune, Echtzeit-Performance-Monitoring mit PgHero und automatisierte VACUUM ANALYZE-Jobs mit pgcron.
  • Es wurde ein eigenes CLI-Utility für Backups mit ZSTD-Komprimierung entwickelt, das hohe Kompressionsraten und hohen Durchsatz beibehält und automatische S3-Uploads unterstützt.
  • Dieses Setup ist stabil, leistungsfähig und bietet reichlich Spielraum für Wachstum.
• Es gibt einen scherzhaften Kommentar zu den 20k IOPS von AWS-Instanzen.
  • Consumer-NVMe liefert etwa über 1 Million IOPS, und mit PCIe-5.0-NVMe dürfte das noch weiter steigen.
  • Es wird angenommen, dass die willkürlichen Limits in der Cloud viele Probleme verursachen.
  • Async I/O ist sehr nützlich, dürfte bei NVMe mit 1 Million IOPS aber weniger wichtig sein.
  • Cloud-Kosten sind sehr hoch, und der Performance-Unterschied zu günstiger Consumer-Hardware ist groß.
• Es gibt eine Frage zum Performance-Vergleich zwischen Postgres, MariaDB und Percona.
  • Gefragt wird, in welchen Fällen jede dieser Datenbanken besonders stark ist.
• Es wird gefragt, wann ein Update erscheint, das mehr gleichzeitige Verbindungen erlaubt.
  • Es wird gehofft, pgbouncer dann nicht mehr verwenden zu müssen.