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

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

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

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

  • ביצועי ה-GPU

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

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

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

  • זיהוי של הודעות שלא נשלחו

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

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

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

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

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

מגבלות

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

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

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

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

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

המגבלות של זיהוי חריגים

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

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

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

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

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

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

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

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

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

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

כדי לעקוב אחרי מדדים של עומסי עבודה (workloads) ב-AI Hypercomputer, נדרשות ההרשאות הבאות:

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

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

מדדים זמינים

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

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

מדדי תשתית

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

סקירה כללית של המדדים הזמינים ב-Compute Engine מופיעה במאמר בנושא מדדים שלGoogle 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 ב-GPU של NVIDIA שמצורף למופע של Compute נתקל בבעיות.
תקינות התשתית של מכונות וירטואליות 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) נפרדים במארח. במכונות וירטואליות עם כמה יחידות GPU שמחוברות אליהן, המדד מספק את צריכת החשמל בנפרד לכל יחידת GPU במארח.
SM Utilization instance/gpu/sm_utilization ‫A4X Max,‏ A4X,‏ A4,‏ A3 Ultra או A3 Mega ערך שאינו אפס מציין שהמעבדים המרובים לסטרימינג (SM) במעבדי ה-GPU נמצאים בשימוש פעיל.
טמפרטורת ה-GPU instance/gpu/temperature ‫A4X Max,‏ A4X,‏ A4,‏ A3 Ultra או A3 Mega הטמפרטורה במעלות צלזיוס (℃) ובערכים עשרוניים של יחידות GPU נפרדות במארח. במקרים של מכונות וירטואליות עם כמה יחידות GPU שמחוברות אליהן, המדד מספק את הטמפרטורה בנפרד לכל יחידת GPU במארח.
שוליים תרמיים של GPU instance/gpu/tlimit ‫A4X Max,‏ A4X,‏ A4,‏ A3 Ultra או A3 Mega הטווח התרמי במעלות צלזיוס (℃) ובערכים עשרוניים שזמין לכל GPU לפני שהוא צריך להאט בגלל טמפרטורה גבוהה. במקרים של מכונות וירטואליות עם כמה יחידות GPU שמחוברות אליהן, המדד מספק את המרווח התרמי בנפרד לכל יחידת 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.
תפוקה של בייטים שהתקבלו instance/gpu/throughput_rx_bytes ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega מספר הבייטים שהתקבלו מתנועת הרשת.
תפוקה של בייטים בהעברה instance/gpu/throughput_tx_bytes ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega מספר הבייטים שמועברים לתעבורת הרשת.

מדדים של מיתוג ToR

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

  • מעקב אחרי תקינות המתג והיציאה.
  • הערכת קיבולת רוחב הפס הזמינה ועומקי תור במאגר נתונים זמני (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 השימוש במעבד של מתג הרשת, שנמדד כשבר מ-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 הספירה המצטברת של מנות נכנסות שהושלכו בכניסה בגלל גלישת חוצץ.
תוויות מפתח: 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 הספירה המצטברת של מעברים במצב של קישור פיזי (flaps בין 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 הספירה המצטברת של מנות שסומנו בביטים של הודעה מפורשת על עומס (ECN) בגלל חציית סף המאגר.
תוויות מפתח: port_identifier, subblock_id, block_id, reservation_id, switch_type.
Pfc rx packets network_switch/pfc_rx_packets_count ‫A4X Max או A4X הספירה המצטברת של מסגרות השהיה (pause) של בקרת זרימה מבוססת-עדיפות (PFC) שהתקבלו ביציאה.
הערה: רלוונטי רק לסביבות ייעודיות שבהן מופעל PFC.
תוויות מפתח: port_identifier, ‏ priority_index, ‏ subblock_id, ‏ block_id, ‏ reservation_id, ‏ switch_type.
Pfc tx packets 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.
שגיאות ECC ב-DRAM שלא ניתן לתקן 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 (‏Peripheral Component Interconnect Express) שלא ניתן לתקן.
שגיאות ECC במטמון שלא ניתן לתקן instance/gpu/cache_uncorrectable_ecc_error_count ‫A4X Max או A4X מספר שגיאות ה-ECC שלא ניתן לתקן בזיכרון המטמון.

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

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

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

מדדים של זיהוי חריגים

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

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

שם סוג מדד סדרות מכונות נתמכות תיאור
חשד למשתמשים שמתחמקים 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"

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

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

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

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

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

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

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

מדדים לזיהוי עומסי עבודה לא רספונסיביים עוזרים לכם:

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

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

שם סוג מדד סדרות מכונות נתמכות תיאור
זוהו אירועים של עומסי עבודה שלא מגיבים באמצעות טלמטריה של 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. נכנסים לדף  Metrics explorer במסוף Google Cloud :

    כניסה אל Metrics Explorer

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

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

    compute.googleapis.com/instance/gpu/nccl_hang

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

    • instance_id
    • hang_reason

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

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

הצגת המדדים

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

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

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

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

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

  1. במסוף Google Cloud , עוברים לדף  Dashboards:

    מעבר אל מרכזי בקרה

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

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

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

      כדי לקבל מידע נוסף על השימוש במדדים האלה לזיהוי ולניתוח בעיות, אפשר גם להשתמש במרכז הבקרה של מדריך ההפעלה האינטראקטיבי של GCE – מעקב אחרי תקינות של Cluster Director.

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

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

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

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

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

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

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

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

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

צפייה ביומני זיהוי של מכשירים שלא מחוברים

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

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

    כניסה אל 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: מספר מופעי המחשוב החשודים שזוהו בפרויקט. בדוגמה, זוהו ארבעה מקרים חשודים של מכונות וירטואליות (VM) של מחשוב שפועלות ללא צורך.
  • ‫instanceId: המזהה של מופע Compute שזוהה כחשוד כמשאב לא פעיל.

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