בעיות מוכרות

בדף הזה מתוארות בעיות מוכרות שאולי תיתקלו בהן במהלך השימוש ב-Batch.

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

יכול להיות שב-Pub/Sub לא יישלחו התראות על מצבי ביניים במהלך שינויים מהירים

יכול להיות ש-Pub/Sub לא ישלח התראות על כל מצבי הביניים אם משימה או עבודה משתנות מהר מאוד. לדוגמה, נניח שמשימה משנה במהירות את הסטטוס שלה מ-ASSIGNED, ל-RUNNING ואז ל-FAILED. במקרה כזה, יכול להיות שלא תקבלו התראה שהמשימה הגיעה למצב RUNNING.

כדי לפתור את הבעיה, מומלץ, כשרוצים לראות את היסטוריית המצבים המלאה של עבודה או משימה, לצפות באירועי סטטוס במקום בהתראות Pub/Sub.

מידע נוסף על התראות ב-Pub/Sub זמין במאמר מעקב אחרי סטטוס העבודות באמצעות התראות ב-Pub/Sub וב-BigQuery.

יומני זמן קצוב לתפוגה לא מציינים אם חרגתם מהזמן הקצוב לתפוגה של משימה או של קובץ הפעלה

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

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

1. זיהוי המשימה, הקובץ הניתן להרצה והזמן של כשל עקב חריגה מזמן קצוב לתפוגה.

   1. צפייה ביומנים של המשימה.

   2. מחפשים יומן שבו מוזכר קוד היציאה של חריגה מזמן קצוב לתפוגה, 50005. יומן הרישום הזה כולל textPayload שדומה להודעה הבאה:

      Task task/JOB_UID-group0-TASK_INDEX/0/0 runnable RUNNABLE_INDEX...exitCode 50005
      

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

2. מזהים את שעת ההתחלה של המשימה שנכשלה.

   1. צפייה באירועי הסטטוס של המשימה שנכשלה

   2. מחפשים את אירוע הסטטוס שבו מוזכרת ההודעה הבאה:

      Task state is updated from ASSIGNED to RUNNING
      

      מאירוע הסטטוס הזה, מתעדים את השדה eventTime כשעת ההתחלה של המשימה שנכשלה.

3. כדי לחשב את זמן הריצה הכולל של משימה שנכשלה, \({failedTaskRunTime}\), משתמשים בנוסחה הבאה:

   \[{failedTaskRunTime}={failureTime}-{failedTaskStartTime}\]

   מחליפים את הערכים הבאים:

   • ‫\({failureTime}\): השעה שבה התרחשה השגיאה של חריגה מזמן הקצוב לתפוגה.
   • ‫\({failedTaskStartTime}\): שעת ההתחלה של המשימה שנכשלה.

4. מזהים את הזמן הקצוב לתפוגה שחורג מהמגבלה:

   • אם \({failedTaskRunTime}\) תואם לזמן הקצוב לתפוגה שהגדרתם למשימה שנכשלה, סימן שזמן הקצוב לתפוגה של המשימה הזו חלף והוא גרם לכשל.

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

יכול להיות שיהיה עיכוב בעבודות שצורכות הזמנות או שהן לא יתבצעו

כשמנסים ליצור ולהריץ משימה שצורכת הזמנות ב-Compute Engine, יכול להיות ש-Batch יעכב את הרצת המשימה או ימנע אותה בטעות. באופן ספציפי, Batch דורש שלפרויקטים יהיו מכסות מספיקות של משאבי Compute Engine גם אם המכסות האלה משמשות להזמנות שלא נוצלו.

מידע נוסף על הבעיה הזו:

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

זיהוי הבעיה והבנתה

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

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

  לדוגמה, נניח שהפרויקט שלכם כולל את הדברים הבאים:

  • מכסת מקסימום של 16 מעבדי H100 GPU.
  • מקום שמור שלא נוצל בפרויקט יחיד ל-2 מכונות וירטואליות a3-highgpu-8g, שכולל 16 מעבדי H100 GPU.

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

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

  לדוגמה, נניח שהפרויקט שלכם כולל את הדברים הבאים:

  • מכסת מקסימום של 16 מעבדי H100 GPU.
  • הזמנה שלא נוצלה בפרויקט יחיד של מכונה וירטואלית אחת a3-highgpu-8g, שכוללת 8 יחידות GPU מסוג H100.
  • מכונה וירטואלית a3-highgpu-8g שמוגדרת לא לצרוך הזמנות ונמחקת מדי פעם ואז נוצרת מחדש. (המכונה הווירטואלית הזו משתמשת ב-8 יחידות GPU מסוג H100 שלא הוזמנו מראש, אם היא קיימת).

  בתרחיש הזה, הבעיה מאפשרת לפרויקט לתזמן ולהתחיל להריץ כל עבודה שהוגדרה בצורה נכונה לצריכת כל אחד מהמעבדים הגרפיים מסוג H100 שהוזמנו, אם מכונת ה-VM‏ a3-highgpu-8g לא קיימת.

פתרון עקיף לבעיה

כדי לפתור את הבעיה הזו עבור משימה, מוסיפים תווית עם השם goog-batch-skip-quota-check והערך true לשדה job-level labels. התווית הזו גורמת ל-Batch לדלג על אימות מכסות המשאבים של הפרויקט לפני ניסיון ליצור עבודה.

חשוב: לא מומלץ להפעיל את התווית goog-batch-skip-quota-check למשימות שלא יכולות לצרוך הזמנות בפרויקט. לדוגמה, לא מומלץ להשתמש בפתרון העקיף הזה אם בפרויקט אין שמירת מקום ב-Compute Engine או אם נדרשות למשימה מכונות וירטואליות שלא תואמות לשמירת המקום. אחרת, אם משימות מדלגות על בדיקות מכסה שלא לצורך, יכול להיות שתראו כשלים של מכסה לא מספקת שלא לצורך.

לדוגמה, כדי למנוע את הבעיה הזו או לפתור אותה עבור משימת סקריפט בסיסית שיכולה לצרוך הזמנות, יוצרים ומריצים משימה עם הגדרת ה-JSON הבאה:

{
  "taskGroups": [
    {
      "taskSpec": {
        "runnables": [
          {
            "script": {
              "text": "echo Hello world from task ${BATCH_TASK_INDEX}"
            }
          }
        ]
      },
      "taskCount": 3
    }
  ],
  "allocationPolicy": {
    "instances": [
      {
        VM_RESOURCES
      }
    ],
  },
  "labels": {
    "goog-batch-skip-quota-check": "true"
  },
  "logsPolicy": {
    "destination": "CLOUD_LOGGING"
  }
}

מחליפים את VM_RESOURCES במשאבי המכונה הווירטואלית שתואמים להזמנה שרוצים שהעבודה תשתמש בה.

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

יכול להיות שהמשימות ייכשלו כשמציינים תמונות של מערכת הפעלה של מכונות וירטואליות (או מותאמות אישית) ב-Compute Engine עם ליבות מיושנות

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

מידע נוסף על הבעיה הזו:

הערה: אם העבודה שלכם משתמשת ביחידות GPU, כדאי לעיין גם במאמר Jobs using GPUs and VM OS images with outdated kernels fail only when automatically installing drivers.

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

זיהוי הבעיה והבנתה

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

הבעיה הזו יכולה לקרות בכל שלב, גם אם משתמשים בגרסה העדכנית ביותר של תמונה ב-Compute Engine. אם מערכת הפעלה עודכנה לאחרונה, במיוחד אם מדובר בעדכונים בלתי צפויים כמו תיקונים מהירים – עדכונים דחופים לפרצות אבטחה או לבעיות קריטיות – יכול להיות שתמונות של מערכת הפעלה של מכונות וירטואליות ב-Compute Engine עדיין לא הגיבו לשינויים. לדוגמה, שמנו לב שבמערכת ההפעלה Debian, תיקוני אבטחה יכולים להסיר מהליבה חבילות עם קידומות linux-headers- באופן בלתי צפוי.

כדי לזהות את הבעיה הזו, מומלץ לצפות ביומנים של העבודה כדי לבדוק אם יש שגיאות בהתקנה שקשורות לתמונת מערכת ההפעלה של מכונת ה-VM. לדוגמה, אם העבודה שלכם משתמשת בתמונה של Debian Compute Engine או בתמונה מותאמת אישית דומה, מומלץ לבדוק אם יש שגיאות שקשורות להתקנת חבילות linux-headers- באמצעות השאילתה הבאה:

labels.job_uid="JOB_UID" AND severity="ERROR" AND textPayload:("failed" "apt" "install" "linux-headers-")

מחליפים את JOB_UID במזהה הייחודי (UID) של המשימה. כדי לקבל את ה-UID של משרה, מתארים את המשרה. אם השאילתה הזו מחזירה תוצאות, יכול להיות שהבעיה הזו משפיעה על העבודה שלכם.

פתרון עקיף לבעיה

כדי למנוע את הבעיה הזו או לפתור אותה, מומלץ לבצע את הפעולות הבאות:

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

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

3. בוחרים אחת מהאפשרויות האלה:

   • אפשר לנסות מערכת הפעלה אחרת או ליצור תמונה בהתאמה אישית. לדוגמה, אם הגרסה האחרונה של Debian 12 לא פועלת, אפשר לנסות ליצור תמונה בהתאמה אישית ממכונת VM של Compute Engine שמופעלת באמצעות Debian 12 ועודכנה לשימוש בגרסת הליבה האחרונה.

   • אם העבודה נכשלת בגלל שגיאות שקשורות להתקנת חבילות linux-headers-, אפשר לנסות להשתמש בתמונת מערכת ההפעלה של המכונה הווירטואלית עם חבילות linux-headers- לא עדכניות. כדי לאפשר חבילות linux-headers- מיושנות, מוסיפים תווית עם השם goog-batch-allow-insecure-linux-headers-installation והערך true לשדה job-level labels.

     זהירות: הפעלת התווית goog-batch-allow-insecure-linux-headers-installation היא באחריותכם בלבד. התווית הזו מאפשרת לעבודת הגיבוי לנסות להתקין ולהשתמש בחבילות linux-headers- שנשמרו בארכיון. החבילות לא עדכניות, ולכן הן עלולות להיות לא מאובטחות ולחשוף את המשרה לפגיעויות או שלא לכלול עדכונים קריטיים.

     לדוגמה, כדי לאפשר חבילות linux-headers- לא עדכניות למשימת סקריפט בסיסית שמציינת תמונת מערכת הפעלה של מכונה וירטואלית, יוצרים ומריצים משימה עם הגדרת ה-JSON הבאה:

     {
       "taskGroups": [
         {
           "taskSpec": {
             "runnables": [
               {
                 "script": {
                   "text": "echo Hello world from task ${BATCH_TASK_INDEX}"
                 }
               }
             ]
           },
           "taskCount": 3
         }
       ],
       "allocationPolicy": {
         "instances": [
           {
             "policy": {
               "bootDisk": {
                 "image": "VM_OS_IMAGE_URI"
               }
             }
           }
         ]
       },
       "labels": {
         "goog-batch-allow-insecure-linux-headers-installation": "true"
       },
       "logsPolicy": {
         "destination": "CLOUD_LOGGING"
       }
     }
     

     מחליפים את VM_OS_IMAGE_URI במזהה המשאבים האחיד (URI) של תמונת מערכת ההפעלה של המכונה הווירטואלית שבה רוצים להשתמש.

     הוראות נוספות זמינות במאמרים בנושא הגדרת תוויות בהתאמה אישית למשימה וציון תמונת מערכת ההפעלה של מכונת ה-VM למשימה.

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

יכול להיות שמשימות שמשתמשות ב-GPU ובדימויים של מערכת הפעלה של מכונות וירטואליות עם ליבות לא מעודכנות ייכשלו רק כשמתקינים דרייברים באופן אוטומטי

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

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