פתרון בעיות ב-GPU VMs

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

פתרון בעיות במכונות וירטואליות עם GPU באמצעות NVIDIA DCGM

‫NVIDIA Data Center GPU Manager (DCGM) היא חבילת כלים לניהול ולמעקב אחרי יחידות GPU של NVIDIA במרכזי נתונים בסביבות אשכולות.

כדי להשתמש ב-DCGM כדי לפתור בעיות בסביבת ה-GPU, צריך לבצע את הפעולות הבאות:

  • מוודאים שאתם משתמשים בדרייבר NVIDIA המומלץ העדכני ביותר עבור דגם ה-GPU שמחובר למכונה הווירטואלית. כדי לבדוק את גרסאות הדרייבר, אפשר לעיין בגרסאות הדרייבר המומלצות של NVIDIA.
  • מוודאים שהתקנתם את הגרסה האחרונה של DCGM. כדי להתקין את הגרסה העדכנית, אפשר לעיין במאמר בנושא התקנת DCGM.

אבחון בעיות

כשמריצים dcgmi פקודת אבחון, הבעיות שמדווחות בכלי האבחון כוללות את השלבים הבאים לטיפול בבעיה. בדוגמה הבאה אפשר לראות את הפלט שניתן לפעולה מהפקודה dcgmi diag -r memory -j.

{
  ........
   "category":"Hardware",
   "tests":[
      {
         "name":"GPU Memory",
         "results":[
            {
               "gpu_id":"0",
               "info":"GPU 0 Allocated 23376170169
bytes (98.3%)",
               "status":"Fail",
               ""warnings":[
                  {
                     "warning":"Pending page
retirements together with a DBE were detected on GPU 0. Drain the GPU and reset it or reboot the node to resolve this issue.",
                     "error_id":83,
                     "error_category":10,
                     "error_severity":6
                  }
               ]
            }
  .........

מקטע הפלט הקודם אפשר לראות שיש GPU 0 דפים בהמתנה להוצאה משימוש בגלל שגיאה שלא ניתן לתקן. בפלט מופיע הערך הייחודי error_id והמלצות לניפוי באגים של הבעיה. בדוגמה הזו, מומלץ לרוקן את ה-GPU ולהפעיל מחדש את המכונה הווירטואלית. ברוב המקרים, פעולה לפי ההוראות בקטע הזה של הפלט יכולה לעזור לפתור את הבעיה.

פתרון בעיות בביצועים של יחידות GPU במכונות וירטואליות מסוג A3

סדרת המכונות A3 זמינה עם מעבדי GPU של NVIDIA H200 או H100 שמצורפים אליה. הסדרה הזו כוללת את סוגי המכונות A3 Ultra‏ (H200),‏ A3 Mega‏ (H100),‏ A3 High‏ (H100) ו-A3 Edge‏ (H100).

זיהוי צומת פגום

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

הרצת בדיקת ביצועים של NCCL

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

  1. כדי לזהות את קבוצות הצמתים, מקבצים את הצמתים לקבוצות לוגיות, למשל, מחיצות ב-Slurm.
  2. כדי ליצור קובצי hostfile, צריך ליצור קובץ hostfile נפרד לכל קבוצת צמתים, ולציין בו את שמות המארחים ואת מספר יחידות ה-GPU לכל צומת. מספר המשבצות שאתם מציינים תלוי במספר מעבדי ה-GPU בסוג ה-VM שלכם מסוג A3. לדוגמה: למכונות וירטואליות a3-highgpu-8g יש 8 יחידות GPU, ולכן צריך לציין a3-highgpu-8g.slots=8
  3. כדי להריץ בדיקות השוואה, מריצים את all_reduce_perf benchmark מול כל אחד מה-nodeset בנפרד. 
    mpirun -x LD_LIBRARY_PATH --hostfile HOSTFILE_NAME -n TOTAL_PROCESSES \
    ./build/all_reduce_perf -b 1G -e 8G -f 2 -g NUM_GPUS_PER_NODE

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫HOSTFILE_NAME: השם של קובץ המארחים שמכיל את רשימת הצמתים ואת מספר המעבדים הגרפיים לכל צומת עבור קבוצת הצמתים.
    • ‫TOTAL_PROCESSES: המספר הכולל של תהליכי MPI להפעלה בכל המארחים ב-nodeset.
    • ‫NUM_GPUS_PER_NODE: מספר יחידות ה-GPU לכל צומת. לכל סוגי המכונות מסוג A3, הערך הזה הוא 8.
  4. כדי לנתח את התוצאות, אם עבודה נתקעת או שמציגה רוחב פס נמוך משמעותית (busbw) בקבוצת צמתים מסוימת, סביר להניח שיש פגם בקבוצה הזו.
  5. כדי לחלק משנה, אם יש בעיה ב-nodeset, מחלקים את קובץ המארח שלו לשניים ומריצים מחדש את הבדיקה כדי לצמצם את החיפוש הבינארי עד שמאתרים את הצומת הספציפי שמתנהג בצורה לא תקינה.

ניתוח יומני NCCL

אם שיטת ההשוואה לא מצליחה לאתר צומת, צריך לנתח את היומנים המפורטים של NCCL.

  1. כדי להפעיל רישום של ניפוי באגים, מגדירים את משתני הסביבה הבאים בסשן של מעטפת הפקודות שבו מתכננים להריץ את עומס העבודה: 
    export NCCL_DEBUG=INFO
        export NCCL_DEBUG_SUBSYS=INIT,NET,COLL
        export NCCL_DEBUG_FILE="LOG_DIRECTORY/nccl_log.%h.%p"

    מחליפים את LOG_DIRECTORY בספרייה שבה רוצים לאחסן את היומנים.

    ההגדרה NCCL_DEBUG_FILE עם %h ו-%p יוצרת קובצי יומן ייחודיים ולא משולבים לכל תהליך.

    אם מריצים עומס עבודה מרובה צמתים באמצעות mpirun, צריך להפיץ את המשתנים האלה לכל הצמתים באמצעות הדגל -x. For example:

    mpirun -x NCCL_DEBUG -x NCCL_DEBUG_SUBSYS -x NCCL_DEBUG_FILE ...
  2. כדי למצוא את השגיאה הראשונה, משתמשים בפקודה הבאה כדי למצוא את האירועים הכי מוקדמים של זמן קצוב לתפוגה או כשל בכל קובצי היומן: 
    grep "NCCL WARN.*NET/FasTrak" LOG_DIRECTORY/* | sed 's/.*NET\/FasTrak\(.*\)/\1/g' \
  | sort | head -n 20

    מחליפים את LOG_DIRECTORY בספרייה שבה מאוחסנים היומנים.

  3. כדי לספור פעולות קולקטיביות, צומת שנותר מאחור משלים פחות פעולות קולקטיביות. ספירה של "opCount" רשומות לדירוגים של חשודים: 
    grep "opCount" LOG_DIRECTORY/nccl_log.HOSTNAME.PID | wc -l

    מחליפים את מה שכתוב בשדות הבאים:

    • LOG_DIRECTORY: הספרייה שבה שמורים היומנים
    • ‫HOSTNAME: שם המארח של הצומת
    • ‫PID: מזהה התהליך של תהליך NCCL
  4. כדי לאסוף נתוני רישום נוספים לפני שהעבודה מבוטלת, אפשר להגדיל באופן זמני את הזמן הקצוב לתפוגה של העברת הנתונים: 
    export NCCL_FASTRAK_DATA_TRANSFER_TIMEOUT_MS=3600000

מעקב אחרי ויסות נתונים (throttle) של מעבד גרפי (GPU) בגלל חום

יכול להיות שיהיה פגיעה בביצועים של מכונות וירטואליות מסדרת A3 אם הן יגיעו באופן עקבי לטמפרטורות גבוהות מ-87 מעלות צלזיוס בעומס. כדי לבדוק אם יש הגבלת מהירות (throttling) של יחידות ה-GPU בצמתים באשכול, משתמשים בפקודה nvidia-smi או dcgmi.

שימוש ב-nvidia-smi

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

nvidia-smi --query-gpu=timestamp,name,pci.bus_id,temperature.gpu,clocks_throttle_reasons.hw_slowdown --format=csv

בפלט, הערך Active בעמודה clocks_throttle_reasons.hw_slowdown מציין שה-GPU מוגבל בגלל טמפרטורות גבוהות.

שימוש ב-dcgmi

חבילת האבחון NVIDIA Data Center GPU Manager‏ (DCGM) כוללת בדיקות של הפרות שקשורות לטמפרטורה. כדי להריץ אבחון ברמה 1, מריצים את הפקודה הבאה:

dcgmi diag -r 1

תוצאה של Warn או Fail בקטע Thermal מציינת שהתרחשה הפרה של התנאים התרמיים במהלך הבדיקה. אם חריגה תרמית מלווה בהגבלת מהירות השעון, סביר להניח שה-GPU מתחמם יתר על המידה ונדרשת בדיקה נוספת.

שגיאות Xid

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

הודעת Xid היא דוח שגיאה מדרייבר NVIDIA שמופיע ביומן של ליבת מערכת ההפעלה או ביומן האירועים של מכונת ה-VM שלכם ב-Linux. ההודעות האלה ממוקמות בקובץ /var/log/messages. מידע נוסף על הודעות Xid, כולל סיבות אפשריות, זמין במסמכי התיעוד של NVIDIA.

איך Google מטפלת בשגיאות Xid

‫Google משתמשת בבדיקות תקינות פסיביות כדי להעריך מערכות GPU. אם מצוין שיש צורך בהחלפת חומרה, Google תפעיל אוטומטית תחזוקה במקרה חירום. ‫Google מזהה שגיאות Xid ושולחת באופן יזום מכונות לתיקון במקרים שבהם קודי השגיאה מצביעים על סבירות גבוהה לכשל בחומרה, כמו Xid 74,‏ 79 ו-140. במקרים מסוימים, קודי Xid יכולים להיגרם מבעיות בתוכנה או בחומרה, ולכן Google משתמשת בהתאמת תבניות כדי להפעיל תיקונים. לכן, לא כל מקרה מוביל לתיקון אוטומטי.

סוגים של שגיאות Xid

ברשימה הבאה מפורטות שלוש הקטגוריות העיקריות של שגיאות Xid והפעולות המומלצות לתיקון שלהן:

  • שגיאות באפליקציה: שגיאות שמצביעות על בעיות בקוד אפליקציה. שגיאות באפליקציה כוללות Xid כמו Xid 13,‏ 31,‏ 94,‏ 95 ו-137, שמציינים סוגים שונים של הפרות גישה לזיכרון, בדומה לשגיאת פילוח. ההודעות האלה לא מצביעות על שגיאת ECC. כדי לפתור את השגיאות האלה, NVIDIA ממליצה להשתמש באחת משיטות הניפוי הבאות:

    • ניפוי באגים ישיר: מריצים את האפליקציה ישירות ב-cuda-gdb או מריצים את הכלי Compute Sanitizer memcheck.
    • ניפוי באגים אחרי חריגה: מריצים את האפליקציה עם CUDA_DEVICE_WAITS_ON_EXCEPTION=1. כשמתרחש חריג, מנהל ההתקן של ה-GPU מקפיא את מצב האפליקציה בלי לצאת ממנה, כדי שתוכלו לצרף מאוחר יותר מאתר באגים (cuda-gdb -p <PID>) ולבדוק את מעקב המחסנית בזמן אמת.

  • שגיאות בדרייבר: השגיאות האלה מצביעות על בעיות שנגרמות בגלל הדרייבר של NVIDIA GPU. כדי לפתור את השגיאות האלה, צריך לוודא שמשתמשים בגרסה העדכנית ביותר של מנהל ההתקן של NVIDIA. ‫Google עוקבת אחרי השגיאות האלה ומשתפת פעולה עם NVIDIA כדי לתקן את הדרייברים.

  • שגיאות שניתן לתקן בקושחה או בחומרה: שגיאות שמצביעות על בעיות בקושחה או בחומרה, שאפשר לתקן בלי להחליף את החומרה. כדי לפתור את השגיאות האלה, צריך להחיל אמצעי שחזור ידניים, כמו איפוס ה-GPU או הפעלה מחדש של המופע. שגיאות שניתנות לתיקון בתוכנת קושחה או בחומרה כוללות שגיאות של קוד לתיקון שגיאות (ECC) (רלוונטי ל-Xid כמו Xid 48,‏ 63 ו-64) שמצביעות על שלבים שונים של זיהוי שגיאות ECC וצמצום ההשפעה שלהן. מידע נוסף על הוצאה משימוש של דפים ועל צמצום שגיאות ECC זמין בשאלות הנפוצות של NVIDIA בנושא הוצאה משימוש של דפים דינמיים.

בדיקת הודעות Xid

כדי לאבחן במהירות למה עומס העבודה של ה-GPU נכשל, הפסיק להגיב או חווה ירידה בביצועים, כדאי לבדוק את יומני הליבה של המופע (dmesg או /var/log/kern.log) ולחפש קודי שגיאה מספריים של NVIDIA Xid.

הטבלאות הבאות עם שגיאות Xid יעזרו לכם באופן מיידי:

  • זיהוי שורש הבעיה: צריך לזהות אם הכשל נגרם על ידי באג באפליקציה (למשל, גישה לא חוקית לזיכרון), התנגשות בין מנהלי התקנים או תקלה פיזית בחומרה (למשל, שגיאות בזיכרון ECC של שני ביטים).
  • קביעת הבעלות התפעולית: בודקים אילו אמצעי שחזור ידניים מיידיים צריך להחיל, כמו איפוס של יחידות GPU, הפעלה מחדש של מכונות וירטואליות או הפעלת מאתרי באגים, לעומת פעולות תיקון אוטומטיות והחלפת חומרה ש-Google מנהלת באופן פעיל במארח.
  • לנקוט את שלבי השחזור הנכונים: כך תוכלו להימנע מפעולות מיותרות לפתרון בעיות, ולדעת בדיוק מתי שחזור ידני מספיק ומתי צריך לדווח על המארח כפגום. לפעמים, שחזור ידני לא מספיק. למשל, אם מקור השגיאה הוא במטמון של ה-GPU‏ (SRAM), שלא ניתן למפות מחדש, כפי שמצוין על ידי Xid 48 עם SRAM Threshold Exceeded=Yes, או אם ה-GPU מיצה את בנק המיפוי מחדש שלו, כפי שמצוין על ידי Xid 64: All reserved rows for bank are remapped. במקרים כאלה, Google מזהה שה-GPU עומד בדרישות להחלפת חומרה ושולחת את המכונה לתיקון באופן יזום. אם עומסי העבודה שלכם נתקלים בשגיאות חוזרות או אם אתם מבחינים בתקלות חוזרות בזיכרון, אתם יכולים לדווח על המארח הפגום כדי להתחיל תיקון או החלפה אוטומטיים. לגבי GKE, אפשר לקרוא את המאמר איך מדווחים על מארחים פגומים ב-GKE.

טיפול ב-Xid

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

שגיאות בזיכרון ה-GPU

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

שגיאות הזיכרון האלה צפויות להתרחש במהלך חיי השימוש של ה-GPU. לפני השקת מעבדי ה-GPU‏ NVIDIA A100, הייתה תמיכה בהוצאה דינמית משימוש של דפים. במעבדי GPU של NVIDIA A100 ואילך (כמו NVIDIA H100), שחזור שגיאות של מיפוי שורות מוצג עבור שגיאות HBM ‏ (DRAM). ההגדרה ECC מופעלת כברירת מחדל, ו-Google ממליצה מאוד להשאיר אותה מופעלת.

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

הודעת שגיאה של Xid פעולה של לקוח פעולה ב-Google
Xid 48: Double Bit ECC

שגיאת זיכרון כפולה (שלא ניתן לתקן) זוהתה על ידי ECC. השגיאה הזו תמיד קוטעת את עומס העבודה הפועל ויוצרת Xid 48.
  1. מפסיקים את עומסי העבודה.
  2. בהתאם לסביבה שלכם, מאפסים את יחידות ה-GPU או מפעילים מחדש את המכונה הווירטואלית כדי לשחזר את עומסי העבודה ולהמשיך אותם:

‫Google עוקבת אחרי המקרים שבהם ה-GPU עומד בדרישות להחלפת חומרה, למשל אם נגמר המיפוי מחדש של בנק ה-HBM או אם ה-GPU חורג מסף השגיאות של ה-SRAM במהלך מחזור החיים שלו, ושולחת את המכונה לתיקון באופן יזום כדי להחליף את ה-GPU.
Xid 63: ECC page retirement or row remapping recording event

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

‫Google עוקבת אחרי ספי שגיאות ושולחת את המכונה לתיקון כשנדרש תיקון פיזי או החלפה של ה-GPU.
Xid 64: ECC page retirement or row remapper recording failure

ההודעה מכילה את הפרטים הבאים:

Xid 64: All reserved rows for bank are remapped
  1. מפסיקים את עומסי העבודה.
  2. בהתאם לסביבה שלכם, מאפסים את יחידות ה-GPU או מפעילים מחדש את המכונה הווירטואלית כדי לשחזר את עומסי העבודה ולהמשיך אותם:

כשמאגר המיפוי מחדש מתרוקן (All reserved rows for bank are remapped), Google מזהה שה-GPU עומד בדרישות להחלפת חומרה ושולחת את המכונה לתיקון באופן יזום.

אם תקבלו לפחות שתי הודעות Xid מהסוגים הבאים:

  • Xid 48
  • Xid 63
  • Xid 64

ההודעה מכילה את הפרטים הבאים:

Xid XX: row remap pending
  1. מפסיקים את עומסי העבודה.
  2. בהתאם לסביבה שלכם, מאפסים את יחידות ה-GPU או מפעילים מחדש את המכונה הווירטואלית כדי לשחזר את עומסי העבודה ולהמשיך אותם:

‫Google שולחת את המכונה לתיקון אם מאגר המיפוי מחדש מוצה או אם המעבד הגרפי דורש תיקון פיזי או החלפה.
Xid 92: High single-bit ECC error rate הודעת ה-Xid הזו מוחזרת אחרי שהדרייבר של ה-GPU מתקן שגיאה שניתנת לתיקון, והיא לא אמורה להשפיע על עומסי העבודה. ההודעה Xid היא לידיעה בלבד. לא נדרשת כל פעולה מצידך.

ללא
Xid 94: Contained error

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

השגיאה Xid 94 לבדה לא מצביעה על שורש הבעיה, וצריך לפרש אותה יחד עם שגיאות אחרות מסוג Xid שמתרחשות בו-זמנית כדי לקבוע מהי הסיבה הבסיסית.
  1. מכיוון שהשגיאה הייתה באפליקציה אחת, צריך להפעיל מחדש את האפליקציה כדי לשחזר אותה.
  2. אם צריך, מאפסים את מעבדי ה-GPU או מפסיקים את עומסי העבודה.
  3. כדאי לבדוק שגיאות אחרות של Xid שמתרחשות בו-זמנית כדי לקבל שלבים נוספים לשחזור ולקבוע את הסיבה הבסיסית לשגיאה.

ללא
Xid 95: Uncontained error

מציין שקרתה שגיאת GPU שלא הייתה מוגבלת לאפליקציה אחת.

השגיאה Xid 95 לבדה לא מצביעה על שורש הבעיה, וצריך לפרש אותה יחד עם שגיאות Xid אחרות שמתרחשות בו-זמנית כדי לקבוע את הסיבה הבסיסית.
  1. מכיוון שהשגיאה לא נכללה, צריך להפסיק את עומסי העבודה ולאפס את ה-GPU או להפעיל מחדש את המכונה הווירטואלית כדי לשחזר.
  2. כדאי לבדוק שגיאות אחרות של Xid שמתרחשות בו-זמנית כדי לקבוע את שורש הבעיה ולנקוט צעדים נוספים לתיקון.

ללא

שגיאות GSP

מעבד מערכת GPU (GSP) הוא מיקרו-בקר שפועל על יחידות GPU ומטפל בחלק מהפונקציות של ניהול החומרה ברמה נמוכה.

הודעת שגיאה של Xid פעולה של לקוח פעולה ב-Google
Xid 119: GSP RPC timeout
  1. מפסיקים את עומסי העבודה.
  2. כדאי לעיין בענפים מומלצים של מנהלי התקנים (דרייברים) של NVIDIA כדי לוודא שאתם משתמשים בענף נתמך ובגרסה עדכנית או אחרונה של מנהל התקנים, כי באגים במנהלי התקנים בגרסאות קודמות הם גורם מרכזי לשגיאות GSP.
  3. אם השגיאה נמשכת אחרי בדיקה או עדכון של מנהל ההתקן, צריך למחוק את המכונה הווירטואלית וליצור אותה מחדש. אם השגיאה נמשכת, צריך לאסוף את דוח הבאגים של NVIDIA ולפתוח פנייה לCloud Customer Care.

אין. אם השגיאה נמשכת ואתם שולחים בקשת תמיכה, Google בודקת את מצב החומרה או מנהל ההתקן באמצעות תהליך העבודה של התמיכה.
Xid 120: GSP error

שגיאות של גישה לא חוקית לזיכרון

מזהי ה-Xid הבאים מוחזרים כשיש באפליקציות תקלות בגישה לא חוקית לזיכרון:

הודעת שגיאה של Xid פעולה של לקוח פעולה ב-Google

Xid 13: Graphics Engine Exception

Xid 31: GPU memory page fault

Xid 137: Memory access fault

זוהתה הפרה של גישה לזיכרון, בדומה לשגיאת פילוח. השגיאות האלה בדרך כלל מצביעות על באג באפליקציה שבו יש גישה לזיכרון של ה-GPU מחוץ לגבולות, או למאגרי נתונים ששוחררו, כמו ביטול הפניה של מצביע לא תקין או מערך מחוץ לגבולות. השגיאות האלה לא מייצגות שגיאות ECC, אלא אם מופיעה גם שגיאת Xid 48.

כדי לפתור את הבעיה, צריך לנפות באגים בשגיאות הגישה לזיכרון באפליקציה. אפשר להשתמש ב-cuda-gdb, ב-Compute Sanitizer או ב-cuda-memcheck.

פרטים נוספים זמינים במאמרי העזרה של NVIDIA Xid.

אין. במקרים נדירים שבהם שחיקת החומרה עלולה לגרום לדיווח שגוי על שגיאות בגישה לא חוקית לזיכרון, אפשר להשתמש ב-NVIDIA Data Center GPU Manager (DCGM) כדי להריץ את dcgmi diag -r 3 או את dcgmi diag -r 4 לרמות שונות של כיסוי בדיקות ומשך זמן. אם זיהיתם בעיה בחומרה, אתם יכולים לשלוח בקשת תמיכה ל-Customer Care.

הודעות שגיאה נפוצות אחרות של Xid

הודעת שגיאה של Xid פעולה של לקוח פעולה ב-Google
Xid 74: NVLINK error
  1. מפסיקים את עומסי העבודה.
  2. מאפסים את יחידות ה-GPU.

ללא
Xid 79: GPU has fallen off the bus

המשמעות היא שהמנהל לא יכול לתקשר עם ה-GPU כי בעיה בחומרה גרמה ל-GPU להיעלם מאפיק ה-PCI.

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

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

‫Google מזהה שה-GPU יצא מאפיק ה-PCI ושולחת את המכונה לתיקון.
Xid 109: Context switch timeout

שגיאה Xid 109 היא שגיאה כללית שמדווחת על ידי מנהל ההתקן של NVIDIA GPU, שנוצרת כשמופע של GPU לא מצליח לבצע משימות או להחליף משימות בתוך תקופת הזמן הקצובה.

ל-Google יש היסטוריה ארוכה של בדיקת Xid 109 עם NVIDIA, והסיבות הידועות לבאגים בדרייברים תוקנו בדרייברים האחרונים. השגיאה Xid 109 לא נגרמת בגלל בעיה בחומרה.
  1. מפסיקים את עומסי העבודה.
  2. בהתאם לסביבה שלכם, מאפסים את יחידות ה-GPU או מפעילים מחדש את המכונה הווירטואלית כדי לשחזר את עומסי העבודה ולהמשיך אותם:
  3. מומלץ לשדרג לגרסה חדשה יותר של דרייבר NVIDIA בסביבה שלכם, למשל להתקין את הדרייבר האחרון במכונה וירטואלית של Compute Engine או לשדרג את מאגר הצמתים או את DaemonSet של הדרייבר ב-GKE.

ללא
‫Xid 149 שכולל את המילה 0x02a, כמו בדוגמה הבאה: 
Xid (PCI:0000:c0:00): 149,NETIR_LINK_EVT Fatal XC0 i0 Link 04 (0x02a485c6 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000)

ההודעה הזו מצביעה על בעיה מוכרת שמשפיעה על קושחה של מעבדי GPU מסוג NVIDIA B200.
  1. מפסיקים את עומסי העבודה.
  2. מאפסים את יחידות ה-GPU.

ללא

איפוס יחידות GPU

יכול להיות שתצטרכו לאפס את יחידות העיבוד הגרפי (GPU) כדי לפתור בעיות מסוימות. כדי לאפס את יחידות ה-GPU, מבצעים את השלבים הבאים:

  • במכונות וירטואליות מסוג N1,‏ G2,‏ A2 ו-G4 עם יחידת GPU אחת או יותר שמצורפת אליהן, צריך להפעיל מחדש את המכונה הווירטואלית.
  • במכונות וירטואליות מסוג G4 עם יחידות GPU חלקיות (פחות מיחידת GPU אחת מצורפת), צריך לבצע את השלבים הבאים:
    1. מחיקת מכונה וירטואלית
    2. יצירה מחדש של ה-VM.
  • במקרים של מופעי A3,‏ A4,‏ A4X ו-A4X Max, מריצים את הפקודה sudo nvidia-smi --gpu-reset.
    • ברוב מכונות ה-VM של Linux, קובץ ההפעלה nvidia-smi נמצא בספרייה /var/lib/nvidia/bin.
    • בצומתי GKE, קובץ ההפעלה nvidia-smi נמצא בספרייה /home/kubernetes/bin/nvidia.
  • במקרים של מכונות A3,‏ A4,‏ A4X ו-A4X Max בצמתי GKE, אפשר גם להשתמש בכלי לאיפוס GPU כדי לבצע אוטומציה של איפוס כל ה-GPU בצומת. כדי להשתמש בכלי הזה, צריך רק לציין את שם צומת היעד.

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

פתיחת בקשת תמיכה

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

  • מזהה הפרויקט שבו נמצאים המופעים המושפעים.
  • רשימה של כל שמות המופעים או המזהים באשכול.
  • רשימה של צמתים חשודים שזוהו במהלך פתרון הבעיות.
  • יומני NCCL מלאים, לא משולבים עם הגדרות ניפוי באגים מופעלות.
  • פלט מבדיקות תקינות של חומרה (dcgmi, nvidia-smi).
  • פקודת עומס עבודה או מדד השוואה מדויקים שנכשלו.
  • קובצי יומן רלוונטיים, כמו יומני אבחון ומנוע מארח. כדי לאסוף את הנתונים האלה, מריצים את הפקודה gather-dcgm-logs.sh, שנמצאת ב-/usr/local/dcgm/scripts בהתקנות שמוגדרות כברירת מחדל.
  • דיווח על באג ב-NVIDIA. מריצים את nvidia-bug-report.sh. לגבי Blackwell GPUs, צריך לפעול לפי ההוראות במאמר יצירת דוח באגים של NVIDIA עבור Blackwell GPUs.
  • פרטים על שינויים שבוצעו לאחרונה בסביבה לפני הכשל.

המאמרים הבאים

קוראים את המאמר בנושא סוגי מכונות עם GPU.