AWS-Ingenieur berichtet, dass sich die PostgreSQL-Leistung unter Linux 7.0 halbiert – eine Behebung könnte nicht einfach sein

• Im Entwicklungskernel von Linux 7.0 wurde von einem Amazon-/AWS-Ingenieur eine schwere Leistungsregression entdeckt, bei der der Durchsatz des PostgreSQL-Datenbankservers im Vergleich zu früheren Kerneln auf etwa die Hälfte fällt
• Messungen auf Graviton4-Servern zeigen, dass Linux 7.0 im Vergleich zu früheren Kerneln nur etwa den 0,51-fachen Durchsatz liefert; als Ursache wurde festgestellt, dass deutlich mehr Zeit in User-Space-Spinlocks verbraucht wird
• Als Ursache der Regression wurde eine Änderung identifiziert, die in Linux 7.0 die Einschränkung des Kernel-Preemption-Modus betrifft; ein Patch zur Wiederherstellung von PREEMPT_NONE als Standardwert wurde eingereicht, doch die Aussicht auf Annahme ist unklar
• Der ursprüngliche Autor Peter Zijlstra erklärte, statt einer Kernel-Korrektur müsse PostgreSQL so angepasst werden, dass es die RSEQ-(Restartable-Sequences)-Time-Slice-Erweiterung nutzt
• Die stabile Version von Linux 7.0 soll in etwa zwei Wochen erscheinen und wird auch als Basiskernel für Ubuntu 26.04 LTS dienen; deshalb wird eine breit angelegte Leistungsverschlechterung befürchtet, bis PostgreSQL angepasst ist

---

Entdeckung des Problems und Ausmaß

• Der Amazon-/AWS-Ingenieur Salvatore Dipietro meldete Regressionen bei Durchsatz und Latenz von PostgreSQL
• Auf Basis von Messungen auf Graviton4-Servern liefert Linux 7.0 im Vergleich zu bestehenden Kerneln nur den 0,51-fachen Durchsatz
  • Als Ursache wurde bestätigt, dass wesentlich mehr Zeit in User-Space-Spinlocks verbraucht wird

Ursache der Regression: Einschränkung des Preemption-Modus

• Das Bisecting ergab, dass die Ursache eine Änderung ist, die in Linux 7.0 den Kernel-Preemption-Modus einschränkt
• Die Änderung wurde mit dem Ziel vorgenommen, für moderne CPU-Architekturen nur noch Full- und Lazy-Preemption-Modi beizubehalten, und war Teil der Scheduler-Updates für Linux 7.0

Eingereichter Patch und Reaktion des Kernel-Maintainers

• Wegen der schweren Regression wurde ein Patch auf der Linux-Kernel-Mailingliste eingereicht, der PREEMPT_NONE als Standard-Preemption-Modus wiederherstellt
• Der Autor des ursprünglichen Codes, Peter Zijlstra, steht einer Annahme dieses Patches jedoch ablehnend gegenüber und erklärte, die Lösung bestehe darin, dass PostgreSQL die RSEQ-(Restartable-Sequences)-Time-Slice-Erweiterung nutzt
  • Die RSEQ-Time-Slice-Erweiterung ist ebenfalls eine in Linux 7.0 enthaltene Funktion
  • Zijlstra erklärte, „damit lässt sich die Preemption-Exposition des Lock-Holders begrenzen“

Auswirkungen und Zeitplan für die Veröffentlichung

• Falls diese Haltung bestehen bleibt, könnte die PostgreSQL-Leistung in einigen Szenarien unter der stabilen Version von Linux 7.0 erheblich sinken, bis PostgreSQL aktualisiert wird
• Die stabile Version von Linux 7.0 soll in etwa zwei Wochen erscheinen
• Linux 7.0 ist der Basiskernel von Ubuntu 26.04 LTS, sodass dieselben Auswirkungen auch Ubuntu 26.04 LTS betreffen könnten, dessen Veröffentlichung für Ende April geplant ist

[unstabler]

Soweit ich gehört habe, haben Kernel-Entwickler den PostgreSQL-Entwicklern wohl schon seit fast 10 bis 20 Jahren gesagt: „Spinlocks im Userland sind nicht empfehlenswert, vielleicht solltet ihr das noch einmal überdenken.“

https://x.com/kosaki55tea/status/2040458791536497035

[GN⁺]

Hacker-News-Kommentare

• Es lohnt sich, den LKML-Nachfolgebeitrag von Postgres-Entwickler Andres Freund zu lesen

  • Wenn das Performance-Problem eine reproduzierbare Regression ist, wäre es eine seltsame Situation, wenn sich das nur beheben ließe, indem man in 7.0 neu hinzugefügte Funktionen deaktiviert
  • Nicht nur der einzelne Beitrag, sondern der gesamte Thread enthält zusätzliche Informationen
  • Es ist keine gute Idee, zur Behebung einer nur in 7.0 auftretenden Regression neue Low-Level-Features zu erzwingen, die erst in 7.0 eingeführt wurden
    Es wurde die Ansicht geäußert, dass Linux-Maintainer zentrale Anwendungen wie PostgreSQL vorrangig unterstützen sollten
    Das erinnerte an einen früheren Fall, in dem Fedora Updates blockierte, wenn Wine installiert war
  • Die Lösung „verwendet hugepages“ wird zwar immer wieder genannt, aber die meisten Nutzer ignorieren das
  • Nur auf einer ARM64-Maschine mit 96 Kernen kam es zu einer Leistungsreduktion auf das 0,51-Fache; auf AMD64 ließ sich das nicht reproduzieren
    Das heißt, es ist kein Problem, das alle Nutzer von PostgreSQL beim Umstieg auf den neuesten Kernel erleben

• Es wurde auch die Meinung geäußert, dass spinlocks im Userspace ohne Kernel-Unterstützung geradezu nach Performance-Verlusten verlangen

  • Ich selbst mag die Verwendung von Spinlocks in Postgres auch nicht und entferne sie nach und nach
    Locks auf Futex-Basis verursachen jedoch durch mehr Memory Barriers Performance-Regressions
    Außerdem muss Postgres weiterhin Plattformen berücksichtigen, die noch keine 8-Byte-Atomics unterstützen, was einen Ersatz schwierig macht
    Der betreffende Spinlock wurde kürzlich entfernt, und bei Verwendung von Huge Pages verschwindet der Engpass fast vollständig
  • Ein Vergleich lautete, Spinlocks im Userspace zu verwenden sei, als würde man „sich selbst mit einem Hammer ins Gesicht schlagen“
  • Es gab auch die Meinung, dass PostgreSQL Spinlocks wegen der Kompatibilität mit alten Kerneln verwendet hat, es dafür aber nun Zeit sei aufzuhören

• Es gab auch die Behauptung: „Niemand setzt den neuesten Kernel in Produktion ein“
  Tatsächlich wird Ubuntu 26.04 LTS aber bald auf Basis von Linux 7.0 erscheinen, sodass viele Nutzer ihn bald verwenden werden
  Das Problem ist derzeit, dass kein sysctl, sondern ein Kernel-Patch nötig ist

  • Trotzdem muss es Leute geben, die neue Kernel testen, damit solche Probleme früh erkannt werden können
  • Wenn PostgreSQL betroffen ist, könnten auch andere Anwendungen betroffen sein
  • Es wurde auch darauf hingewiesen, dass man in Docker-Umgebungen keine Wahl hat, weil dort der Host-Kernel geteilt wird
  • Zur Einordnung: Die Option PREEMPT_NONE wurde auf den meisten Plattformen entfernt

• Hintergrund zu PREEMPT_LAZY findet sich in diesem LWN-Artikel

• Es gab einen scherzhaften Kommentar: „Habt ihr nachgesehen, ob Jia Tan kürzlich einen Kernel-Patch eingereicht hat?“
  Darauf folgte die Antwort: „Dafür besteht gar keine Notwendigkeit, es gibt ohnehin schon mehr als genug Schwachstellen“

• Jemand fragte sich, ob die asynchrone I/O und Parallel-Query-Optimierungen in PostgreSQL 18 diesen Performance-Verlust ausgleichen könnten
  Mehr dazu steht in den Release Notes zu PostgreSQL 18

• Es wurde auch bezweifelt, warum dynamische Preemption-Modi wie PREEMPT_LAZY überhaupt nötig sind
  Der Nutzen für normale Nutzer sei unklar

  • In einer Antwort wurde erklärt, das Design solle den Durchsatz erhöhen, ohne die Latenz zu verschlechtern
    Dadurch könne der Kernel explizitere Informationen erhalten und Scheduling-Entscheidungen verbessern

• Jemand schrieb, zwischen FreeBSD 14 und 15.0 eine Leistungseinbuße von 10 % gemessen zu haben, und fühle sich durch diesen Fall getröstet

  • Darauf kam die Reaktion: „Gab es dafür wenigstens entsprechend viele neue Funktionen?“

• Es gab auch Kritik daran, dass Phoronix den Fall ohne ausreichende Verifizierung aufgegriffen habe
  In einer Follow-up-Mail wurde geschlussfolgert, dass bereits der Benchmark fehlerhaft gewesen sei und es in Wirklichkeit kein großes Problem gebe

  • Die Regression tritt allerdings nur dann auf, wenn Huge Pages nicht verwendet werden
    Für PostgreSQL dürfte das kein großes Problem sein, andere Anwendungen, die keine Huge Pages nutzen können, könnten aber betroffen sein
    Deshalb sei es nicht etwas, das man einfach ignorieren sollte

• Zusätzlich wurde ein älterer LKML-Thread geteilt