Menanti Postgres 18: Kecepatan Baca Disk Meningkat dengan I/O Asinkron

• Postgres 18, yang saat ini masih beta1, memperkenalkan dukungan I/O asinkron (Asynchronous I/O) dan secara signifikan meningkatkan kinerja baca di lingkungan cloud
• Melalui nilai konfigurasi baru io_method, kini bisa dipilih metode worker atau io_uring selain metode sync tradisional
• Berdasarkan hasil benchmark di AWS, penggunaan io_uring memberikan peningkatan kinerja baca disk hingga 3x
• Namun, karena sifat asinkron, interpretasi timing I/O pada analisis kueri lama (EXPLAIN ANALYZE) menjadi lebih sulit
• View pemantauan baru (pg_aios) dan parameter tuning (effective_io_concurrency) diperlukan untuk optimalisasi performa

---

Penerapan I/O asinkron di Postgres 18

• Secara tradisional, Postgres menggunakan model I/O blocking, sehingga harus menunggu sampai setiap pembacaan disk selesai
• Latensi tinggi pada storage berbasis jaringan (seperti EBS) menyebabkan bottleneck di lingkungan cloud
• I/O asinkron memungkinkan beberapa pembacaan disk diproses secara paralel, sehingga meningkatkan utilisasi CPU dan throughput keseluruhan

Persiapan awal di Postgres 17: Read Stream API

• Di Postgres 17, API read_stream diperkenalkan untuk menstandarkan abstraksi operasi baca
• Namun, ini masih bergantung pada page cache OS dan tidak langsung tercermin di shared buffer milik Postgres sendiri
• Di Postgres 18, kini dimungkinkan pembacaan asinkron langsung, bukan sekadar kernel hint

Konfigurasi baru: io_method

• Postgres 18 menambahkan pengaturan io_method di postgresql.conf, dengan tiga opsi berikut:

io_method = sync

• Metode sinkron yang sama seperti Postgres sebelumnya
• Menggunakan pendekatan permintaan baca preemptive berbasis posix_fadvise()

io_method = worker (default)

• Proses worker khusus I/O membaca data secara asinkron dan mengirimkannya ke shared buffer
• Proses utama dapat terus berjalan tanpa terhenti oleh operasi baca
• Jumlah worker default adalah 3, dan bisa disesuaikan melalui pengaturan io_workers

io_method = io_uring

• Antarmuka I/O berperforma tinggi yang tersedia di Linux kernel 5.1 ke atas
• Tanpa proses worker, pembacaan asinkron dilakukan langsung melalui shared ring buffer dengan kernel
• Membutuhkan kernel, filesystem, dan konfigurasi yang lebih baru

Benchmark kinerja I/O asinkron (berdasarkan AWS)

• Lingkungan pengujian:
  • AWS c7i.8xlarge (32 vCPU, 64GB RAM)
  • 100GB io2 EBS, 20,000 IOPS
  • Menjalankan SELECT COUNT(*) pada tabel berukuran 3.5GB

Perbandingan performa cold cache:

Versi/konfigurasi	Waktu eksekusi (ms)
Postgres 17 (sync)	15,831
Postgres 18 (sync)	15,071
Postgres 18 (worker)	10,052
Postgres 18 (io_uring)	5,723

• io_uring memberikan peningkatan performa 2.8x dibanding sync
• Sangat efektif untuk meminimalkan latensi disk di cloud

Tuning effective_io_concurrency

• Di Postgres 18, parameter ini memengaruhi jumlah permintaan read-ahead asinkron internal
• Nilai default naik dari 1 → 16, dan dikalikan dengan io_combine_limit untuk menentukan rentang baca maksimum
• Di lingkungan cloud dengan latensi tinggi, nilai yang lebih besar bisa menguntungkan, tetapi benchmark per workload tetap diperlukan

Alat pemantauan baru: pg_aios

• Di pg_stat_activity, operasi asinkron muncul sebagai event AioIoCompletion, sehingga analisis wait backend menjadi lebih sulit
• Untuk io_uring, karena kernel menanganinya secara langsung, status I/O tidak terlihat dari Postgres
• Melalui view pg_aios, detail permintaan asinkron yang sedang berlangsung dapat diperiksa

  SELECT * FROM pg_aios;  
  

• Status seperti SUBMITTED, COMPLETED_IO, serta informasi blok target dapat diperiksa

Hal yang perlu diperhatikan: perubahan interpretasi informasi timing I/O

• I/O Timings yang terlihat di EXPLAIN ANALYZE sebelumnya hanya dapat diandalkan pada metode sinkron
• Saat menggunakan worker atau io_uring yang asinkron, interpretasi informasi timing menjadi terdistorsi karena pemrosesan paralel dan distribusi ke worker
• Untuk menilai beban I/O yang sebenarnya, disarankan menggunakan jumlah buffer shared read dan pg_aios

Kesimpulan

• Postgres 18 memberikan kontribusi nyata pada peningkatan performa workload yang berfokus pada pembacaan
• Terutama bila menggunakan disk berlatensi tinggi di lingkungan cloud, manfaatnya bisa sangat besar
• Pada saat yang sama, dibutuhkan pembelajaran ulang tentang interpretasi metrik observabilitas, tuning performa, dan cara penerapan konfigurasi
• Di Postgres 19 mendatang, dukungan tulis asinkron juga diharapkan hadir

[jujumilk3]

Postgres benar-benar yang terbaik, keren banget

[GN⁺]

Komentar Hacker News

• Di Linux, preadv2(..., RWF_NOWAIT) dapat digunakan untuk melakukan pembacaan asinkron dari page cache. Ini bisa berguna untuk mengurangi latensi pada io_method = worker
  • Diusulkan pendekatan untuk mencoba membaca dengan NOWAIT di thread utama, lalu mengalihkan ke thread pekerja hanya jika gagal
• Ada pertanyaan apakah fitur I/O asinkron baru ini khusus untuk Linux
  • Windows memiliki IOCP dan implementasi IORing-nya sendiri, sementara macOS mendukung POSIX AIO
  • Disebutkan bahwa tidak banyak pembahasan tentang implementasi IORing di Windows
• Banyak pekerjaan telah dilakukan pada aio(4) di FreeBSD, dan cara kerjanya tampaknya menarik karena tidak memiliki kekurangan aio Linux/glibc
• Ada pertanyaan tentang kemiripannya dengan InnoDB milik MySQL
• Ada kekhawatiran tentang masalah keamanan io_uring, serta pertanyaan apakah banyak admin atau distro Linux menonaktifkannya
• Ada pendapat bahwa fitur ini ingin diterapkan di produksi pada NVMe, dan berharap penyedia cloud besar menyediakannya secepatnya
  • Peningkatan kinerjanya sangat menarik
• Dibagikan pengalaman menerapkan Postgres di server Hetzner EX-44
  • Rasio harga terhadap performanya sangat baik, dan menawarkan kapasitas tingkat perusahaan dengan biaya rendah
  • Keamanan diperkuat menggunakan TailScale, sepenuhnya menghilangkan paparan ke jaringan publik
  • Pendekatan optimasi mencakup konfigurasi per beban kerja melalui PGTune, pemantauan performa real-time melalui PgHero, serta pekerjaan VACUUM ANALYZE otomatis melalui pgcron
  • Dikembangkan utilitas CLI kustom untuk backup kompresi ZSTD yang mempertahankan rasio kompresi tinggi dan throughput tinggi, serta mendukung unggah otomatis ke S3
  • Pengaturan ini stabil, berkinerja baik, dan masih punya ruang tumbuh yang cukup
• Ada komentar bernada bercanda tentang 20k IOPS pada instance AWS
  • NVMe konsumen menyediakan ~1 juta+ IOPS, dan diperkirakan akan meningkat lebih jauh berkat PCIe 5.0 NVMe
  • Ada anggapan bahwa batasan cloud yang sewenang-wenang menyebabkan banyak masalah
  • Async IO sangat berguna, tetapi mungkin kurang penting pada NVMe 1 juta IOPS
  • Biaya cloud sangat mahal, dan ada kesenjangan performa besar dibandingkan perangkat keras konsumen yang murah
• Ada pertanyaan tentang perbandingan performa antara Postgres, MariaDB, dan Percona
  • Ingin tahu dalam kasus apa masing-masing database unggul
• Ada pertanyaan kapan pembaruan yang memungkinkan lebih banyak koneksi simultan akan dirilis
  • Berharap bisa berhenti menggunakan pgbouncer