אתם יכולים להגדיר את המגבלה העליונה של מאגר הנתונים הזמני המשותף כשמפעילים את AlloyDB Omni. אם לא מגדירים את המגבלה העליונה, AlloyDB Omni מגדיר אוטומטית את גודל הגיבוי של מאגר הנתונים הזמני המשותף ל-80% מזיכרון המערכת. גודל הגיבוי הראשוני של מאגר הנתונים הזמני המשותף יכול להיות שונה מהגבול העליון.
AlloyDB Omni כולל תהליך עבודה חכם של זיכרון שעוקב כל הזמן אחרי סטטוס הזיכרון, ומתאים את גודל הגיבוי של מאגר נתונים זמני משותף כדי להשיג את הביצועים הכי טובים כשמטמון נתונים.

כברירת מחדל, הפרמטר shared_buffers מוגדר לערך 0, שהוא ערך מיוחד שמגדיר את המגבלה העליונה של גודל מטמון shared buffers ל-80% מזיכרון המערכת. ההתחלה ב-AlloyDB Omni היא 10% מהתקרה העליונה של shared_buffers. אם shared_buffers מוחלף בערך מותאם אישית, AlloyDB Omni מתייחס לערך הזה כאל הגבול העליון של הגודל של shared_buffers, ומתחיל עם הגודל המותאם אישית שצוין.
כדי לציין גודל מותאם אישית, אפשר להגדיר את shared_buffers ל-1GB. השיטה תלויה בסוג הפריסה:
docker run --name CONTAINER_NAME -e INITDB_ARGS="-c shared_buffers=1GB" $imagedocker run --name CONTAINER_NAME $image -c shared_buffers=1GB
מחליפים את CONTAINER_NAME בשם שהקציתם לקונטיינר של AlloyDB Omni כשהתקנתם אותו.
אופטימיזציה של ביצועי השאילתות
ערך ברירת המחדל של הפרמטר shared_buffers מתאים לתרחישים נפוצים.
עם זאת, אפשר לשנות את הערך כדי לשפר את הביצועים.
אם בוחרים להסתמך על ערך ברירת המחדל shared_buffers כדי להסיק את הגבול העליון של המאגר המשותף, צריך להשתמש בערך של cgroup memory.max כדי להשפיע על החישוב.
זיכרון של מנוע מבוסס-עמודות
הזיכרון הדינמי של shared_buffers הוא נפרד מהזיכרון של מנוע מבוסס-עמודות. כשהמנוע מבוסס-עמודות מופעל, אפשר לחשב את הגודל הדינמי shared_buffers על ידי הפחתת כמות הזיכרון שמשמשת את המנוע מבוסס-עמודות מ-80% מהזיכרון הכולל שזמין למערכת או ל-cgroup.
דפים ענקיים
דפים גדולים משפרים את הביצועים של מסד הנתונים. AlloyDB Omni מנהל דפים גדולים באופן מפורש אם אפשר, אחרת הוא מסתמך על התכונה transparent huge pages (THP) של מערכת ההפעלה. אם אף אחד מסוגי הדפים הענקיים לא נתמך, AlloyDB Omni חוזר לדף בגודל 4k ומציג אזהרה ביומני של קונטיינר Dockerdocker logs $container_name עם הוראות ספציפיות להגדרת דפים ענקיים. הוראות להפעלת קונטיינר מפורטות במאמר הפעלת AlloyDB Omni.
האזהרה תיראה כך:
HINT: Please either execute the all-in-one setup script:
docker run --rm --privileged $image setup-host
OR manually execute:
echo within_size | sudo tee /sys/kernel/mm/transparent_hugepage/shmem_enabled
sudo sysctl -w vm.nr_overcommit_hugepages=1048576
ניהול זיכרון אוטומטי בזמן ריצה
AlloyDB Omni עוקב כל הזמן אחרי עומס המערכת, ומשנה את צריכת הזיכרון שלו כדי לשפר את הביצועים. באופן ספציפי, יכול להיות שתבחינו בשינויים הבאים:
- שינוי גודל דינמי
shared_buffers
- AlloyDB Omni מגדיל את הגודל הדינמי של
shared_buffersכשצריכת הזיכרון של המערכת נמוכה, ומקטין את הגודל כשצריכת הזיכרון של המערכת גבוהה. התוסף `g_memory` כלול בהפצה של AlloyDB Omni. כדי להפעיל את האפשרות הזו ולעקוב אחרי הגודל הדינמי של shared_buffers, מריצים את הפקודות הבאות:CREATE EXTENSION IF NOT EXISTS g_memory; SELECT g_dynamic_shared_size();
- סיום חיבור PostgreSQL כשהמערכת סובלת ממחסור חמור בזיכרון
-
כש-AlloyDB Omni מזהה שזיכרון המערכת נמוך מאוד, הוא מנסה למחוק את חיבורי PostgreSQL שצורכים הכי הרבה זיכרון עד שהעומס יחזור לרמה סבירה. כשאירוע כזה קורה, AlloyDB Omni מתעד רשומה ביומני של קונטיינר Docker, בדומה לדוגמה הבאה:
WARNING: Sending SIGTERM to pid=12345 NSpid=67890 (VA size = 1024MB) (RSS size = 512MB)