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

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

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

כשמתרחשות שגיאות של חוסר זיכרון (OOM) במכונות וירטואליות של Dataproc ב-Compute Engine, ההשפעות כוללות את התנאים הבאים:

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

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

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

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

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

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

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

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

הגנה על הזיכרון ב-Dataproc

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

‫Dataproc מספק הגנה על הזיכרון עבור הצמתים הבאים באשכול בגרסאות התמונות של Dataproc ב-Compute Engine:

תפקיד	1.5	2.0	‫2.1	‫2.2
מכונה וירטואלית ראשית	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

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

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

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

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

• תהליכים שמוגנים על ידי Dataproc מפני שימוש בזיכרון מסתיימים עם הקוד 137 או 143.

• כש-Dataproc מסיים תהליך בגלל עומס על הזיכרון, יכולות להתרחש הפעולות או התנאים הבאים:

  • ‫Dataproc מגדיל את המדד המצטבר dataproc.googleapis.com/node/problem_count ומגדיר את reason לערך ProcessKilledDueToMemoryPressure. מידע נוסף על איסוף מדדים של משאבי Dataproc
  • ‫Dataproc כותב יומן 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:"
    

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

• כשעבודת מאגר צמתים של צומת ראשי או צומת דרייבר של Dataproc מסתיימת בגלל עומס על הזיכרון, העבודה נכשלת עם קוד השגיאה 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"
      

  • כדי לוודא שההגנה על הזיכרון ב-Dataproc הפסיקה את העבודה, בודקים את היומן google.dataproc.oom-killer או את היומן dataproc.googleapis.com/node/problem_count (ראו הפסקת תהליכים).

  פתרונות:

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

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

• ‫Dataproc כותב את ההודעה הבאה במנהל המשאבים של YARN: ‏ container id exited with code EXIT_CODE. כדי לראות את ההודעות האלה, צריך להפעיל את הרישום ביומן ואז להשתמש במסנן היומן הבא:

  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 כדי לוודא שהגנת הזיכרון של Dataproc סיימה את העבודה (ראו סיום תהליכים).

  פתרונות:

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

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

צמתי מאסטר של Dataproc משתמשים בכלי השירות 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.

   שיקולים לגבי כוונון: אם מגדירים את הערך של -M גבוה מדי, יכול להיות ש-earlyoom יסיים תהליכים בצורה אגרסיבית יותר. הדבר הזה יכול להשפיע על אפליקציות גם אם עדיין יש להן מספיק זיכרון. חשוב לעקוב אחרי התנהגות המערכת אחרי שמבצעים שינויים. אפשר להתאים את הערך של -M בהתאם לגודל המופע ולעומס העבודה. הנחיה כללית היא להגדיר את -M לערך שמייצג 1-5% מזיכרון המערכת הכולל.

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

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

   הערות:

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

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

   sudo systemctl restart earlyoom