פתרון בעיות ב-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 בסוג ה-VM של A3. לדוגמה, למכונות וירטואליות מסוג a3-highgpu-8g יש 8 יחידות GPU, ולכן צריך לציין 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. לדוגמה:

    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

מעקב אחרי ויסות נתונים תרמיים של GPU

יכול להיות שהביצועים של מכונות וירטואליות מסדרת A3 ירדו אם הן יגיעו באופן עקבי לטמפרטורות גבוהות מ-87 °C בעומס. כדי לבדוק אם יש הגבלת מהירות (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. מכיוון שהשגיאה לא נכללה, צריך להפסיק את עומסי העבודה (workload) ולאפס את יחידות ה-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.

ללא

פתרון בעיות שקשורות לnvidia-smi אחרי תיקון מערכת ההפעלה או שדרוג הליבה

אם הפקודה nvidia-smi נכשלת עם NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver אחרי חלון זמן לתחזוקה, הפעלת תיקון של מערכת ההפעלה או הפעלה מחדש של המכונה הווירטואלית, צריך לבדוק את ההשהיות של חבילת הליבה. נעילות חבילות מהתקנה קודמת של מנהל התקן במצב binary יכולות למנוע את ההתקנה של כותרות ליבה תואמות.

כדי לאבחן ולפתור את הבעיה, בוחרים את מערכת ההפעלה:

Ubuntu

  1. בודקים את גרסת הליבה הפעילה:

    uname -r

  2. בודקים אם התקנה קודמת של דרייבר במצב binary נעלה את חבילות הליבה, למשל כשמשתמשים ב---force-version, ב---installation-branch=lts או במופעי מחשוב של NVIDIA RTX Virtual Workstation ‏ (vWS):

    apt-mark showhold

    בודקים אם הסמל linux-image-gcp או linux-headers-gcp מופיע ברשימה.

  3. בודקים אם כותרות הליבה מותקנות עבור הליבה הפועלת:

    dpkg -l | grep "linux-headers-$(uname -r)"

  4. אם חבילות המטא של הליבה מושהות, צריך להסיר את נעילות החבילות:

    sudo apt-mark unhold linux-image-gcp linux-headers-gcp

  5. מתקינים את הכותרות של הליבה עבור הליבה הפועלת:

    sudo apt-get update && sudo apt-get install -y linux-headers-$(uname -r)

  6. בונים מחדש את מודול הליבה של NVIDIA וטוענים אותו:

    • אם מקורות מודול DKMS רשומים (מסומן sudo dkms status):

      sudo dkms autoinstall
sudo modprobe nvidia
nvidia-smi

    • אם הפקודה sudo dkms status לא מציגה מודול NVIDIA רשום (לדוגמה, אם הדרייבר הותקן בעבר באמצעות קובץ בינארי .run ללא --dkms), מריצים מחדש את Google Cloud קובץ ההתקנה של דרייבר ה-GPU:

      sudo python3 cuda_installer.pyz install_driver

‫Debian

  1. בודקים את גרסת הליבה הפועלת:

    uname -r

  2. בודקים אם התקנה קודמת של דרייבר במצב binary נעלה את חבילות הליבה, למשל כשמשתמשים ב---force-version, ב---installation-branch=lts או במופעי מחשוב של NVIDIA RTX Virtual Workstation ‏ (vWS):

    apt-mark showhold

    בודקים אם הסמל linux-image-cloud-amd64 או linux-headers-cloud-amd64 מופיע ברשימה.

  3. בודקים אם כותרות הליבה מותקנות עבור הליבה הפועלת:

    dpkg -l | grep "linux-headers-$(uname -r)"

  4. אם חבילות המטא של הליבה מושהות, צריך להסיר את נעילות החבילות:

    sudo apt-mark unhold linux-image-cloud-amd64 linux-headers-cloud-amd64

  5. מתקינים את הכותרות של הליבה עבור הליבה הפועלת:

    sudo apt-get update && sudo apt-get install -y linux-headers-$(uname -r)

  6. בונים מחדש את מודול הליבה של NVIDIA וטוענים אותו:

    • אם מקורות מודול DKMS רשומים (צריך לבדוק את sudo dkms status):

      sudo dkms autoinstall
sudo modprobe nvidia
nvidia-smi

    • אם הפקודה sudo dkms status לא מציגה מודול NVIDIA רשום (לדוגמה, אם הדרייבר הותקן בעבר באמצעות קובץ בינארי .run ללא --dkms), מריצים מחדש את Google Cloud קובץ ההתקנה של דרייבר ה-GPU:

      sudo python3 cuda_installer.pyz install_driver

‫RHEL ו-Rocky Linux

  1. בודקים את גרסת הליבה הפועלת:

    uname -r

  2. בודקים אם התקנה קודמת של דרייבר במצב binary נעלה את חבילות הליבה, למשל כשמשתמשים ב---force-version, ב---installation-branch=lts או במופעי מחשוב של NVIDIA RTX Virtual Workstation ‏ (vWS):

    grep "^exclude=.*kernel" /etc/dnf/dnf.conf

  3. בודקים אם כותרות הליבה מותקנות עבור הליבה הפועלת:

    rpm -qa | grep "kernel-devel-$(uname -r)"

  4. אם חבילות ליבה מוחרגות, צריך להסיר את kernel* מהשורה exclude= בקובץ /etc/dnf/dnf.conf.

  5. מתקינים את הכותרות של הליבה עבור הליבה הפועלת:

    sudo dnf install -y kernel-devel-$(uname -r) kernel-headers-$(uname -r)

  6. בונים מחדש את מודול הליבה של NVIDIA וטוענים אותו:

    • אם מקורות מודול DKMS רשומים (צריך לבדוק את sudo dkms status):

      sudo dkms autoinstall
sudo modprobe nvidia
nvidia-smi

    • אם הפקודה sudo dkms status לא מציגה מודול NVIDIA רשום (לדוגמה, אם הדרייבר הותקן בעבר באמצעות קובץ בינארי .run ללא --dkms), מריצים מחדש את Google Cloud קובץ ההתקנה של דרייבר ה-GPU:

      sudo python3 cuda_installer.pyz install_driver

איפוס יחידות ה-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.