POSETTE benchmark'ı: yerel NVMe, 3,3 milyar satırlık bir Postgres iş yükünü temel EBS'ye göre 9,2 kat daha hızlı çalıştırdı

Tanıdık bir dizi arıza, tek bir ortak neden

POSETTE 2026'da Sai Srirampur, "Postgres Isn't Slow. Your Storage Is." (Postgres Yavaş Değil, Depolamanız Yavaş) başlıklı bir sunum yaptı ve ölçek büyüdüğünde birbiriyle ilgisiz görünen PostgreSQL sorunlarının çoğunun tek bir katmana, yani veritabanının altındaki depolamaya dayandığını savundu. ClickHouse tarafından yayımlanan bir özet, bu iddianın ardındaki benchmark'ı ve onun üzerine kurulan üretim mimarisini adım adım anlatıyor.

Özete göre, bir iş yükü gerçek eşzamanlılıkla yüzlerce gigabayt veya terabayt boyutuna ulaştığında belirtiler kendini gösteriyor: UPDATE ve UPSERT ağırlıklı veri alma hatları saniyelerden dakikalara uzuyor; sorguların çoğu hızlı kalırken P95 gecikmesi milisaniyelerden saniyelere fırlıyor; autovacuum geride kalıyor ve şişme (bloat) birikiyor; checkpoint'ler I/O ve CPU için istemci trafiğiyle rekabet etmeye başlıyor; ve Kafka veya ClickHouse gibi sistemlere yapılan mantıksal replikasyon, WAL çözümlemesi yavaşladıkça gecikmeye düşüyor.

Hepsini birbirine bağlayan iplik şudur: çalışma kümesi (working set) hem veritabanının belleğini hem de işletim sisteminin page cache'ini aştığında, okumaların daha fazlası fiziksel I/O'ya dönüşür. Bu arada heap ve index yazmaları, WAL senkronizasyonu, checkpoint'ler, vacuum ve mantıksal çözümleme taşmaları hep aynı bant genişliği, IOPS ve kuyruk kapasitesi havuzundan beslenir. Depolama bu limitlerden birine takıldığında işlemler birbirini geciktirmeye başlar; tek bir yavaş katman, görünüşte ilgisiz birçok sorunu böylece yaratabilir.

Benchmark kurulumu

Depolamayı tek değişken olarak izole etmek için test, aksi halde birbirinin aynı olan sekiz PostgreSQL kümesi kullandı: dördü instance-store NVMe üzerinde, dördü ise 3.000 IOPS ile sağlanan temel gp3 EBS üzerinde. Her küme, 16 vCPU, 64 GiB RAM ve 16 GiB shared_buffers'a sahip bir m6id.4xlarge instance üzerinde, 3,3 milyar satır tutan 482 GiB'lik bir pgbench_accounts heap'iyle çalıştı. Ardından her küme, 64 istemci ve 16 worker thread ile beş dakika boyunca aynı yüksek eşzamanlılıklı rastgele UPDATE iş yükünü yürüttü.

Sayılar ne gösterdi

NVMe kümeleri saniyede medyan 16.030 işlem'e ulaşırken EBS üzerinde bu sayı 1.734 TPS oldu; bu testteki fark 9,24 kat. Medyan işlem gecikmesi 36,9 ms'den 4,0 ms'ye düştü. Fark arka plan işlerine de uzandı: 10 GB şişme üzerinde bir VACUUM, NVMe'de 366 saniyede, EBS'de ise 964 saniyede tamamlandı; 10 GB'lık mantıksal replikasyon birikimi ise 238 yerine 139 saniyede eridi.

EBS işlem gecikmesinin ayrıştırması, sürenin nereye gittiğini açıklıyor. Sayfa okumaları EBS'de yaklaşık 19 ms, NVMe'de 0,3 ms tuttu; commit sırasındaki WAL fsync yaklaşık 11 ms'ye karşılık 1,5 ms ekledi; lock ve zamanlayıcı (scheduler) yükü de yaklaşık 5 ms'ye karşılık 0,2 ms katkıda bulundu. CPU işinin kendisi neredeyse aynıydı, her iki durumda da yaklaşık 2 ms. Veritabanı EBS'de daha fazla iş yapmıyordu; ek sürenin büyük kısmını depolamayı bekleyerek geçiriyordu.

Aynı sonuca işaret eden iki gözlem daha var. Test ortasından alınan bir pg_stat_activity anlık görüntüsü, EBS'de 64 backend'in 29'unun IO:DataFileRead üzerinde beklediğini, NVMe'de ise 9'unun beklediğini gösterdi; kabaca yüzde 45'e karşı yüzde 14 — ancak özet bunun koşu ortalaması değil, tek bir anlık örneklem olduğunu belirtiyor. Yaklaşık 240 saniyelik bir profilleme penceresinde NVMe sunucusu 2.253 CPU-saniye (yaklaşık 9,4 meşgul çekirdek) biriktirirken EBS sunucusu yalnızca 251 CPU-saniye (yaklaşık bir çekirdek) biriktirdi: EBS backend'leri çoğunlukla CPU dışında bekliyordu, NVMe ise çekirdeklerini yararlı işle meşgul tutuyordu.

Özet, karşılaştırmanın sınırları konusunda açık: sonuçlar bu iş yüküne ve bu yapılandırmalara aittir ve EBS tarafı 3.000 IOPS'luk temel gp3 kullandı. Farklı şekilde sağlanmış bir EBS kurulumu büyük olasılıkla farklı sayılar üretirdi.

Geçici depolamayı üretime uygun hale getirmek

Yerel NVMe'ye en itiraz edilebilir nokta, instance-store birimlerin makineye bağlı olması: veri düğümle birlikte kaybolur, birimler EBS API üzerinden snapshot alınamaz ve kapasite instance türüne bağlıdır. Sunumun cevabı dayanıklılığı tekil bir düğümde değil küme düzeyinde sağlamak; bunun için üç gereksinim var:

• Düğüm kaybına dayanan replikasyon: iki standby adayıyla, quorum temelli senkron replikasyon. ANY 1 (standby1, standby2) gibi bir yapılandırmayla bir işlem, yavaş olanı beklemeden, WAL'ını kalıcı olarak onaylayan standby'lardan herhangi biri olduğunda commit edilir; ve düğümler bir AZ arızasına dayanabilmek için farklı availability zone'lara yayılır.
• Yedeklerin ve kurtarma verilerinin veritabanı makinelerinin dışında tutulması; örneğin açık kaynak WAL-G aracıyla fiziksel base backup ve sürekli WAL arşivleme.
• Her instance türünde mevcut NVMe'ye göre kapasite planlaması.

Neden önemli

Bu benchmark, birçok operasyon ekibinin şüphelendiği şeye sayısal bir dayanak sağlıyor: PostgreSQL ölçek büyüdüğünde yavaşladığında motor çoğu zaman çalışmak yerine bekliyordur ve depolama sınıfı eldeki en büyük kaldıraçtır. Sayfa okumalarını, WAL senkronlarını, zamanlayıcı yükünü ve CPU süresini ayıran gecikme ayrıştırması da, açıklanamayan kuyruk gecikmesinin peşinde olan herkes için aktarılabilir bir teşhis tekniğidir. Önerilen mimari ise yerel NVMe'nin ana dezavantajının —geçiciliğinin— senkron replikasyon artı düğüm dışı yedeklerle mühendislik yoluyla aşılabileceğini gösteriyor. gp3 uyarısı iki yönlü işliyor: temel ağ depolaması en kötü duruma yakın, dolayısıyla 9,24 katlık figür evrensel bir sabit değil, fırsatın büyüklüğü olarak okunmalı.