מידע על ניהול זיכרון אוטומטי

בוחרים גרסת תיעוד:

‫AlloyDB Omni משתמש באלגוריתמים דינמיים לניהול הזיכרון.

אתם יכולים להחליט מה הגבול העליון של מאגר הנתונים הזמני המשותף כשאתם מפעילים את 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, משתמשים באחת מהפקודות הבאות:

  • docker run --name CONTAINER_NAME -e INITDB_ARGS="-c shared_buffers=1GB" $image

  • docker run --name CONTAINER_NAME $image -c shared_buffers=1GB

מחליפים את CONTAINER_NAME בשם שהקציתם לקונטיינר AlloyDB Omni כשביצעתם את ההתקנה.

אופטימיזציה של ביצועי השאילתות

ערך ברירת המחדל של הפרמטר shared_buffers מתאים לתרחישים נפוצים.

עם זאת, אפשר לשנות את הערך כדי לשפר את הביצועים. אם אתם בוחרים להסתמך על ערך ברירת המחדל של shared_buffers כדי להסיק את הגבול העליון של מאגר הנתונים הזמני המשותף, השתמשו בערך memory.max של cgroup כדי להשפיע על החישוב.

זיכרון של מנוע מבוסס-עמודות

ה-shared_buffers הדינמי לא תלוי בזיכרון של המנוע מבוסס-העמודות. כשהמנוע מבוסס-עמודות מופעל, אפשר לחשב את הגודל הדינמי של shared_buffers על ידי הפחתת כמות הזיכרון שמשמשת את המנוע מבוסס-עמודות מ-80% מהזיכרון הכולל שזמין למערכת או לקבוצת הבקרה.

דפים ענקיים

דפים גדולים משפרים את הביצועים של מסד הנתונים. ‫AlloyDB Omni מנהל דפים גדולים באופן מפורש אם אפשר, אחרת הוא מסתמך על התכונה 'דפים גדולים שקופים' (THP) של מערכת ההפעלה. אם אף אחד מסוגי הדפים הגדולים לא נתמך, AlloyDB Omni חוזר לדף בגודל 4k ומציג אזהרה ביומני של קונטיינר Docker‏ docker 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)