פתרון בעיות שקשורות לשגיאות של חוסר זיכרון במכונה וירטואלית

בדף הזה מוסבר על שגיאות של חוסר זיכרון (OOM) במכונה וירטואלית של Compute Engine ב-Managed Service for Apache Spark, וגם מפורטים השלבים לפתרון בעיות ולתיקון שגיאות OOM.

ההשפעות של שגיאות OOM

כשמכונות וירטואליות של Managed Service for Apache Spark נתקלות בשגיאות של חוסר זיכרון (OOM), ההשפעות כוללות את התנאים הבאים:

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

  • שגיאות OOM במכונות וירטואליות ראשיות גורמות לכשלים בעבודות עם שגיאות מסוג 'המשימה לא נרכשה'.

  • שגיאות OOM במכונות וירטואליות של Worker גורמות לאובדן הצומת ב-YARN HDFS, מה שמעכב את הביצוע של משימות Managed Service for Apache Spark.

אמצעי בקרה של זיכרון YARN

‫Apache YARN מספק את הסוגים הבאים של אמצעי בקרה לזיכרון:

  • על סמך סקרים (מדור קודם)
  • מחמיר
  • אלסטי

כברירת מחדל, Managed Service for Apache Spark לא מגדיר את yarn.nodemanager.resource.memory.enabled כדי להפעיל את אמצעי הבקרה של זיכרון YARN, מהסיבות הבאות:

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

הגנה על הזיכרון של Managed Service for Apache Spark

כשמכונה וירטואלית באשכול Managed Service for Apache Spark נמצאת במצב של עומס על הזיכרון, התכונה 'הגנה על הזיכרון' של Managed Service for Apache Spark מפסיקה תהליכים או קונטיינרים עד להסרת מצב ה-OOM.

‫Managed Service for Apache Spark מספק הגנה על הזיכרון לצמתי האשכול הבאים בגרסאות התמונות הבאות של Managed Service for Apache Spark:

תפקיד ‫1.5 2.0 ‫2.1 ‫2.2
Master VM 1.5.74+ 2.0.48+ all all
Worker VM לא זמין 2.0.76+ 2.1.24+ all
Driver Pool VM לא זמין 2.0.76+ 2.1.24+ all

זיהוי ואישור של סיום הגנת הזיכרון

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

עיבוד סיום העסקה

  • תהליכים שמופעלת בהם הגנה על הזיכרון ב-Managed Service for Apache Spark מסתיימים עם קוד 137 או 143.

  • כש-Managed Service for Apache Spark מסיים תהליך בגלל עומס על הזיכרון, יכולים לקרות הפעולות או התנאים הבאים:

    • ב-Managed Service for Apache Spark, הערך של dataproc.googleapis.com/node/problem_count המדד המצטבר גדל, והערך של reason מוגדר ל-ProcessKilledDueToMemoryPressure. מידע נוסף זמין במאמר בנושא איסוף מדדי משאבים בשירות Managed Service for Apache Spark.
    • ‫Managed Service for Apache Spark כותב google.dataproc.oom-killer יומן עם ההודעה: "A process is killed due to memory pressure: process name. כדי לראות את ההודעות האלה, מפעילים את רישום היומן ומשתמשים במסנן היומן הבא: 
      resource.type="cloud_dataproc_cluster"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.cluster_uuid="CLUSTER_UUID"
jsonPayload.message:"A process is killed due to memory pressure:"

סגירת עבודות במאגר צמתים של צומת מאסטר או צומת דרייבר

  • כשמשימה של מאגר צמתים ראשיים או מאגר צמתים של מנהל התקן ב-Managed Service for Apache Spark מסתיימת בגלל עומס על הזיכרון, המשימה נכשלת עם קוד השגיאה Driver received SIGTERM/SIGKILL signal and exited with INT. כדי לראות את ההודעות האלה, מפעילים את רישום היומן ומשתמשים במסנן היומן הבא: 

    resource.type="cloud_dataproc_cluster"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.cluster_uuid="CLUSTER_UUID"
jsonPayload.message:"Driver received SIGTERM/SIGKILL signal and exited with"

    • בודקים את היומן google.dataproc.oom-killer או את dataproc.googleapis.com/node/problem_count כדי לוודא ש-Managed Service for Apache Spark Memory Protection הפסיק את העבודה (ראו הפסקת תהליכים).

    פתרונות:

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

סגירת קונטיינרים של YARN בצומת עובד

  • ‫Managed Service for Apache Spark כותב את ההודעה הבאה במנהל המשאבים של YARN: container id exited with code EXIT_CODE. כדי לראות את ההודעות האלה, מפעילים את האפשרות Logging (רישום ביומן) ואז משתמשים במסנן היומן הבא:

    resource.type="cloud_dataproc_cluster"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.cluster_uuid="CLUSTER_UUID"
jsonPayload.message:"container" AND "exited with code" AND "which potentially signifies memory pressure on NODE

  • אם קונטיינר יצא עם code INT, צריך לבדוק את היומן של google.dataproc.oom-killer או את dataproc.googleapis.com/node/problem_count כדי לוודא ש-Managed Service for Apache Spark Memory Protection סיים את העבודה (ראו סיום תהליכים).

    פתרונות:

    • בודקים שהגדרתם את גדלי מאגרי התגים בצורה נכונה.
    • כדאי להקטין את הערך של yarn.nodemanager.resource.memory-mb. המאפיין הזה קובע את נפח הזיכרון שמשמש לתזמון של קונטיינרים של YARN.
    • אם יש כשלים עקביים בקונטיינרים של העבודות, בודקים אם חלוקת נתונים לא מאוזנת גורמת לשימוש מוגבר בקונטיינרים ספציפיים. אם כן, צריך לחלק מחדש את העבודה או להגדיל את גודל העובד כדי להתאים לדרישות הזיכרון הנוספות.

שיפור ההגנה על הזיכרון ב-Linux בצומת הראשי (מתקדם)

בצמתים הראשיים של Managed Service for Apache Spark נעשה שימוש בכלי earlyoom כדי למנוע קריסות של המערכת על ידי שחרור זיכרון כשהזיכרון הזמין נמוך באופן קריטי. הגדרת ברירת המחדל מתאימה לעומסי עבודה רבים. עם זאת, יכול להיות שתצטרכו לשנות את ההגדרות אם לצומת הראשי יש כמות גדולה של זיכרון והוא צורך זיכרון במהירות.

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

לפני שמתחילים

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

התאמה אישית של ההגדרות של earlyoom

ההגדרה שמוגדרת כברירת מחדל ל-earlyoom משתמשת בכמות קבועה של זיכרון פנוי כטריגר. במכונות וירטואליות עם כמות גדולה של זיכרון RAM, למשל 32GB או יותר, הכמות הקבועה הזו עשויה לייצג חלק קטן מנפח הזיכרון הכולל. כך המערכת חשופה לעליות פתאומיות בשימוש בזיכרון.

כדי להתאים אישית את ההגדרות של earlyoom, מתחברים לצומת הראשי ומשנים את קובץ ההגדרות.

  1. מתחברים לצומת הראשי באמצעות SSH.

  2. פותחים את קובץ ההגדרות לעריכה:

    sudo nano /etc/default/earlyoom

  3. לשנות את סף הזיכרון המינימלי. מחפשים את הקו EARLYOOM_ARGS. האפשרות -M <kbytes> מגדירה את הכמות המינימלית של הזיכרון הפנוי ב-KiB ש-earlyoom מנסה לשמור. ערך ברירת המחדל הוא -M 65536, ששווה ל-64 MiB.

    אם יש לכם צומת ראשי עם זיכרון משמעותי, כדאי להגדיל את הערך הזה. לדוגמה, כדי להגדיר את ערך הסף ל-1 GiB (1048576 KiB), משנים את השורה באופן הבא:

    EARLYOOM_ARGS="-r 15 -M 1048576 -s 1"

    הערות:

    • ‫-r: מרווח הדיווח על הזיכרון בשניות
    • -s: ערך הסף של אזור ההחלפה להפעלת earlyoom

  4. מפעילים מחדש את השירות earlyoom כדי שהשינויים ייכנסו לתוקף:

    sudo systemctl restart earlyoom