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

 (pganalyze.com)
4 puan yazan GN⁺ 2025-05-08 | 2 yorum | WhatsApp'ta paylaş
  • Ş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

İlgili okumalar

2 yorum

 
jujumilk3 2025-05-09

Postgres gerçekten en iyisi, harika.
 
GN⁺ 2025-05-08
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