Postgres אינו איטי. האיטי הוא האחסון שלך: סיכום ההרצאה מ-POSETTE 2026

הכנת הבנצ'מרק

ב-POSETTE 2026 Sai Srirampur הציג את ההרצאה „Postgres Isn't Slow. Your Storage Is" שבה נדון כיצד ביצועי אחסון משפיעים על PostgreSQL בקנה מידה. במצגת הודגשו חמישה תסמינים נפוצים: אינגסט איטי, חוסר עקביות בזמן השחזור של קריאות, חוסר בהתקדמות של autovacuum, checkpoint-ים איטיים וחוסר בהתקדמות של רפליקציה לוגית. בעיות אלו לעיתים קרובות נובעות מאותו שורש: ביצועי אחסון כאשר ערכי העבודה חורגים מזיכרון הזמין.

כדי לבודד את האחסון כמשתנה, הבנצ'מרק השתמש בשמונה מחשורי PostgreSQL זהים: ארבעה על instance-store NVMe וארבעה על gp3 EBS בסיסי, עם 3000 IOPS. כל מחשור רץ על מופע m6id.4xlarge עם 16 vCPU, 64 GiB RAM ו-16 GiB shared_buffers. עומס העבודה השתמש ב-heap של pgbench_accounts בנפח 482 GiB, שהכיל 3.3 מיליארד שורות, וביצע עומס random-UPDATE בקונקורנטיות גבוהה עם 64 לקוחות ו-16 worker thread-ים למשך חמש דקות.

מה הראו התוצאות

הבנצ'מרק הראה 16,030 TPS בחציון עבור מחשורי NVMe, לעומת 1,734 TPS על EBS, כלומר הפרש של 9.24 פעמים. זמן השחזור החוצה של טרנזקציות ירד מ-36.9 ms ל-4.0 ms. עבור פעולות טכניות, NVMe השלים VACUUM על 10 GB של bloat תוך 366 שניות, בעוד EBS ארך 964 שניות, ו-backlog של 10 GB של רפליקציה לוגית הושלם תוך 139 שניות במקום 238.

פירוק זמני השחזור הראה שקריאת עמודים ארכה כ-19 ms על EBS, לעומת 0.3 ms על NVMe, WAL fsync ארך 11 ms במקום 1.5 ms, ו-overhead של lock ו-scheduler ארך 5 ms במקום 0.2 ms. זמן ה-CPU היה כמעט זהה בשני המקרים, כ-2 ms. צילום מסך של pg_stat_activity הראה שמתוך 64 backend-ים על EBS, 29 היו ממתינים ל-IO:DataFileRead, בעוד על NVMe רק תשעה. בחלון פרופילינג של 240 שניות, מארח NVMe צבר 2,253 שניות-CPU, בעוד מארח EBS רק 251, מה שמצביע על כך שתהליכי EBS בילו הרבה יותר זמן מחוץ ל-CPU, בהמתנה לאחסון.

Postgres מבוסס NVMe בפרודקשן

הארכיטקטורה המוצגת בהרצאה עונה על מגבלות העמידות של instance-store NVMe בשלושה דרישות: בצע רפליקציה של מסד הנתונים כדי שהשירות יוכל להתמודד עם אובדן node, שמור גיבויים ונתוני שחזור מחוץ למכונות הבודדות, ותכנן את הכול לפי זמינות ה-NVMe בכל instance type.

התבנית הראשונה היא רפליקציה סינכרונית מבוססת quorum עם שני מועמדי standby, בתצורה למשל ANY 1 (standby1, standby2), שמאפשרת לטרנזקציה לבצע commit לאחר שאחד ה-standby-ים מאשר את ה-WAL. לעמידות מחוץ ל-node-ים של מסד הנתונים, כלי קוד פתוח כמו WAL-G יכולים לבצע base backup-ים פיזיים וארכיונת WAL רציפה, עם RPO יעד בשניות. ההרצאה מציגה דוגמאות פומביות של Instacart ו-Datadog שתיארו הפעלה של PostgreSQL על NVMe מקומי עבור עומסי עבודה רגישים לזמן שחזור.

מקורות: clickhouse.com