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

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

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

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

ה-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)