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

בוחרים גרסה של מאמר העזרה:

‫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, ומתחיל עם הגודל המותאם אישית שצוין.

כדי לציין גודל מותאם אישית, עורכים את קובץ התצורה postgresql.conf. לדוגמה, אפשר להגדיר את shared_buffers ל-1GB באחת מהדרכים הבאות:

  • 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 כדי להסיק את הגבול העליון של מאגר הנתונים הזמני המשותף, תצטרכו להשתמש בערך של cgroup memory.max כדי להשפיע על החישוב.

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

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

דפים ענקיים

דפים גדולים משפרים את הביצועים של מסד הנתונים. ‫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 כשצריכת הזיכרון של המערכת נמוכה, ומקטין את הגודל כשצריכת הזיכרון של המערכת גבוהה. כדי לעקוב אחרי הגודל הדינמי של 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=xxx NSpid=xxx (VA size = xxxMB) (RSS size = xxxMB)