פתרון בעיות ב-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 לכל קבוצת צמתים בנפרד. 
    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

מעקב אחרי ויסות נתונים (throttle) של מעבד גרפי (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 מתחמם יתר על המידה ונדרשת בדיקה נוספת.

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

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

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

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

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

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

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

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

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

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

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

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

הודעת שגיאה של Xid פתרון
Xid 48: Double Bit ECC
  1. מפסיקים את עומסי העבודה.
  2. מוחקים ויוצרים מחדש את המכונה הווירטואלית. אם השגיאה נמשכת, צריך לפתוח פנייה אל Cloud Customer Care.
Xid 63: ECC page retirement or row remapping recording event
  1. מפסיקים את עומסי העבודה.
  2. מאפסים את יחידות ה-GPU.
Xid 64: ECC page retirement or row remapper recording failure

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

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

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

  • Xid 48
  • Xid 63
  • Xid 64

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

Xid XX: row remap pending
  1. מפסיקים את עומסי העבודה.
  2. מאפסים את יחידות ה-GPU. איפוס ה-GPU מאפשר להשלים את תהליך המיפוי מחדש של השורה והוצאת הדף משימוש, ולתקן את ה-GPU.
Xid 92: High single-bit ECC error rate הודעת ה-Xid הזו מוחזרת אחרי שהדרייבר של ה-GPU מתקן שגיאה שניתנת לתיקון, והיא לא אמורה להשפיע על עומסי העבודה שלכם. ההודעה Xid היא לידיעה בלבד. לא צריך לעשות שום דבר.
Xid 94: Contained ECC error
  1. מפסיקים את עומסי העבודה.
  2. מאפסים את יחידות ה-GPU.
Xid 95: Uncontained ECC error
  1. מפסיקים את עומסי העבודה.
  2. מאפסים את יחידות ה-GPU.

שגיאות GSP

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

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

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

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

  • Xid 13: Graphics Engine Exception
  • Xid 31: GPU memory page fault

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

כדי לפתור את הבעיה, צריך לבצע ניפוי באגים באפליקציה. כדי לנפות באגים באפליקציה, אפשר להשתמש ב-cuda-memcheck וב-CUDA-GDB.

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

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

הודעת שגיאה של Xid פתרון
Xid 74: NVLINK error
  1. מפסיקים את עומסי העבודה.
  2. מאפסים את יחידות ה-GPU.
Xid 79: GPU has fallen off the bus

המשמעות היא שהדרייבר לא יכול לתקשר עם ה-GPU.

 מפעילים מחדש את ה-VM.
‫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 אחד, צריך למחוק וליצור מחדש את המכונה הווירטואלית.
  • למכונות וירטואליות מסוג A3 ו-A4, מריצים את הפקודה sudo nvidia-smi --gpu-reset.
    • ברוב המכונות הווירטואליות של Linux, קובץ ההפעלה nvidia-smi נמצא בספרייה /var/lib/nvidia/bin.
    • בצומתי GKE, קובץ ההפעלה nvidia-smi נמצא בספרייה /home/kubernetes/bin/nvidia.
    • אם אתם משתמשים בצמתי GKE, אתם יכולים להשתמש בכלי לאיפוס GPU כדי לאפס אוטומטית את כל ה-GPU בצומת. כדי להשתמש בכלי הזה, צריך רק לציין את שם צומת היעד.

לחלופין, יחידות ה-GPU מאופסות גם כשמאפסים מכונת VM או כשמפעילים מחדש מכונת VM.

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

אם השגיאה נמשכת אחרי מחיקה ויצירה מחדש, צריך לפתוח פנייה אל Cloud Customer Care כדי להעביר את מכונת ה-VM אל שלב התיקון.

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

קוראים על סוגי מכונות GPU.