הגדרת ניטור ניצול GPU ו-VRAM עם DCGM

מדוע ניטור GPU משקר: היכן הולכות לאיבוד המדדים

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

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

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

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

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

מה נותן איסוף רציף של טלמטריה מהמאיצים

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

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

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

מצבי ניטור GPU: סוכן, קולקטור, היברידי

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

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

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

שלבי ההטמעה: ממיפוי המאיצים ועד למסירה

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

1. מיפוי המצאי. עוברים על הצומתים, רושמים את דגם המאיצים, נפח הזיכרון, טופולוגיית החיבורים וההתפלגות בין הצוותים. במקביל מאמתים את המצב מול מערכות הרישום — אי־ההתאמות הן בדרך כלל המקור לאזורים עיוורים, שבהם משימות נופלות בלי סיבה מוסברת.
2. סכמת האיסוף. פורסים קולט מדדים ברמת החומרה ומגדירים את מערך האותות: עומס יחידת החישוב, זיכרון תפוס, טמפרטורה, ירידת תדר עקב התחממות, שגיאות זיכרון. את תדירות הסקירה בוחרים כפשרה בין רמת הפירוט לנפח האחסון.
3. כללי התראות. כל התראה משויכת לפעולה: מה בדיוק צריך לעשות התורן כשהיא מופעלת. את הספים קובעים לפי פרופיל העומס הנצפה, ולא לפי התיעוד, אחרת התורן טובע ברעש ומפסיק להגיב.
4. בדיקה תחת עומס. מריצים משימות אופייניות, כולל שיאים, ובודקים אם המערכת תופסת ירידות ודליפות זיכרון לפני שהן מפילות את האימון. בנפרד בודקים את ההתנהגות בעת כשל של צומת אחד.
5. מסירה לתפעול. מוסרים נוהל תגובה, רשימת האחראים והוראות להוספת צומתים חדשים לניטור. לאחר המסירה צוות הלקוח מרחיב את הכיסוי בעצמו, בלי לחזור אלינו עבור כל כרטיס.

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

מארז האספקה: קונפיגורציות, כללי התראות, נהלים

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

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

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

מקרה בוחן: איסוף מדדים אחיד עבור מצאי מאיצים

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

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

מה שינינו

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

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

מדדים לפני ואחרי

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

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

מה לעשות אם DCGM כבר פרוס, אך המדדים אינם מתכנסים?

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

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

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

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

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

קורה שאחרי תיקון הקונפיגורציה המספרים לא משתנים: הסוכן NVIDIA DCGM מעלה מערכת מונים ישנה מתוך האימג׳ הבנוי. נדרשת בנייה מחדש של הסוכן עם תיאור שדות מעודכן והפעלה מחדש של הקונטיינרים — המשימות אינן נעצרות, והאיסוף ממשיך במקביל לחישובים.

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

ספקות טכניים: תקורה, הרשאות, רעש

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

המתחם סגור, ואין להוציא מדדים החוצה

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

ההתראות יהיו שגויות ורועשות

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

נדבר על המשימה: מה צריך לדעת לפני שמתחילים

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

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

מה כדאי להכין לשיחה:

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

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

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