"Managed Service for Apache Spark" is the new name for the product formerly known as "Dataproc on Compute Engine" (cluster deployment) and "Google Cloud Serverless for Apache Spark" (serverless deployment).

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

בדף הזה מוסבר על שגיאות של חוסר זיכרון (OOM) במכונה וירטואלית של Compute Engine בשירות המנוהל ל-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
מכונה וירטואלית ראשית	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 הפסיק את העבודה (ראו Process terminations).
פתרונות:
- אם לאשכול יש מאגר של מנהלי התקנים, צריך להגדיל את 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, מתחברים לצומת הראשי ומשנים את קובץ ההגדרות.

מתחברים לצומת הראשי באמצעות SSH.
פותחים את קובץ ההגדרות לעריכה:
```
sudo nano /etc/default/earlyoom
```
משנים את סף הזיכרון המינימלי. מאתרים את השורה 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
מפעילים מחדש את השירות earlyoom כדי להחיל את השינויים:
```
sudo systemctl restart earlyoom
```