Postgres Yavaş Değil. Yavaş Olan Depolamanız: POSETTE 2026 Sunumu Özeti

Kıyaslamanın Hazırlanışı

POSETTE 2026'da Sai Srirampur, depolama verimliliğinin PostgreSQL'in ölçeklendirilmesini nasıl etkilediğini ele alan “Postgres Yavaş Değil. Depolama Yavaş” adlı konuşmayı sundu. Sunumda beş sık görülen belirti vurgulandı: yavaş veri alımı, tutarsız okuma gecikmesi, otovacuum yavaşlığı, yavaş checkpoint'ler ve mantıksal replikasyonda yavaşlama. Bu sorunlar, çalışma kümesi kullanılabilir belleği aştığında sıkça aynı kökene, depolama verimliliğine bağlanır.

Depolamayı bir değişken olarak ortaya çıkarmak için kıyaslamada sekiz özdeş PostgreSQL kümesi kullanıldı: dördü instance-store NVMe üzerinde, dördü ise 3000 IOPS ile temel gp3 EBS üzerinde. Her küme, 16 vCPU, 64 GiB RAM ve 16 GiB shared_buffers ile bir m6id.4xlarge örneğinde çalışıyordu. İş yükü, 3,3 milyar satırdan oluşan 482 GiB pgbench_accounts heap kullanıyordu ve beş dakika boyunca 64 istemci ile 16 iş parçacığı üzerinden yüksek eşzamanlı random-UPDATE yükünü tamamlıyordu.

Sonuçların Gösterdiği

Kıyaslama, NVMe kümelerinde medyan 16 030 TPS gösterirken EBS üzerinde 1 734 TPS oldu; yani 9,24 kat fark. İşlem gecikmesi medyanı 36,9 ms'den 4,0 ms'ye düştü. Teknik işlemler için NVMe, 10 GB bloat üzerinde VACUUM işlemini 366 saniyede tamamlarken, EBS bu işlemi 964 saniyede tamamladı; 10 GB mantıksal replikasyon birikimi ise 238 saniye yerine 139 saniyede bitti.

Gecikme dökümü, sayfa okumalarının EBS üzerinde yaklaşık 19 ms, NVMe üzerinde 0,3 ms sürdüğünü; WAL fsync ek maliyetinin 1,5 ms yerine 11 ms olduğunu; kilit ve zamanlayıcı ek maliyetinin ise 0,2 ms yerine 5 ms olduğunu gösterdi. CPU tüketimi her iki durumda da yaklaşık aynıydı, yaklaşık 2 ms. pg_stat_activity anlık görüntüsü, EBS üzerinde 64 arka uçtan 29'sunun IO:DataFileRead beklediğini, NVMe üzerinde ise dokuzunun beklediğini gösterdi. 240 saniyelik profilleme penceresinde NVMe sunucusu 2 253 CPU saniyesi biriktirirken EBS sunucusu yalnızca 251 saniye biriktirdi; bu, EBS süreçlerinin CPU dışında depolama beklemesinde çok daha fazla harcadığını gösteriyor.

NVMe Tabanlı Postgres Üretimde

Sunumda önerilen üretim mimarisi, instance-store NVMe'nin dayanıklılık sınırlarını üç gereksinime yanıt vererek aşar: veritabanını çoğaltarak hizmetin bir düğüm kaybını taşımasını sağlayın, yedekleri ve kurtarma verilerini başka makinelerde saklayın ve kapasiteyi her örnek türünde NVMe'nin kullanılabilirliğine göre planlayın.

Birinci desen, iki standby adayı ile quorum tabanlı eşzamanlı replikasyondur; örneğin ANY 1 (standby1, standby2) yapılandırması, işlemin bir standby WAL'i doğruladıktan sonra commit edilmesine olanak tanır. Veritabanı düğümlerinin dışında dayanıklılık için WAL-G gibi açık kaynak araçlar, fiziksel temel yedekleri ve kesintisiz WAL arşivlemeyi, RPO hedefini saniyeler içinde tutmayı mümkün kılar. Sunum, Instacart ve Datadog'un PostgreSQL'i gecikme hassas yükler için yerel NVMe üzerinde çalıştırdığını anlatan herkese açık örneklerini aktarıyor.

Kaynaklar: clickhouse.com