בעיות מוכרות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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