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

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

    שיעור מציאות במטמון (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 משתמש בזיכרון משותף, לכן לא כדאי להגדיר ערך גבוה מדי.

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

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