בעיות מוכרות

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

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

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

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

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

זיהוי הבעיה

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

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

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

    • מכסת מקסימום של 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 לא קיימת.

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

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

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

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

  1. אם אפשר, כדאי להשתמש בתמונות בכמות גדולה או בתמונות מותאמות אישית שמבוססות על תמונות בכמות גדולה, כי הן לא מושפעות מהבעיה הזו.
  2. אם אי אפשר להשתמש בתמונה של Batch, נסו להשתמש בגרסה האחרונה של תמונת Compute Engine המועדפת. בדרך כלל, בגרסאות חדשות יותר של תמונות Compute Engine יש סיכוי גבוה יותר לגרסת ליבה עדכנית מאשר בגרסאות ישנות יותר.
  3. אם הגרסה העדכנית של תמונה מסוימת לא פועלת, יכול להיות שתצטרכו לנסות מערכת הפעלה אחרת או ליצור תמונה בהתאמה אישית. לדוגמה, אם הגרסה האחרונה של Debian 12 לא פועלת, אפשר לנסות ליצור תמונה בהתאמה אישית ממכונת VM ב-Compute Engine שמופעלת בה Debian 12 ושעדכנתם אותה לשימוש בגרסת הליבה האחרונה.

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

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

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

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

מידע נוסף על יחידות GPU זמין במאמר יצירה והפעלה של משימה שמשתמשת ביחידות GPU.