Postgres yavaş deyil. Yavaş olan sizin saxlama qurğunuzdur: POSETTE 2026 hesabatı xülasəsi

Bencmarkın hazırlanması

POSETTE 2026-da Sai Srirampur „Postgres Isn't Slow. Your Storage Is“ adlı hesabatı təqdim etdi; burada saxlama məhsuldarlığının PostgreSQL miqyasına təsiri araşdırıldı. Təqdimatda beş tez-tez simptom vurğulandı: yavaş ingest, ardıcıl oxuma gecikməsi, avtovakuumun geridə qalması, yavaş checkpoint-lər və loqik replikasiyanın geridə qalması. Bu problemlər çox vaxt saxlama məhsuldarlığındakı eyni mənbəyi paylaşır, iş dəstləri əlçatan yaddaşa çatmadıqda.

Saxlama dəyişəni kimi ayırmaq üçün bencmarkda səkkiz eyni PostgreSQL klasteri istifadə edildi: dördü instance-store NVMe-də, dördü isə 3000 IOPS olan əsas gp3 EBS-də. Hər klaster m6id.4xlarge nümunəsində 16 vCPU, 64 GiB RAM və 16 GiB shared_buffers ilə işlədi. İş yükü 3,3 milyard sətirdən ibarət 482 GiB pgbench_accounts heap istifadə etdi və beş dəqiqə ərzində 64 müştəri və 16 worker thread ilə yüksək paralellikli random-UPDATE yükünə əldə etdi.

Nəticələr nə göstərdi

Bencmark NVMe klasterləri üçün median 16 030 TPS göstərdi, EBS-də isə 1 734 TPS, yəni 9,24 dəfə fərq. Tranzaksiya median gecikməsi 36,9 ms-dən 4,0 ms-ə qədər düşdü. Texniki əməliyyatlar üçün NVMe 10 GB bloat üzərində VACUUM-u 366 saniyədə, EBS-də isə 964 saniyədə tamamladı, 10 GB loqik replikasiya backloqi isə 238 əvəz 139 saniyədə tamamlandı.

Gecikmənin təhlili göstərdi ki, səhifələrin oxunması EBS-də təxminən 19 ms, NVMe-də isə 0,3 ms sürür; WAL fsync əlavə olaraq 1,5 ms əvəz 11 ms, lock və scheduler overhead isə 0,2 ms əvəz 5 ms təşkil etdi. CPU işi hər iki halda təxminən eyni, təxminən 2 ms idi. pg_stat_activity snapshot-ı göstərdi ki, EBS-nin 64 backend-indən 29-u IO:DataFileRead-i gözləyir, NVMe-də isə doqquz. 240 saniyəlik profilləşdirmə pəncərəsində NVMe hostu 2 253 CPU saniyəsi topladı, EBS hostu isə yalnız 251; bu, EBS proseslərinin çox vaxt CPU-da deyil, saxlama gözləməsində keçdiyini göstərir.

NVMe üzərində qurulan Postgres istehsalda

Hesabatda təqdim olunan istehsal memarlığı instance-store NVMe davamlılığı məhdudiyyətlərinə üç tələblə cavab verir: verilənlər bazasını replikasiya et ki, xidmət node itkisinə dözəsin; ehtiyat nüsxələri və bərpaya verilənləri ayrı maşınlarda saxla; hər instance type üçün əlçatan NVMe-ə görə gücü planla.

Birinci nümunə iki standby namizədlı quorum əsasında sinxron replikasiyadır, konfigurasiya məsələn ANY 1 (standby1, standby2), bu tranzaksiyanın hər hansı standby WAL-i təsdiqlədikdən sonra commit olmasına imkan verir. Verilənlər bazası node-larının xaricində davamlılıq üçün WAL-G kimi açıq mənbə alətlər fiziki base backup-lər və davamlı WAL arxivləşdirməsini, saniyələrə qədər RPO-nu təmin edə bilər. Hesabat Instacart və Datadog-un PostgreSQL-i latency-sensitive yük üzərində lokal NVMe-də işlətməyi təsvir edən açıq nümunələri gətirir.

Mənbələr: clickhouse.com