Postgres 18’i Beklerken: Asenkron I/O ile Disk Okuma Hızında Artış

• Şu anda beta1 aşamasındaki Postgres 18, asenkron I/O (Asynchronous I/O) desteği getiriyor ve özellikle bulut ortamlarında okuma performansını büyük ölçüde iyileştiriyor
• Yeni io_method ayarıyla geleneksel sync yönteminin yanı sıra worker ve io_uring yöntemleri seçilebiliyor
• AWS tabanlı benchmark sonuçlarına göre, io_uring kullanıldığında disk okuma performansı 3 kata kadar artıyor
• Ancak asenkronlaşma nedeniyle mevcut sorgu analizi (EXPLAIN ANALYZE) içindeki I/O zamanlamalarını yorumlamak daha zor hale geliyor
• Yeni izleme görünümü (pg_aios) ve ayar parametreleri (effective_io_concurrency) ile performans optimizasyonu gerekiyor

---

Postgres 18’de asenkron I/O’nun kullanıma girmesi

• Geleneksel olarak Postgres, blocking I/O modelini kullanıyordu; bu nedenle her disk okuması tamamlanana kadar bekliyordu
• Ağ tabanlı depolamada (EBS vb.) yüksek gecikme süreleri nedeniyle bulut ortamlarında darboğaz oluşuyordu
• Asenkron I/O, birden çok disk okumasının paralel işlenmesini mümkün kılarak CPU kullanımını ve genel throughput’u artırıyor

Postgres 17’de ön hazırlık: Read Stream API

• Postgres 17, read_stream API’sini sunarak okuma işlemlerinin soyutlamasını standartlaştırdı
• Ancak bu yapı hâlâ OS page cache’e dayanıyor ve Postgres’in kendi shared buffer’ına doğrudan yansımıyor
• Postgres 18 ile kernel ipuçları yerine doğrudan asenkron okuma mümkün hale geliyor

Yeni ayar: io_method

• Postgres 18, postgresql.conf içine io_method ayarını ekliyor ve şu 3 seçeneği sunuyor:

io_method = sync

• Mevcut Postgres ile aynı senkron yöntem
• posix_fadvise() tabanlı okuma önceden getirme yaklaşımını kullanıyor

io_method = worker (varsayılan)

• I/O’ya adanmış worker process’ler veriyi asenkron olarak okuyup shared buffer’a iletiyor
• Ana process, okuma işlemi kesilmeden çalışmaya devam edebiliyor
• Varsayılan worker sayısı 3 ve io_workers ayarıyla değiştirilebiliyor

io_method = io_uring

• Linux kernel 5.1 ve üzeri sürümlerde kullanılabilen yüksek performanslı I/O arayüzü
• Worker process olmadan da kernel ile paylaşılan ring buffer üzerinden doğrudan asenkron okuma yapabiliyor
• Güncel kernel, dosya sistemi ve yapılandırma gerektiriyor

Asenkron I/O performans benchmark’ı (AWS tabanlı)

• Test ortamı:
  • AWS c7i.8xlarge (32 vCPU, 64GB RAM)
  • 100GB io2 EBS, 20.000 IOPS
  • 3.5GB büyüklüğündeki bir tabloda SELECT COUNT(*) çalıştırıldı

Cold cache performans karşılaştırması:

Sürüm/Ayar	Çalışma süresi (ms)
Postgres 17 (sync)	15,831
Postgres 18 (sync)	15,071
Postgres 18 (worker)	10,052
Postgres 18 (io_uring)	5,723

• io_uring, sync ile karşılaştırıldığında 2,8 kat performans artışı sağlıyor
• Bulutta disk gecikmesini azaltmada özellikle etkili

effective_io_concurrency ayarı

• Postgres 18’de bu parametre, iç asenkron read-ahead isteklerinin sayısını etkiliyor
• Varsayılan değer 1’den 16’ya yükseltildi ve io_combine_limit ile çarpılarak en yüksek okuma aralığı belirleniyor
• Gecikmesi yüksek bulut ortamlarında daha büyük değerler avantaj sağlayabilir, ancak iş yüküne göre benchmark yapılması gerekiyor

Yeni izleme aracı: pg_aios

• pg_stat_activity içinde asenkron işlemler AioIoCompletion olayı olarak göründüğünden backend bekleme analizini yapmak zorlaşıyor
• io_uring durumunda işlemler doğrudan kernel tarafından yürütüldüğü için I/O durumu Postgres içinde görünmüyor
• pg_aios görünümü üzerinden o anda devam eden asenkron isteklerin ayrıntıları görülebiliyor

  SELECT * FROM pg_aios;  
  

• SUBMITTED, COMPLETED_IO gibi durumlar ve hedef blok bilgileri görülebiliyor

Dikkat edilmesi gereken nokta: I/O zamanlama bilgilerinin yorumlanması değişiyor

• Mevcut EXPLAIN ANALYZE içindeki I/O Timings, yalnızca senkron yöntemde güvenilir kabul edilebilir
• Asenkron worker ve io_uring kullanıldığında paralel işleme ve worker dağılımı nedeniyle zamanlama bilgisinin yorumu bozulabiliyor
• Gerçek I/O yükünü değerlendirirken shared read buffer sayısı ve pg_aios kullanımı öneriliyor

Sonuç

• Postgres 18, okuma ağırlıklı iş yüklerinde performans artışına somut katkı sağlıyor
• Özellikle bulut ortamlarındaki yüksek gecikmeli diskleri kullananlar için önemli avantajlar sunabilir
• Aynı zamanda gözlem metriklerinin yorumlanması, performans ayarı ve yapılandırma uygulama biçimi konusunda yeniden öğrenme gerektiriyor
• Gelecekte Postgres 19’da asenkron yazma desteği de bekleniyor

[jujumilk3]

Postgres gerçekten en iyisi, harika.

[GN⁺]

Hacker News yorumları

• Linux'ta preadv2(..., RWF_NOWAIT) kullanılarak sayfa önbelleğinden asenkron okuma yapılabiliyor. Bu, io_method = worker durumunda gecikmeyi azaltmak için faydalı olabilir
  • Ana iş parçacığında NOWAIT ile okumayı deneyip yalnızca başarısız olursa işi worker iş parçacığına devretme yöntemi öneriliyor
• Bu yeni asenkron I/O özelliğinin yalnızca Linux'a mı özel olduğu soruluyor
  • Windows'ta IOCP ve kendi IORing uygulaması var, macOS ise POSIX AIO'yu destekliyor
  • Windows'un IORing uygulamasından çok fazla bahsedilmediğine dikkat çekiliyor
• FreeBSD'nin aio(4) özelliği üzerinde çok çalışma yapıldığı ve Linux/glibc aio'nun dezavantajlarına sahip olmaması nedeniyle nasıl çalıştığının ilginç olacağı belirtiliyor
• MySQL'in InnoDB'siyle benzerlik olup olmadığı soruluyor
• io_uring güvenlik sorunlarına dair endişeler var; birçok Linux yöneticisinin veya dağıtımın bunu devre dışı bırakıp bırakmadığı soruluyor
• NVMe üzerinde bu özelliği prodüksiyonda kullanmak istediklerini söyleyenler var ve büyük bulut sağlayıcılarının bunu ASAP sunmasını umuyorlar
  • Performans artışı çok cazip görünüyor
• Hetzner EX-44 sunucularında Postgres dağıtma deneyimi paylaşılıyor
  • Fiyat/performans oranının olağanüstü olduğu ve kurumsal düzeyde kapasiteyi düşük maliyetle sunduğu belirtiliyor
  • Güvenliği artırmak için TailScale kullanıldığı ve genel ağa maruz kalmanın tamamen kaldırıldığı söyleniyor
  • Optimizasyon yaklaşımında PGTune ile iş yüküne özel yapılandırma, PgHero ile gerçek zamanlı performans izleme ve pgcron ile otomatik VACUUM ANALYZE işleri yer alıyor
  • Yüksek sıkıştırma oranı ve yüksek aktarım hızını korurken otomatik S3 yüklemelerini destekleyen ZSTD sıkıştırmalı yedekler için özel bir CLI yardımcı programı geliştirildiği belirtiliyor
  • Bu kurulumun kararlı, yüksek performanslı ve büyüme için bolca alan sunduğu söyleniyor
• AWS instance'larındaki 20k IOPS hakkında alaycı bir yorum var
  • Tüketici sınıfı NVMe'nin yaklaşık 1 milyon+ IOPS sunduğu ve PCIe 5.0 NVMe ile bunun daha da artmasının beklendiği belirtiliyor
  • Buluttaki keyfi sınırların pek çok soruna yol açtığı düşünülüyor
  • Asenkron IO'nun çok faydalı olduğu, ancak 1 milyon IOPS NVMe'de öneminin daha az olacağı söyleniyor
  • Bulut maliyetlerinin çok yüksek olduğu ve ucuz tüketici donanımıyla arasında büyük performans farkı bulunduğu belirtiliyor
• Postgres, MariaDB ve Percona arasında performans karşılaştırması soruluyor
  • Her veritabanının hangi durumlarda öne çıktığı merak ediliyor
• Daha fazla eşzamanlı bağlantıya izin veren güncellemenin ne zaman çıkacağı soruluyor
  • pgbouncer kullanmayı bırakabilmeyi umdukları ifade ediliyor