PostgreSQL performans sorunlarının arkasında yavaş depolama yatıyor

POSETTE 2026 etkinliğinde sunum yapan Sai Srirampur, PostgreSQL sistemlerinde yaşanan ölçeklenme ve gecikme sorunlarının veritabanı motorundan ziyade depolama katmanındaki darboğazlardan kaynaklandığını açıkladı. Büyük veri kümelerinde görülen yavaş veri yazma, yüksek P95 okuma gecikmesi, autovacuum işlemlerinin geride kalması ve mantıksal çoğaltma gecikmeleri gibi problemlerin ortak kaynağının depolama performansı olduğunu belirten Srirampur, EBS ile yerel NVMe sürücülerini karşılaştıran bir kıyaslama testi paylaştı.

Test kapsamında 3,3 milyar satırlık ve 482 GiB boyutundaki pgbench_accounts tablosu üzerinde eşzamanlı rastgele güncelleme iş yükü çalıştırıldı. 3 bin IOPS değerindeki gp3 EBS kullanan kümeler saniyede ortalama 1.734 işlem gerçekleştirebilirken, yerel NVMe sürücülü sistemler saniyede 16.030 işleme ulaştı. Ortalama işlem gecikmesi EBS üzerinde 36,9 milisaniye ölçülürken, NVMe tarafında bu değer 4,0 milisaniyeye geriledi. Gecikme analizleri, EBS tarafındaki bekleme süresinin büyük kısmının işlemci yükünden değil, doğrudan sayfa okumaları ve WAL fsync işlemlerinin depolama kuyruğunda beklemesinden kaynaklandığını ortaya koydu.

Yerel NVMe birimlerinin sunucu kapandığında veriyi kaybetmesi riskine karşı sunumda küme düzeyinde dayanıklılık mimarisi önerildi. Bu mimari, farklı erişim alanlarına dağıtılmış iki yedek sunucuyla çoğunluk tabanlı eşzamanlı çoğaltma kurulmasını, WAL-G benzeri açık kaynaklı araçlarla nesne depolama servislerine sürekli fiziksel yedek alınmasını kapsıyor. Instacart ve Datadog gibi şirketlerin üretim ortamlarında uyguladığı bu yöntem, yerel sürücülerin düşük gecikme avantajını yüksek erişilebilirlikle birleştiriyor.