Insinyur AWS melaporkan performa PostgreSQL turun setengah di Linux 7.0 – perbaikannya mungkin tidak mudah

• Pada kernel pengembangan Linux 7.0, ditemukan regresi performa serius pada server database PostgreSQL, di mana throughput turun hingga sekitar setengah dibanding kernel sebelumnya, dan hal ini ditemukan oleh insinyur Amazon/AWS
• Hasil pengukuran di server Graviton4 menunjukkan bahwa Linux 7.0 hanya memberikan sekitar 0,51x throughput dibanding kernel sebelumnya, dan penyebabnya diketahui karena jauh lebih banyak waktu dihabiskan pada spinlock user-space
• Penyebab regresi ini adalah perubahan pembatasan mode preemption kernel yang diterapkan di Linux 7.0; patch untuk mengembalikan PREEMPT_NONE sebagai nilai default telah diajukan, tetapi kemungkinan diterimanya masih tidak jelas
• Penulis asli perubahan tersebut, Peter Zijlstra, menyatakan bahwa alih-alih memperbaiki kernel, PostgreSQL seharusnya dimodifikasi agar memanfaatkan ekstensi time slice RSEQ (Restartable Sequences)
• Versi stabil Linux 7.0 dijadwalkan rilis sekitar 2 minggu lagi dan juga akan digunakan sebagai kernel dasar Ubuntu 26.04 LTS, sehingga dikhawatirkan akan terjadi penurunan performa yang luas sampai PostgreSQL beradaptasi

---

Penemuan masalah dan skalanya

• Insinyur Amazon/AWS, Salvatore Dipietro, melaporkan regresi pada throughput dan latensi PostgreSQL
• Berdasarkan pengukuran pada server Graviton4, Linux 7.0 hanya memberikan 0,51x throughput dibanding kernel yang ada sebelumnya
  • Penyebabnya dipastikan karena jauh lebih banyak waktu dihabiskan pada spinlock user-space

Penyebab regresi: pembatasan mode preemption

• Hasil bisecting menunjukkan bahwa penyebabnya adalah perubahan yang membatasi mode preemption kernel di Linux 7.0
• Perubahan tersebut dilakukan dengan arah hanya mempertahankan mode preemption Full dan Lazy untuk arsitektur CPU modern, dan dimasukkan sebagai bagian dari pembaruan scheduler Linux 7.0

Patch yang diajukan dan respons maintainer kernel

• Dengan alasan regresi yang serius, patch untuk mengembalikan PREEMPT_NONE sebagai mode preemption default telah diajukan ke mailing list kernel Linux
• Namun, Peter Zijlstra yang menulis kode aslinya bersikap negatif terhadap penerimaan patch tersebut, dan menyatakan bahwa solusinya adalah PostgreSQL memanfaatkan ekstensi time slice RSEQ (Restartable Sequences)
  • Ekstensi time slice RSEQ juga merupakan fitur yang disertakan di Linux 7.0
  • Zijlstra menjelaskan bahwa "hal ini dapat membatasi paparan preemption pada pemegang lock"

Cakupan dampak dan jadwal rilis

• Jika posisi ini tetap dipertahankan, maka performa PostgreSQL dalam beberapa skenario di versi stabil Linux 7.0 dapat menurun tajam sampai PostgreSQL diperbarui
• Versi stabil Linux 7.0 dijadwalkan rilis sekitar 2 minggu lagi
• Linux 7.0 akan menjadi kernel dasar Ubuntu 26.04 LTS, sehingga Ubuntu 26.04 LTS yang dijadwalkan rilis pada akhir April juga berpotensi terkena dampak yang sama

[unstabler]

Katanya, para pengembang kernel sudah hampir 10–20 tahun mengatakan kepada para pengembang PostgreSQL, “spinlock di userland tidak direkomendasikan, jadi kami berharap kalian bisa mempertimbangkannya kembali.”..

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

[GN⁺]

Komentar Hacker News

• Layak membaca tulisan lanjutan di LKML dari pengembang Postgres, Andres Freund

  • Jika masalah performa ini adalah regresi yang dapat direproduksi (regression), maka aneh jika solusinya di 7.0 justru mengharuskan mematikan fitur yang baru ditambahkan di 7.0
  • Bukan hanya satu tulisan, mengikuti seluruh thread akan memberi informasi tambahan yang cukup banyak
  • Tidak baik memaksakan fitur tingkat rendah yang baru diperkenalkan di 7.0 demi menyelesaikan regresi yang hanya muncul di 7.0
    Ada pendapat bahwa para maintainer Linux seharusnya memprioritaskan dukungan untuk aplikasi inti seperti PostgreSQL
    Ini mengingatkan pada kasus lama saat Fedora memblokir pembaruan ketika Wine terpasang
  • Solusi “gunakan hugepages” selalu diajukan, tetapi kebanyakan pengguna mengabaikannya
  • Hanya pada mesin ARM64 96-core performa turun menjadi 0,51x, dan tidak dapat direproduksi di AMD64
    Jadi ini bukan masalah yang dialami semua pengguna PostgreSQL yang berpindah ke kernel terbaru

• Ada pendapat bahwa memakai spinlock di user space tanpa dukungan kernel sama saja mengundang penurunan performa

  • Saya juga tidak suka penggunaan spinlock di Postgres dan sedang menguranginya sedikit demi sedikit
    Namun lock berbasis futex menimbulkan regresi performa karena peningkatan memory barrier
    Selain itu, Postgres masih harus mempertimbangkan platform yang belum mendukung operasi atomik 8-byte, sehingga sulit menggantinya
    Spinlock yang dipermasalahkan baru-baru ini sudah dihapus, dan saat menggunakan huge pages bottleneck-nya hampir hilang
  • Ada analogi bahwa memakai spinlock di user space itu seperti “memukul wajah sendiri dengan palu”
  • Ada juga pendapat bahwa PostgreSQL selama ini memakai spinlock demi menjaga kompatibilitas dengan kernel lama, tetapi sekarang sudah saatnya berhenti

• Ada juga klaim bahwa “tidak ada orang yang memakai kernel terbaru di production”
  Kenyataannya, Ubuntu 26.04 LTS akan segera dirilis berbasis Linux 7.0, jadi banyak pengguna akan segera memakainya
  Masalahnya saat ini membutuhkan patch kernel, bukan sysctl

  • Meski begitu, tetap harus ada orang yang menguji kernel terbaru agar masalah seperti ini bisa ditemukan lebih awal
  • Jika PostgreSQL terdampak, ada kemungkinan aplikasi lain juga terdampak
  • Ada juga catatan bahwa di lingkungan Docker, kernel host dipakai bersama sehingga tidak ada pilihan
  • Sebagai catatan, opsi PREEMPT_NONE telah dihapus di sebagian besar platform

• Latar belakang PREEMPT_LAZY bisa dilihat di artikel LWN

• Ada komentar bercanda yang bertanya, “sudah cek apakah Jia Tan baru-baru ini mengirim patch kernel?”
  Lalu ada balasan, “bahkan tidak perlu sejauh itu, kerentanannya sudah melimpah”

• Ada pendapat yang penasaran apakah I/O asinkron dan optimasi query paralel di PostgreSQL 18 bisa menutup penurunan performa kali ini
  Detail terkait bisa dilihat di catatan rilis PostgreSQL 18

• Ada juga yang mempertanyakan mengapa mode preemption dinamis seperti PREEMPT_LAZY diperlukan
  Menurut mereka, manfaatnya bagi pengguna biasa tidak jelas

  • Sebagai balasan, ada penjelasan bahwa ini adalah desain untuk meningkatkan throughput tanpa menambah latensi
    Kernel jadi bisa menerima informasi yang lebih eksplisit untuk memperbaiki keputusan scheduling

• Ada komentar yang mengatakan bahwa ia mengukur penurunan performa 10% antara FreeBSD 14 dan 15.0, dan kasus ini membuatnya sedikit terhibur

  • Lalu ada tanggapan, “setidaknya apakah ada penambahan fitur sebanyak itu?”

• Ada juga kritik bahwa Phoronix membuat artikel tanpa verifikasi yang memadai
  Dalam email lanjutan, disimpulkan bahwa benchmark-nya sendiri keliru dan sebenarnya bukan masalah besar

  • Namun regresi memang hanya terjadi saat tidak menggunakan huge pages
    Mungkin ini bukan masalah besar untuk PostgreSQL, tetapi bisa berdampak pada aplikasi lain yang tidak bisa memakai huge pages
    Karena itu, menurut mereka ini bukan sesuatu yang bisa begitu saja diabaikan

• Tautan thread LKML lama juga dibagikan