מעקב אחרי מכונות Compute Engine ואשכולות Slurm

במאמר הזה מוסבר איך להשתמש במרכזי הבקרה של Cloud Monitoring כדי לעקוב אחרי מכונות A4X Max,‏ A4X,‏ A4,‏ A3 Ultra ו-A3 Mega שיצרתם באמצעות קיבולת שמוגבלת להזמנה. בעזרת מרכזי הבקרה האלה תוכלו לזהות ולפתור צווארי בקבוק בביצועים במכונות העצמאיות של Compute Engine או באשכולות Slurm, וכך לצמצם את זמני ההשבתה בעומסי העבודה.

אתם יכולים ליצור לוחות בקרה בהתאמה אישית או להשתמש בלוחות בקרה מוכנים מראש של Monitoring כדי לעקוב אחרי:

  • תקינות המכונה

  • ביצועי ה-GPU

  • יעילות השידור ברשת

  • יעילות הרשת בין בלוקים ובלוקי משנה

  • יעילות עומס העבודה של למידת מכונה (ML)

  • זיהוי משימות איטיות

  • זיהוי עומסי עבודה שלא מגיבים

כדי לעקוב אחרי אשכולות ב-Cluster Director, קראו את המאמר מעקב אחרי ביצועי האשכולות באמצעות לוחות בקרה מוכנים מראש.

לפני שמתחילים

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

כשמשתמשים במסוף Google Cloud כדי לגשת לשירותים ולממשקי ה-API של Google Cloud , לא צריך להגדיר אימות.

מגבלות

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

    • צריך ליצור את המכונות כמכונות Compute Engine עצמאיות או כחלק מאשכול Slurm.
    • המכונות צריכות להיווצר באמצעות קיבולת שקשורה להזמנה.
    • המכונות צריכות להיות מסדרת המכונות A4X Max,‏ A4X,‏ A4,‏ A3 Ultra או A3 Mega.
      • עם זאת, זיהוי חריגים נתמך גם במכונות וירטואליות (VM) מסדרת המכונות A3 Mega.

כדי לעקוב אחרי מדדי עומסי העבודה של למידת המכונה, צריך להגדיר מעקב אחרי עומסי העבודה.

מגבלות בזיהוי משימות איטיות

למדדים של זיהוי משימות איטיות יש את המגבלות הנוספות הבאות:

  • בסדרות מכונות נתמכות שאינן A3 Mega, זיהוי חריגים תומך רק במכונות שמאפשרות לספריית Collective Communication Analyzer‏ (CoMMA) לייצא נתוני טלמטריה של NCCL לשירותי Google Cloud . מידע נוסף מופיע במאמר סקירה כללית על CoMMA.
  • בדרך כלל, דיווח על משימה איטית באמצעות זיהוי משימות איטיות נמשך עד 10 דקות.
  • בניגוד למדדים האחרים במסמך הזה, אי אפשר לסנן את מדדי הזיהוי של משימות איטיות בפרויקטים לפי אשכול, בלוק, בלוק משנה או מכונה. עם זאת, אפשר לסנן שאילתות של יומני זיהוי של משימות איטיות לפי המזהה של מכונה אחת או יותר שחשודות כמשימות איטיות.

מגבלות בזיהוי עומסי עבודה שלא מגיבים

מדדי הזיהוי של עומסי עבודה שלא מגיבים תומכים רק במכונות שמשתמשות בספריית Collective Communication Analyzer‏ (CoMMA) כדי לייצא נתוני טלמטריה של NCCL לשירותי Google Cloud . מידע נוסף מופיע במאמר סקירה כללית על CoMMA.

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות למעקב אחרי מדדים של עומסי עבודה ב-AI Hypercomputer, בקשו מהאדמין להקצות לכם את התפקידים הבאים ב-IAM:

  • כדי לצפות במדדים ב-Cloud Monitoring: עריכת מעקב (roles/monitoring.editor) בפרויקט
  • כדי לצפות ביומני זיהוי המשימות האיטיות ב-Logging: צפייה ביומנים (roles/logging.viewer) בפרויקט

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

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

ההרשאות הנדרשות

כדי לעקוב אחרי מדדים של עומסי עבודה ב-AI Hypercomputer, צריך את ההרשאות הבאות:

  • כדי לצפות במרכזי הבקרה: monitoring.dashboards.get בפרויקט
  • כדי ליצור מרכזי בקרה: ‫monitoring.dashboards.create בפרויקט
  • כדי לראות את רשומות היומן: logging.logEntries.list בפרויקט

יכול להיות שתקבלו את ההרשאות האלה באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש אחרים.

המדדים הזמינים

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

בקטע הצגת מדדים מוסבר איך להציג את המדדים האלה.

מדדי תשתית

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

סקירה כללית של המדדים שזמינים ב-Compute EngineGoogle Cloud

מדדי תקינות של ה-GPU

כדי לעקוב אחרי התקינות של ה-GPU, אתם יכולים להשתמש במדדים הבאים:

שם סוג מדד סדרות מכונות נתמכות תיאור
סטטוס המכונה machine/machine_status ‫A4X Max,‏ A4X,‏ A4,‏ A3 Ultra או A3 Mega אם המכונה שבה משתמשים תקינה או לא תקינה וצריך לתקן אותה.
סטטוס NVSwitch instance/gpu/nvswitch_status ‫A4X Max,‏ A4X,‏ A4,‏ A3 Ultra או A3 Mega אם יש בעיות ב-NVLink Switch ב-GPU של NVIDIA שמחובר למכונה.
תקינות התשתית של ה-VM instance/gpu/infra_health ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega תקינות האשכול, הבלוק, תת-הבלוק והמארח שבהם פועלות המכונות. אם המדד הזה מראה שהתשתית של מכונה לא תקינה, הוא גם מתאר את הבעיה.
ציון חיזוי הכשל של המכונה הווירטואלית instance/gpu/failure_prediction_score ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega הסבירות שהמארח שבו פועלת המכונה יתדרדר בחמש השעות הבאות. הערך יכול להיות בין 0.0 ל-1.0. ככל שהערך נשאר קרוב יותר ל-1.0 לאורך זמן, כך גדל הסיכוי שהביצועים של המכונה ירדו. במקרה כזה, מומלץ להעביר את המשימה למכונה אחרת. אם נתקלים בבעיות במכונה, צריך לדווח על המארח שלה כפגום.

מדדי ביצועים של GPU

כדי לעקוב אחרי הביצועים של ה-GPU, אתם יכולים להשתמש במדדים הבאים:

שם סוג מדד סדרות מכונות נתמכות תיאור
שימוש מצטבר בהקשר instance/gpu/accumulated_context_utilization_seconds ‫A4X Max,‏ A4X,‏ A4,‏ A3 Ultra או A3 Mega משך הזמן הכולל, בשניות, שבו ה-GPU עסוק בעיבוד עומס עבודה.
צריכת החשמל של ה-GPU instance/gpu/power_consumption ‫A4X Max,‏ A4X,‏ A4,‏ A3 Ultra או A3 Mega ההספק בוואט (W) ובערכים עשרוניים שנצרך על ידי יחידות GPU נפרדות במארח. במכונות שמחוברים אליהן כמה מעבדים גרפיים, המדד מספק את צריכת החשמל בנפרד לכל מעבד גרפי במארח.
ניצול SM instance/gpu/sm_utilization ‫A4X Max,‏ A4X,‏ A4,‏ A3 Ultra או A3 Mega ערך שאינו אפס מציין שנעשה שימוש פעיל בבלוקי ה-SM ‏(Streaming Multiprocessor) במעבדים הגרפיים.
טמפרטורת ה-GPU instance/gpu/temperature ‫A4X Max,‏ A4X,‏ A4,‏ A3 Ultra או A3 Mega הטמפרטורה במעלות צלזיוס (℃) ובערכים עשרוניים של יחידות GPU נפרדות במארח. במכונות שמחוברים אליהן כמה מעבדים גרפיים, המדד מספק את הטמפרטורה בנפרד לכל מעבד גרפי במארח.
מרווח תרמי של ה-GPU instance/gpu/tlimit ‫A4X Max,‏ A4X,‏ A4,‏ A3 Ultra או A3 Mega ההפרש בין הטמפרטורה הנוכחית לטמפרטורה המקסימלית של כל GPU במעלות צלזיוס (℃) ובערכים עשרוניים, לפני שצריך להאט את הפעילות שלו בגלל טמפרטורה גבוהה. במכונות עם כמה מעבדים גרפיים, המדד מספק את המרווח התרמי בנפרד לכל מעבד גרפי במארח.

מדדי ביצועים של רשת GPU

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

שם סוג מדד סדרות מכונות נתמכות תיאור
שינויים בקישור לספק instance/gpu/link_carrier_changes ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega התדירות שבה ספק הקישור לרשת משתנה בדקה.
זמן הלוך ושוב (RTT) ברשת instance/gpu/network_rtt ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega זמן הלוך ושוב, שנמדד במיקרו-שניות, של נתוני רשת שעוברים בין מקור ליעד.
תנועה ברשת בין בלוקים instance/gpu/network/inter_block_tx ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega מספר הבייטים של תנועה ברשת בין בלוקים.
תנועה ברשת בין בלוקי משנה instance/gpu/network/inter_subblock_tx ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega מספר הבייטים של התנועה ברשת בין בלוקי המשנה.
תנועה ברשת בתוך בלוק משנה instance/gpu/network/intra_subblock_tx ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega מספר הבייטים של תנועה ברשת בתוך בלוק משנה אחד.
מהירות פעילה של NVLink instance/gpu/nvlink_active_speed ‫A4X Max,‏ A4X,‏ A4,‏ A3 Ultra או A3 Mega מהירות היציאה של קישור הגישה הנוכחי, ב-GBps.
בייטים של תפוקת Rx instance/gpu/throughput_rx_bytes ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega מספר הבייטים שהתקבלו מהתנועה ברשת.
בייטים של תפוקת Tx instance/gpu/throughput_tx_bytes ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega מספר הבייטים שהועברו לתנועה ברשת.

מדדי מתג ToR

באשכולות A4X Max ו-A4X, אתם יכולים לעקוב אחרי נתוני הטלמטריה של מתג הרשת ToR בקצה העורפי כדי לבצע את הפעולות הבאות במהלך אימון מבוזר של למידת מכונה:

  • לבדוק את תקינות המתג והיציאה.
  • בודקים את קיבולת רוחב הפס הזמינה ואת עומק התור במאגר הנתונים הזמני (buffer queue).
  • אבחון של חבילות שנמחקו, שגיאות, שינויים תכופים בממשק ואירועים של ניהול עומסים.

המדדים האלה משתמשים בסוג המשאב במעקב compute.googleapis.com/NetworkSwitch ובקידומת של סוג המדד compute.googleapis.com/. ב-Metrics Explorer, בוחרים את סוג המשאב NetworkSwitch (compute.googleapis.com/NetworkSwitch).

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

החלפת מדדי התקינות והסטטוס

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

  • בודקים את סטטוס הפעילות של יציאות המתג.
  • מעקב אחרי ניצול המעבד (CPU) וניצול הזיכרון של המתג.
  • בודקים את זמני ההפעלה כדי לזהות הפעלות מחדש לא צפויות.
שם סוג מדד סדרות מכונות נתמכות תיאור
סטטוס הניוד network_switch/port_status ‫A4X Max או A4X מציין את סטטוס הפעילות של הממשק הפיזי (יציאה) במתג הרשת. ערך המדד הוא תמיד 1 לצבירה. המצב בפועל מופיע בתווית status (למשל UP או DOWN).
תוויות עיקריות: port_identifier, status, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
ניצול יחידת העיבוד המרכזית (CPU) network_switch/cpu_utilization ‫A4X Max או A4X ניצול המעבד (CPU) של מתג הרשת, נמדד כשבר מ-0.0 עד 1.0.
תוויות מפתח: subblock_id,‏ block_id,‏ reservation_id,‏ switch_type.
זיכרון בשימוש network_switch/memory_used ‫A4X Max או A4X הזיכרון שמתג הרשת משתמש בו, בבייטים.
תוויות מפתח: subblock_id,‏ block_id,‏ reservation_id,‏ switch_type.
סה"כ זיכרון network_switch/total_memory_bytes ‫A4X Max או A4X נפח הזיכרון הכולל של מתג הרשת, בבייטים.
תוויות מפתח: subblock_id,‏ block_id,‏ reservation_id,‏ switch_type.
זמן האתחול network_switch/boot_time_in_ns ‫A4X Max או A4X חותמת הזמן של הפעלת מתג הרשת, בננו-שניות מאז ראשית זמן יוניקס (Unix epoch).
תוויות מפתח: subblock_id,‏ block_id,‏ reservation_id,‏ switch_type.
מעבר בין מדדי קיבולת ומדדי תור

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

שם סוג מדד סדרות מכונות נתמכות תיאור
קיבולת בסיסית network_switch/baseline_capacity_kbps ‫A4X Max או A4X קיבולת רוחב הפס הפוטנציאלית הכוללת של חיבור מתג ToR לבלוק-העל, בקילו-ביט לשנייה (kbit/s).
תוויות מפתח: subblock_id,‏ block_id,‏ reservation_id,‏ switch_type.
קיבולת אפקטיבית network_switch/effective_capacity_kbps ‫A4X Max או A4X קיבולת התפעול השימושית של חיבור מתג ToR לבלוק-העל, בקילו-ביט לשנייה (kbit/s). המדד הזה משקף הפחתות בקיבולת שנגרמו בגלל קישורים לא תקינים או קישורים במצב אופליין.
תוויות מפתח: subblock_id,‏ block_id,‏ reservation_id,‏ switch_type.
עומק התור המקסימלי של תעבורת נתונים יוצאת network_switch/egress_max_queue_depth ‫A4X Max או A4X עומק התור המקסימלי שנצפה במהלך מחזור המדידה האחרון.
תוויות מפתח: port_identifier,‏ queue_name,‏ subblock_id,‏ block_id,‏ reservation_id,‏ switch_type.
השלכות של תורים בתעבורת נתונים יוצאת (egress) network_switch/egress_queue_drops_count ‫A4X Max או A4X המספר המצטבר של חבילות שהושמטו מתורי היציאה בגלל עומס בתור או ניצול מלא של המאגר.
תוויות מפתח: port_identifier,‏ queue_name,‏ subblock_id,‏ block_id,‏ reservation_id,‏ switch_type.
השלכות של מאגר נתונים זמני נכנס network_switch/in_buffer_discards ‫A4X Max או A4X המספר המצטבר של חבילות נכנסות שנמחקו בכניסה בגלל גלישת מאגר נתונים (buffer overflow).
תוויות מפתח: port_identifier,‏ peer_target_identifier,‏ peer_port_identifier,‏ subblock_id,‏ block_id,‏ reservation_id,‏ switch_type.
מדדים של ניתוקים, שגיאות ובקרת זרימה במתג

אתם יכולים להשתמש במדדים שבקטע הזה כדי לאבחן את הבעיות הבאות, שעלולות לגרום לעיכובים באימון מבוזר או לזמן קצוב לתפוגה של תקשורת קולקטיבית (כמו זמן קצוב לתפוגה של NCCL watchdog):

  • מנות שנזרקו, שגיאות שידור ושינויים במצב הקישור הפיזי.
  • שגיאות במילים בתיקון שגיאות מראש (FEC).
  • אירועים של ניהול עומסים, כמו השהיות של בקרת זרימה מבוססת-עדיפות (PFC) וסימונים של הודעות עומס מפורשות (ECN).
שם סוג מדד סדרות מכונות נתמכות תיאור
תנודות בממשק network_switch/interface_flaps_count ‫A4X Max או A4X המספר המצטבר של מעברי מצב של קישור פיזי (תנודות בין UP ל-DOWN) בממשק של יציאת המתג.
תוויות מפתח: port_identifier,‏ subblock_id,‏ block_id,‏ reservation_id,‏ switch_type.
שגיאות במילים ב-FEC network_switch/fec_word_error_count ‫A4X Max או A4X המספר המצטבר של שגיאות במילים של תיקון שגיאות מראש (FEC). משתמשים בתווית הבוליאנית correctable (true או false) כדי להבחין בין שגיאות שניתן לתקן לשגיאות שלא ניתן לתקן.
תוויות מפתח: port_identifier,‏ correctable,‏ subblock_id,‏ block_id,‏ reservation_id,‏ switch_type.
חבילות שסומנו ב-ECN network_switch/ecn_marked_packets_count ‫A4X Max או A4X המספר המצטבר של חבילות שסומנו בביטים של Explicit Congestion Notification (ECN) בגלל חריגה מסף המאגר.
תוויות מפתח: port_identifier,‏ subblock_id,‏ block_id,‏ reservation_id,‏ switch_type.
מנות PFC שהתקבלו network_switch/pfc_rx_packets_count ‫A4X Max או A4X המספר המצטבר של מסגרות ההשהיה של בקרת זרימה מבוססת-עדיפות (PFC) שהתקבלו ביציאה.
הערה: רלוונטי רק לסביבות ייעודיות שבהן מופעלת בקרת זרימה מבוססת-עדיפות (PFC).
תוויות מפתח: port_identifier,‏ priority_index,‏ subblock_id,‏ block_id,‏ reservation_id,‏ switch_type.
מנות PFC TX network_switch/pfc_tx_packets_count ‫A4X Max או A4X המספר המצטבר של מסגרות השהיה של בקרת זרימה מבוססת-עדיפות (PFC) שנשלחו מהיציאה כדי לווסת את התנועה הנכנסת.
הערה: רלוונטי רק לסביבות ייעודיות שבהן מופעלת התכונה PFC.
תוויות מפתח: port_identifier,‏ queue_name,‏ subblock_id,‏ block_id,‏ reservation_id,‏ switch_type.
חבילות QoS tx network_switch/qos_tx_packets ‫A4X Max או A4X המספר המצטבר של חבילות הנתונים של איכות השירות (QoS) שהועברו בתור שצוין.
תוויות מפתח: port_identifier,‏ queue_name,‏ subblock_id,‏ block_id,‏ reservation_id,‏ switch_type.
מספר חבילות הנתונים הנכנסות network_switch/in_packets_count ‫A4X Max או A4X המספר המצטבר של חבילות נתונים נכנסות שהתקבלו ביציאת המתג.
תוויות מפתח: port_identifier,‏ subblock_id,‏ block_id,‏ reservation_id,‏ switch_type.
בשגיאות network_switch/in_errors ‫A4X Max או A4X המספר המצטבר של חבילות נתונים נכנסות שהתקבלו עם שגיאות שמנעו את המסירה שלהן.
תוויות מפתח: port_identifier,‏ peer_target_identifier,‏ peer_port_identifier,‏ subblock_id,‏ block_id,‏ reservation_id,‏ switch_type.
בפריטים שנמחקו network_switch/in_discards ‫A4X Max או A4X המספר המצטבר של חבילות נתונים נכנסות תקינות שנמחקו (לדוגמה, בגלל שאין מספיק מקום במאגר הנתונים).
תוויות מפתח: port_identifier,‏ peer_target_identifier,‏ peer_port_identifier,‏ subblock_id,‏ block_id,‏ reservation_id,‏ switch_type.
שגיאות ביציאה network_switch/out_errors ‫A4X Max או A4X המספר המצטבר של חבילות יוצאות שלא נשלחו בגלל שגיאות.
תוויות מפתח: port_identifier,‏ peer_target_identifier,‏ peer_port_identifier,‏ subblock_id,‏ block_id,‏ reservation_id,‏ switch_type.
חבילות שנמחקו ביציאה network_switch/out_discards ‫A4X Max או A4X המספר המצטבר של חבילות נתונים יוצאות שנבחרו למחיקה, למרות שלא זוהו שגיאות.
תוויות מפתח: port_identifier,‏ peer_target_identifier,‏ peer_port_identifier,‏ subblock_id,‏ block_id,‏ reservation_id,‏ switch_type.
מספר הבייטים הנכנסים network_switch/in_bytes_count ‫A4X Max או A4X המספר המצטבר של בייטים נכנסים שהתקבלו ביציאת המתג.
תוויות מפתח: port_identifier,‏ subblock_id,‏ block_id,‏ reservation_id,‏ switch_type.
מספר הבייטים היוצאים network_switch/out_bytes_count ‫A4X Max או A4X המספר המצטבר של בייטים יוצאים שנשלחו מיציאת המתג.
תוויות מפתח: port_identifier,‏ subblock_id,‏ block_id,‏ reservation_id,‏ switch_type.

מדדים של שגיאות קריטיות ב-GPU

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

שם סוג מדד סדרות מכונות נתמכות תיאור
שגיאת זמן ריצה של NVLink instance/gpu/nvlink_runtime_error ‫A4X Max או A4X אם אירעה שגיאת זמן ריצה של NVLink.
שגיאות DRAM ECC שלא ניתן לתקן instance/gpu/dram_uncorrectable_ecc_error_count ‫A4X Max או A4X מספר הקודים לתיקון שגיאות (ECC) שלא ניתנים לתיקון בזיכרון הגישה האקראית הדינמי (DRAM) של ה-GPU.
מספר המיפויים מחדש של שורות DRAM שלא ניתנים לתיקון instance/gpu/dram_uncorrectable_row_remapping_count ‫A4X Max או A4X מספר המיפויים מחדש של שורות משגיאות שלא ניתן לתקן ב-DRAM של ה-GPU.
המיפוי מחדש של שורת DRAM שלא ניתן לתקן נכשל instance/gpu/dram_row_remapping_failed ‫A4X Max או A4X אם מיפוי מחדש של שורה ב-DRAM של ה-GPU נכשל בגלל אחת מהבעיות הבאות:
  • ניסיון למפות מחדש בנק זיכרון נכשל כי בבנק הזיכרון כבר מופו מחדש שמונה שורות של שגיאות שלא ניתנות לתיקון.
  • ניסיון למפות מחדש שורה נכשל כי השורה כבר מופתה מחדש.
  • ניסיון מיפוי מחדש נכשל כי בוצעו 512 מיפויים מחדש בסך הכול.
שגיאות PCIe שלא ניתן לתקן instance/gpu/pcie_fatal_error_count ‫A4X Max או A4X מספר השגיאות שלא ניתן לתקן ב-PCIe (חיבור מהיר של רכיבים היקפיים).
שגיאות ECC במטמון שלא ניתן לתקן instance/gpu/cache_uncorrectable_ecc_error_count ‫A4X Max או A4X מספר ה-ECC שלא ניתנים לתיקון בזיכרון המטמון.

מדדים של עומסי עבודה של למידת מכונה

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

שם סוג מדד סדרות מכונות נתמכות תיאור
זמן פרודוקטיבי workload/goodput_time ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega הזמן, בשניות, שעומס העבודה מקדיש לפעילויות goodput. הפעילויות האלה הן משימות ליבה שימושיות, כמו מעבר קדימה או אחורה במהלך אימון המודל.
זמן לא פרודוקטיבי workload/badput_time ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega הזמן, בשניות, שעומס העבודה משקיע בפעילויות badput. הפעילויות האלה הן משימות תקורה, כמו טעינה או עיבוד מראש של נתונים לאימון.

מדדים לזיהוי משימות איטיות

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

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

שם סוג מדד סדרות מכונות נתמכות תיאור
חשד למשתתפים שנותרו מאחור instance/gpu/straggler_status ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega אם יש חשד שמכונה וירטואלית היא איטית ומשפיעה על הביצועים של עומס העבודה. מומלץ לפעול לגבי חשד למשימות איטיות רק כשמדדים אחרים מצביעים על בעיות בעומס העבודה.

אתם יכולים גם לראות את מדדי הזיהוי של משימות איטיות ברשומות ביומן של מכונות A4X, ‏ A4,‏ A3 Ultra או A3 Mega. לדוגמה, אפשר להשתמש בשאילתות הבאות:

תיאור שאילתה
יומנים עם חשד למכונות וירטואליות ספציפיות שמתעכבות. אתם יכולים להשתמש בשאילתה הזו כדי לבדוק אם יש חשד למשימות איטיות בעומס עבודה ספציפי בפרויקט. 
    logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic" AND jsonPayload.suspectedStragglersDetection.numNodes > 0 AND jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"

מחליפים את INSTANCE_ID במזהה של מכונה וירטואלית. לכל מכונה וירטואלית נוספת שרוצים לציין, מוסיפים את התנאי הבא לשאילתה:

    OR jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"
כל היומנים של זיהוי המשימות האיטיות בפרויקט. אפשר להשתמש בשאילתה הזו כדי לבדוק אם שירות זיהוי המשימות האיטיות פועל כשלא מזוהות משימות איטיות חשודות. (בגלל המגבלות, אי אפשר לסנן את היומנים בלי חשד למשימות איטיות לפי מכונות וירטואליות ספציפיות). 
    logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic"

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

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

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

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

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

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

מדדי זיהוי של עומסי עבודה שלא מגיבים

מדדי הזיהוי של עומסי עבודה שלא מגיבים עוזרים לכם:

  • לזהות מתי עומס עבודה שלם נתקע (לפעמים נקרא NCCL hang)
  • להבין למה עומס העבודה נתקע, למשל אם זה נגרם בגלל קריסה של תהליך או רשת שנתקעה

כדי לזהות ולאבחן עומסי עבודה שלא מגיבים במכונות, אתם יכולים להשתמש במדדים הבאים:

שם סוג מדד סדרות מכונות נתמכות תיאור
אירועים של עומסי עבודה שלא מגיבים, שזוהו באמצעות טלמטריית NCCL instance/gpu/nccl_hang ‫A4X Max, ‏ A4X, ‏ A4 ו-A3 Ultra מספר האירועים שזוהו של עומסי עבודה שלא מגיבים, כסדרת נתונים לאורך זמן.

הפעלת זיהוי של עומסי עבודה שלא מגיבים

כדי להפעיל זיהוי של עומסי עבודה שלא מגיבים, צריך להפעיל את CoMMA עם טלמטריית פעימות לב, אות פינג תקופתי שמציין שעומס העבודה פועל. בגרסאות האחרונות של CoMMA, ההגדרה הזו מופעלת כברירת מחדל. עם זאת, אם אתם משתמשים בגרסה של CoMMA מגרסה 1.1.1 של חבילת NICCL/gIB, אתם צריכים להפעיל באופן ידני את הטלמטריה של פעימות הלב. כדי לבדוק באיזו גרסה של חבילת NICCL/gIB אתם משתמשים, קראו את המאמר בדיקת הגרסה של NCCL ו-gIB.

כדי להפעיל באופן ידני את הטלמטריה של אותות חיים ב-CoMMA, צריך לציין את משתני הסביבה הבאים בסביבת האימון:

NCCL_PROFILER_HEARTBEAT=true

NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL=10s

משתמשים במדיניות NCCL_PROFILER_HEARTBEAT כדי להפעיל או להשבית את הטלמטריה של האותות, ובמדיניות NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL כדי לציין את התדירות של הטלמטריה של האותות. מידע נוסף זמין במאמר משתני סביבה של CoMMA.

השבתת הזיהוי של עומסי עבודה שלא מגיבים

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

NCCL_PROFILER_HEARTBEAT=false

למה עומסי העבודה לא מגיבים

כדי להבין למה עומס עבודה לא מגיב, בודקים את הערך של התווית hang_reason:

  1. במסוף Google Cloud , נכנסים לדף  Metrics explorer:

    כניסה לדף Metrics Explorer

    אם אתם משתמשים בשורת החיפוש כדי למצוא את הדף הזה, בחרו בתוצאה שכותרת המשנה שלה היא Monitoring.

  2. מחפשים את המדד הבא:

    compute.googleapis.com/instance/gpu/nccl_hang

  3. משתמשים בתכונה צבירה ובוחרים את התוויות הבאות:

    • instance_id
    • hang_reason

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

ערך התווית תיאור מה מומלץ לעשות בשלב הזה?
MissingHeartbeatIssue הטלמטריה של האותות החיוניים הופסקה בדרגה אחת או יותר, מה שבדרך כלל מצביע על קריסה קריטית של תהליך או צומת.
  • בודקים אם עדיין אפשר להגיע למכונה.
  • בודקים אם התהליכים של עומס העבודה קרסו.
  • בודקים ביומני המערכת אם יש אירועים של מחסור בזיכרון (OOM), כמו dmesg.
  • מחפשים כשלים בחומרה או שגיאות NVIDIA XID.
StalledRankIssue עדיין מתקבלים נתוני טלמטריה של אותות חיים, אבל הדירוגים לא מתקדמים בפעולות NCCL.
  • בודקים אם יש מבוי סתום בפעולות ברמת האפליקציה.
  • בודקים אם תהליך האפליקציה תקוע בפעולה שמונעת ממנו לתקשר עם אחרים, כמו חישוב או checkpointer.
MissingCommunicatorIssue כל הדרגות ששייכות למתקשר NCCL הפסיקו להתקדם.
  • יכול להיות שעומס העבודה הופסק או שהתקשורת של NCCL נסגרה באופן פתאומי. אם אתם מצפים שעומס עבודה יפעל ללא הפרעה במכונה הווירטואלית הזו, בדקו אם עומס העבודה הופסק או הושבת באופן חריג.
NoHangIssue ערך ברירת המחדל. לא זוהו בעיות.
  • לא נדרשת שום פעולה.

הצגת המדדים

כדי לראות את המדדים של המכונות ושל אשכולות Slurm, משתמשים בלוחות הבקרה של Monitoring:

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

שימוש במרכזי בקרה מוכנים מראש

אתם יכולים להשתמש בלוחות הבקרה של Monitoring שנוצרו מראש ל-AI Hypercomputer כדי להציג מדדים של המכונות ואשכולות Slurm. אפשר גם ליצור עותק של מרכז בקרה מוכן מראש ולשנות אותו בהתאם לצרכים שלכם.

כדי להשתמש במרכז בקרה מוכן מראש ל-AI Hypercomputer:

  1. נכנסים לדף  Dashboards במסוף Google Cloud :

    כניסה לדף Dashboards

    אם אתם משתמשים בשורת החיפוש כדי למצוא את הדף הזה, בחרו בתוצאה שכותרת המשנה שלה היא Monitoring.

  2. בעמודה Name, לוחצים על השם של אחד ממרכזי הבקרה הבאים, בהתאם למדדים שרוצים לראות:

    • כדי לעקוב אחרי התקינות של המכונות, הביצועים של ה-GPU וזיהוי המשימות האיטיות, משתמשים בלוח הבקרה Cluster Director Health Monitoring.

      כדי להבין איך משתמשים במדדים האלה כדי לזהות ולנתח בעיות, אתם יכולים להיעזר גם במרכז הבקרה של הפלייבוק GCE Interactive Playbook - Cluster Director Health Monitoring.

    • כדי לעקוב אחרי יעילות השידור ברשת, משתמשים בלוח הבקרה Cluster Director Transmission Efficiency.

    • כדי לעקוב אחרי יעילות הרשת בין בלוקים ותת-בלוקים, משתמשים בלוח הבקרה Cluster Director Block Network.

      כדי לקבל מידע נוסף על השימוש במדדים האלה לזיהוי ולניתוח בעיות, אפשר גם להשתמש בלוח הבקרה של ה-playbook‏ GCE Interactive Playbook - Cluster Director Block Network.

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

  3. אופציונלי: כדי ליצור עותק של מרכז בקרה ולהתאים אותו אישית לצרכים שלכם, לוחצים על Copy dashboard.

יצירת מרכזי בקרה בהתאמה אישית

כדי ליצור לוח בקרה בהתאמה אישית ב-Monitoring, מבצעים את הפעולות הבאות:

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

  2. יצירה וניהול של לוחות בקרה בהתאמה אישית

צפייה ביומני הזיהוי של משימות איטיות

כדי להציג את יומני הזיהוי של משימות איטיות באמצעות ה-Logs Explorer:

  1. נכנסים לדף Logs Explorer ב- במסוף Google Cloud :

    נכנסים לדף Logs Explorer.

    אם אתם משתמשים בשורת החיפוש כדי למצוא את הדף הזה, בחרו בתוצאה עם כותרת המשנה Logging.

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

  2. בסרגל הכלים, משתמשים בבורר טווח התאריכים כדי לבחור את טווח התאריכים שרוצים לנתח.

  3. בחלונית Query, מזינים שאילתה ליומני זיהוי של משימות איטיות.

  4. לוחצים על Run Query.

הדוגמה הבאה מציגה רשומה ביומן של זיהוי משימות איטיות.

  {
    ...
    "jsonPayload": {
      ...
      "@type": "type.googleapis.com/ml.aitelemetry.performancedebugging.output.NetworkStragglersOutput",
      "suspectedStragglersDetection": {
        "numNodes": 4,
        "nodes": [
          {
            "latencyMs": 9,
            "instanceId": "INSTANCE_ID_1"
          },
          {
            "latencyMs": 9,
            "instanceId": "INSTANCE_ID_2"
          },
          {
            "instanceId": "INSTANCE_ID_3",
            "latencyMs": 4
          },
          {
            "instanceId": "INSTANCE_ID_4",
            "latencyMs": 0
          }
        ],
        "message": "Suspected stragglers detected."
      }
    },
    "resource": {
      "type": "project",
      "labels": {
        "project_id": "PROJECT_NUMBER"
      }
    },
    ...
    "severity": "INFO",
    "logName": "projects/PROJECT_ID/logs/compute.googleapis.com%2Fworkload_diagnostic",
    ...
  }

הרשומה ביומן כוללת את השדות הבאים:

  • ‫numNodes: מספר המכונות החשודות כחריגות שזוהו בפרויקט. בדוגמה הזו זוהו ארבעה מופעי מחשוב שחשודים כאיטיים.
  • ‫instanceId: המזהה של מכונה שזוהתה כחשודה כאיטית.

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