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

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

‫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. השיטה תלויה בסוג הפריסה:

בהתקנות מבוססות-Linux (כולל RPM), אפשר להגדיר את הפרמטר shared_buffers באחת מהשיטות הבאות. אחרי שמחילים את השינוי, צריך להפעיל מחדש את השירות.

  • אפשרות 1: עריכת קובץ התצורה

    1. פותחים את הקובץ postgresql.conf לעריכה.

    2. מוסיפים או משנים את השורה הבאה:

      shared_buffers = 1GB
      
    3. שומרים את הקובץ ומפעילים מחדש את שירות AlloyDB Omni:

      sudo systemctl restart alloydbomniMAJOR_VERSION

      מחליפים את MAJOR_VERSION בגרסה הראשית של התקנת AlloyDB Omni, למשל 18.

  • אפשרות 2: שימוש בפקודה ALTER SYSTEM

    1. מתחברים למכונה של מסד הנתונים באמצעות לקוח SQL.

    2. מריצים את הפקודה הבאה:

      ALTER SYSTEM SET shared_buffers = '1GB';
      
    3. מפעילים מחדש את שירות AlloyDB Omni:

      sudo systemctl restart alloydbomniMAJOR_VERSION

      מחליפים את MAJOR_VERSION בגרסה הראשית של התקנת AlloyDB Omni, למשל 18.

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

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

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

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

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

דפים ענקיים

דפים ענקיים משפרים את הביצועים של מסד הנתונים. מערכת AlloyDB Omni מנהלת דפים ענקיים באופן מפורש אם אפשר, אחרת היא מסתמכת על התכונה 'דפים ענקיים שקופים' (THP) של מערכת ההפעלה. אם אף אחד מסוגי הדפים הענקיים לא נתמך, מערכת AlloyDB Omni חוזרת לדף בגודל 4k ומדפיסה אזהרה ביומני מסד הנתונים עם הוראות ספציפיות להגדרת דפים ענקיים.

האזהרה תיראה כך:


HINT:  Please manually execute:
          echo within_size | sudo tee /sys/kernel/mm/transparent_hugepage/shmem_enabled
          sudo sysctl -w vm.nr_overcommit_hugepages="$(/usr/bin/awk '/MemTotal/ { printf "%.0f", $2/1024 }' /proc/meminfo)"

ניהול זיכרון אוטומטי בזמן ריצה

‫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 רושמת ביומני מסד הנתונים רשומה שדומה לדוגמה הבאה:
WARNING: Sending SIGTERM to pid=12345 NSpid=67890 (VA size = 1024MB) (RSS size = 512MB)