אופטימיזציה של שימוש גבוה בזיכרון במופעים

במאמר הזה מוסבר איך לזהות שימוש גבוה בזיכרון במכונות Cloud SQL, ומומלץ איך לפתור בעיות שקשורות לזיכרון.

במאמר שיטות מומלצות לניהול השימוש בזיכרון מוסבר איך להגדיר את השימוש בזיכרון במכונת Cloud SQL.

זיהוי שימוש גבוה בזיכרון

בקטעים הבאים נדון בתרחישים של שימוש גבוה בזיכרון.

שימוש ב-Metrics Explorer כדי לזהות את השימוש בזיכרון

אפשר לבדוק את השימוש בזיכרון של המופע באמצעות המדד database/memory/components.usage בMetrics Explorer.

שימוש בתובנות לגבי שאילתות כדי לנתח את תוכנית ההסבר של שאילתות שצורכות הרבה משאבים

תובנות לגבי שאילתות עוזרות לכם לזהות, לאבחן ולמנוע בעיות בביצועי שאילתות במסדי נתונים של Cloud SQL. בתובנות לגבי שאילתות מוצגת רשימה של שאילתות שמחייבות זמן ריצה ארוך, יחד עם תוכנית ההסבר שלהן (מסמכי PostgreSQL). בודקים את תוכנית ההסבר ומזהים את החלק בשאילתה שמשתמש בשיטת סריקה עם שימוש גבוה בזיכרון. לא משנה כמה זמן הרצת השאילתה, התובנות לגבי השאילתה מספקות לכם את תוכנית ההסבר לכל השאילתות. לזהות את השאילתות המורכבות שדורשות יותר זמן, כדי לדעת אילו שאילתות חוסמות את הזיכרון למשך זמן ארוך יותר.

שיטות נפוצות לסריקה ב-PostgreSQL שמשתמשות בזיכרון רב:

  • סריקת ערימה של מפת סיביות
  • מיון מהיר
  • Hash join או Hash

שימוש גבוה בזיכרון ויומנים רלוונטיים למופעים עם Gemini

אם הפעלתם את Gemini, במקום שגיאת OOM שמובילה להשבתת מסד הנתונים, חיבור שמריץ שאילתה עם שימוש גבוה בזיכרון מסתיים, וכך נמנעת השבתת מסד הנתונים. כדי לזהות את השאילתה שמוגדרת כברירת מחדל, אפשר לבדוק את הרשומות הבאות ביומני מסד הנתונים:

  (...timestamp….) db=postgres, user=customer FATAL: terminating connection due to administrator command

מוצג יומן מסד הנתונים הבא של Cloud SQL ל-PostgreSQL, שמתעד את השאילתה עם השימוש הגבוה בזיכרון שהופסקה כדי למנוע שגיאת OOM. השאילתה היא גרסה מנורמלת של השאילתה המקורית:

  db=postgres,user=customer LOG:  postgres process with PID 1734 for the query "SELECT COUNT(product) AS item_count FROM test_table WHERE product_type = $1 AND product LIKE $2 AND c6_2 IN ($3,$4,$5,$6,$7)" has been cancelled.

התראות מוצגות גם בדף Cloud SQL Instances לגבי האירועים הבאים:

  • ניצול הזיכרון של המופע ב-24 השעות האחרונות.
  • רשימה של שאילתות שעברו נורמליזציה ובוטלו ב-24 השעות האחרונות.
  • קישור לתיעוד של Google בנושא אופטימיזציה של השימוש בזיכרון.

שימוש בנפח גדול מהזיכרון – המלצות

ההמלצות הבאות מתייחסות לבעיות נפוצות שקשורות לזיכרון. אם המופע ממשיך להשתמש בכמות גדולה של זיכרון, סביר להניח שבסופו של דבר תהיה בו בעיה מסוג out of memory. אם דרישות הזיכרון של PostgreSQL או של תהליך אחר גורמות למערכת לאבד זיכרון, תופיע הודעת ליבה Out of Memory ביומני PostgreSQL, ובסופו של דבר מופסק מופע PostgreSQL. לדוגמה:

Out of Memory: Killed process 12345 (postgres)

המקרה הנפוץ ביותר שבו נתקלים בבעיה של OOM הוא כשערך work_mem גבוה עם מספר גבוה של חיבורים פעילים. לכן, אם אתם מקבלים שגיאות OOM לעיתים קרובות או כדי להימנע משגיאות OOM במכונה שלכם ב-Cloud SQL ל-PostgreSQL, כדאי לפעול לפי ההמלצות הבאות:

  • הגדרת work_mem

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

  • מעקב אחרי סשנים פעילים

    כל חיבור משתמש בכמות מסוימת של זיכרון. כדי לבדוק את מספר החיבורים הפעילים, משתמשים בשאילתה הבאה:

      SELECT
    state,
    usename,
    count(1)
  FROM
    pg_stat_activity
  WHERE
    pid <> pg_backend_pid()
  GROUP BY
    state,
    usename
  ORDER BY
    1;

    אם יש לכם מספר גדול של סשנים פעילים, כדאי לנתח את המקור לבעיה. לדוגמה, נעילות של עסקאות.

  • הגדרת shared_buffers

    אם הערך של shared_buffers גבוה מדי, כדאי להקטין אותו כדי שהזיכרון יוכל לשמש לפעולות אחרות, כמו work_mem, או ליצירת חיבורים חדשים.shared_buffers

    שיעור מציאות במטמון (cache hit)

    בדרך כלל, מערכת PostgreSQL מנסה לשמור במטמון את הנתונים שאתם ניגשים אליהם הכי הרבה. כשלקוח מבקש נתונים, אם הם כבר שמורים במאגרים משותפים, הם מועברים ישירות ללקוח. זה נקרא פגיעה במטמון. אם הנתונים לא נמצאים במאגרי נתונים משותפים, המערכת מאחזרת אותם קודם מהדיסק למאגרי הנתונים המשותפים, ואז מעבירה אותם ללקוח. זה נקרא cache miss (אי מציאה במטמון). שיעור מציאות במטמון (cache hit) מודד כמה בקשות לתוכן המטמון טיפל בהן בהשוואה לבקשות שהתקבלו. מריצים את השאילתה הבאה כדי לבדוק את שיעור מציאות במטמון (cache hit) של בקשות הטבלה במופע PostgreSQL:

    SELECT
  sum(heap_blks_read) as heap_read,
  sum(heap_blks_hit)  as heap_hit,
  sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read)) as ratio
FROM
  pg_statio_user_tables;

    מריצים את השאילתה הבאה כדי לבדוק את שיעור מציאות במטמון (cache hit) של בקשות האינדקס במכונת PostgreSQL:

      SELECT
    sum(idx_blks_read) as idx_read,
    sum(idx_blks_hit)  as idx_hit,
    (sum(idx_blks_hit) - sum(idx_blks_read)) / sum(idx_blks_hit) as ratio
  FROM
    pg_statio_user_indexes;

    באופן כללי, שיעור מציאות במטמון (cache hit) של 95% עד 99% נחשב לערך טוב.

  • ב-Cloud SQL ל-PostgreSQL, הדגל huge_pages מופעל כברירת מחדל כדי לשפר את ניהול הזיכרון. מידע נוסף על huge_pages זמין במסמכי התיעוד של PostgreSQL.

  • הגדרת max_locks_per_transaction

    הערך max_locks_per_transaction מציין את מספר אובייקטי מסד הנתונים שאפשר לנעול בו-זמנית. ברוב המקרים, ערך ברירת המחדל 64 מספיק. עם זאת, אם אתם עובדים עם מערך נתונים גדול, יכול להיות שתקבלו שגיאות OOM. כדאי להגדיל את הערך של max_locks_per_transaction מספיק כדי למנוע שגיאות OOM.

    הערך של max_locks_per_transaction צריך להיות max_locks_per_transaction * (max_connections + max_prepared_transactions) אובייקטים. המשמעות היא שאם יש לכם 300,000 אובייקטים, והערך של max_connections הוא 200, אז הערך של max_locks_per_transaction צריך להיות 1,500.

  • הגדרת max_pred_locks_per_transaction

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

  • אם השימוש בזיכרון עדיין גבוה ואתם חושבים שהשאילתות האלה מייצגות תנועה לגיטימית, כדאי להגדיל את מספר משאבי הזיכרון במופע כדי למנוע קריסה של מסד הנתונים או השבתה.

המאמרים הבאים