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

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

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

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

• ביצועי ה-GPU

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

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

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

• זיהוי של הודעות שלא נמסרו

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

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

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

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

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

• מידע על Google Cloud שירותים למעקב אחרי עומסי עבודה:

  • המדדים במסמך הזה מבוססים על מרכזי בקרה של Monitoring. מידע נוסף על לוחות בקרה של Monitoring, תקופות שמירה של נתונים ב-Monitoring ותמחור של Monitoring

  • בנוסף, גילוי של חריגות מספק רשומות ביומן ב-Cloud Logging. מידע נוסף על ממשקי Logging, תקופות שמירה של יומנים ותמחור של Logging

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

מגבלות

בעיות מוכרות במדדי התשתית:

• יכול להיות שחלק ממופעי המחשוב לא יציגו מדדים של GPU Power Consumption.
• יכול להיות שבחלק ממופעי המחשוב לא יוצגו המדדים GPU Temperature או GPU Thermal Margin, או שיוצג NaN במקום המדדים.
• יכול להיות שיעברו עד שבע דקות מרגע איסוף המדדים ועד שהם יופיעו במסוף Google Cloud .
• יכול להיות שתראו מדדים שגויים לגבי סדרות מכונות אחרות מלבד A4X Max,‏ A4X,‏ A4,‏ A3 Ultra או 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 דקות.
• בשונה מהמדדים האחרים במסמך הזה, אי אפשר לסנן את מדדי זיהוי החריגות בפרויקטים לפי אשכול, בלוק, בלוק משנה או מכונת חישוב. עם זאת, אפשר לסנן שאילתות ביומנים של זיהוי שאילתות שמתעכבות לפי המזהה של מופע מחשוב אחד או יותר שחשודים כמתעכבים.

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

• ב-logs של זיהוי חריגים מדווח שהמערכת לא מחשיבה כחריגים מקרים של הפעלת מופעי מחשוב שלא תומכים בזיהוי חריגים.
• למרות שזיהוי של תהליכים שמתעכבים מדויק עבור הרבה עומסי עבודה של ML, יכול להיות שיהיו אי דיוקים בעומסי עבודה עם דפוסי תקשורת מורכבים.

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

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

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

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

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

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

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

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

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

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

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

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

מדדים זמינים

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

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

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

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

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

מדדי תשתית

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

• מדדי תקינות של GPU

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

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

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

Google Cloud מדדים זמינים ב-Compute Engine.

מדדי הבריאות של ה-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	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, אפשר להשתמש במדדים הבאים:

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

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

כדי לעקוב אחרי זיהוי של מכונות 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"

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

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

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

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

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

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

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

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

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

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

שם	סוג מדד	סדרות מכונות נתמכות	תיאור
זוהו אירועים של עומסי עבודה (workload) שלא מגיבים באמצעות טלמטריה של 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	הטלמטריה של אותות הפעימה (Heartbeat) הפסיקה לפעול עבור דרגה אחת או יותר, מה שבדרך כלל מצביע על קריסה של תהליך או צומת.	בודקים אם עדיין אפשר להגיע למופע. בודקים אם תהליכי העבודה קרסו. בודקים ביומני המערכת אם יש אירועים של חוסר זיכרון (OOM), כמו dmesg. מחפשים כשלים בחומרה או שגיאות NVIDIA XID.
StalledRankIssue	עדיין מתקבלים נתוני טלמטריה של פעימות לב, אבל הדירוגים לא מתקדמים בפעולות של NCCL.	בדיקה של אפשרות לקיפאון בפעולות ברמת האפליקציה. בודקים אם תהליך האפליקציה תקוע בפעולה שמונעת ממנו לתקשר עם אחרים, כמו חישוב או נקודת בדיקה.
MissingCommunicatorIssue	כל הדירוגים ששייכים למשתמש שמוגדר כמתקשר ב-NCCL הפסיקו להתקדם.	יכול להיות שהעומס שלכם הופסק או שהתקשורת של NCCL נסגרה בפתאומיות. אם אתם מצפים שעומס עבודה יפעל ללא הפרעות במכונה הווירטואלית הזו, כדאי לבדוק אם עומס העבודה הופסק או כובה באופן לא תקין.
NoHangIssue	ערך ברירת המחדל. לא זוהו בעיות.	לא נדרשת שום פעולה.

הצגת המדדים

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

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

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

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

• כדי לראות את מדדי עומס העבודה של ה-ML, אפשר לעיין במסמכי ההסבר על הגדרת מעקב אחר עומס העבודה.

• כדי לראות את היומנים של זיהוי הודעות שמתעכבות, צפייה ביומנים של זיהוי הודעות שמתעכבות

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

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

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

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

• מעקב אחרי מכונות וירטואליות
• בדיקת אשכולות באמצעות סורק תקינות האשכולות
• התאמה אישית של מרכזי בקרה ל Google Cloud שירותים
• פתרון בעיות שקשורות לביצועים איטיים