ניתוח של ביצועי מכונות וירטואליות ב-VMware vSphere. חלק 1: מעבד

אם אתה מנהל תשתית וירטואלית המבוססת על VMware vSphere (או כל מחסנית טכנולוגית אחרת), אתה כנראה שומע לעתים קרובות תלונות ממשתמשים: "המכונה הוירטואלית איטית!" בסדרת המאמרים הזו אנתח מדדי ביצועים ואספר לכם מה ולמה הוא מאט וכיצד לוודא שהוא לא מאט.

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

• CPU
• RAM,
• דִיסק,
• רֶשֶׁת.

אני אתחיל עם המעבד.

כדי לנתח ביצועים נצטרך:

• מוני ביצועים של vCenter - מוני ביצועים, שניתן לראות את הגרפים שלהם דרך לקוח vSphere. מידע על מונים אלו זמין בכל גרסה של הלקוח (לקוח "עבה" ב-C#, לקוח אינטרנט ב-Flex ולקוח אינטרנט ב-HTML5). במאמרים אלו נשתמש בצילומי מסך מלקוח C#, רק בגלל שהם נראים טוב יותר במיניאטורי :)
• ESXTOP – כלי עזר הפועל משורת הפקודה ESXi. בעזרתו, אתה יכול לקבל את הערכים של מוני ביצועים בזמן אמת או להעלות ערכים אלה לתקופה מסוימת לקובץ .csv לניתוח נוסף. לאחר מכן, אספר לך יותר על כלי זה ואספק מספר קישורים שימושיים לתיעוד ולמאמרים בנושא.

קצת תיאוריה

ב-ESXi, תהליך נפרד - עולם בטרמינולוגיה של VMware - אחראי על הפעולה של כל vCPU (ליבת מכונה וירטואלית). יש גם תהליכי שירות, אבל מנקודת מבט של ניתוח ביצועי VM הם פחות מעניינים.

תהליך ב-ESXi יכול להיות באחד מארבעה מצבים:

• הפעלה - התהליך מבצע עבודה מועילה.
• חכה - התהליך לא עושה שום עבודה (בטל) או שהוא ממתין לקלט/פלט.
• קוסטופ - מצב המתרחש במכונות וירטואליות מרובות ליבות. זה מתרחש כאשר מתזמן ה-CPU של ה-Hypervisor (ESXi CPU Scheduler) אינו יכול לתזמן את הביצוע בו-זמנית של כל ליבות המחשב הווירטואלי הפעילות בליבות השרת הפיזיות. בעולם הפיזי, כל ליבות המעבד עובדות במקביל, מערכת ההפעלה האורחת בתוך ה-VM מצפה להתנהגות דומה, כך שה-Hypervisor צריך להאט את הליבות ה-VM שיש להן את היכולת לסיים את מחזור השעון שלהן מהר יותר. בגרסאות מודרניות של ESXi, מתזמן ה-CPU משתמש במנגנון שנקרא תזמון משותף רגוע: ה-Hypervisor מחשיב את הפער בין ליבת המכונה הווירטואלית ה"מהירה" וה"איטית ביותר" (הטייה). אם הפער חורג מסף מסוים, הליבה המהירה נכנסת למצב costop. אם ליבות VM מבלות זמן רב במצב זה, זה יכול לגרום לבעיות ביצועים.
• מוכן – התהליך נכנס למצב זה כאשר ה-Hypervisor אינו מסוגל להקצות משאבים לביצועו. ערכי מוכנות גבוהים יכולים לגרום לבעיות ביצועים של VM.

מוני ביצועי CPU של מכונה וירטואלית בסיסית

שימוש במעבד, %. מציג את אחוז השימוש במעבד לתקופה נתונה.

איך לנתח? אם VM משתמש באופן עקבי במעבד ב-90% או שיש שיאים של עד 100%, אז יש לנו בעיות. בעיות יכולות להתבטא לא רק בפעולה ה"איטית" של האפליקציה בתוך ה-VM, אלא גם בחוסר הנגישות של ה-VM ברשת. אם מערכת הניטור מראה שה-VM נופל מעת לעת, שימו לב לשיאים בגרף השימוש ב-CPU.

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

מה לעשות? אם השימוש ב-CPU של VM עובר כל הזמן דרך הגג, אז אתה יכול לחשוב על הגדלת מספר ה-vCPUs (למרבה הצער, זה לא תמיד עוזר) או להעביר את ה-VM לשרת עם מעבדים חזקים יותר.

שימוש במעבד ב-MHz

בגרפים ב-vCenter שימוש ב-% אתה יכול לראות רק עבור כל המכונה הוירטואלית; אין גרפים לליבות בודדות (ב-Esxtop יש % ערכי לליבות). עבור כל ליבה אתה יכול לראות שימוש ב-MHz.

איך לנתח? קורה שאפליקציה אינה מותאמת לארכיטקטורה מרובת ליבות: היא משתמשת רק בליבה אחת ב-100%, והשאר לא פעילים ללא עומס. לדוגמה, עם הגדרות ברירת מחדל לגיבוי, MS SQL מתחיל את התהליך על ליבה אחת בלבד. כתוצאה מכך, הגיבוי מאט לא בגלל המהירות האיטית של הדיסקים (על זה התלונן המשתמש בתחילה), אלא בגלל שהמעבד לא יכול להתמודד. הבעיה נפתרה על ידי שינוי הפרמטרים: הגיבוי החל לפעול במקביל במספר קבצים (בהתאמה, במספר תהליכים).

דוגמה לעומס לא אחיד על הליבות.

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

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

אתה יכול גם לנסות לבדוק את הגדרות צריכת החשמל ב-BIOS של השרת. מנהלי מערכת רבים מאפשרים מצב High Performance ב-BIOS ובכך משביתים טכנולוגיות חיסכון באנרגיה של מצבי C ומצבי P. מעבדי אינטל המודרניים משתמשים בטכנולוגיית Turbo Boost, המגבירה את התדירות של ליבות מעבד בודדות על חשבון ליבות אחרות. אבל זה עובד רק כאשר טכנולוגיות חיסכון באנרגיה מופעלות. אם נשבית אותם, המעבד לא יכול להפחית את צריכת החשמל של ליבות שאינן טעונות.

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

אם יש לך מכשירי VM בודדים (או ליבות VM) בתשתית שלך הדורשים תדר מעבד מוגבר, התאמה נכונה של צריכת החשמל יכולה לשפר משמעותית את הביצועים שלהם.

מעבד מוכן

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

איך לנתח? בדרך כלל, אם הליבות של מחשב וירטואלי נמצאות במצב Ready יותר מ-10% מהמקרים, תבחין בבעיות ביצועים. במילים פשוטות, יותר מ-10% מהזמן שה-VM ממתין למשאבים פיזיים שיהפכו לזמינים.

ב-vCenter אתה יכול להציג 2 מונים הקשורים ל-CPU Ready:

• נְכוֹנוּת,
• מוכנים.

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

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

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

(ערך סיכום מוכן למעבד / (מרווח עדכון ברירת המחדל של התרשים בשניות * 1000)) * 100 = % מוכן למעבד

לדוגמה, עבור ה-VM בגרף למטה, ערך שיא Ready עבור כל המחשב הוירטואלי יהיה כדלקמן:

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

• הערך Ready עבור ה-VM כולו הוא הסכום של Ready על פני הליבות.
• מרווח מדידה. עבור זמן אמת זה 20 שניות, ולדוגמה, בתרשימים יומיים זה 300 שניות.

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

בואו לחשב את Ready על סמך הנתונים מהגרף למטה. (324474/(20*1000))*100 = 1622% עבור ה-VM כולו. אם אתה מסתכל על הליבות זה לא כל כך מפחיד: 1622/64 = 25% לכל ליבה. במקרה זה, די קל לזהות את המלכוד: הערך של Ready אינו מציאותי. אבל אם אנחנו מדברים על 10-20% עבור ה-VM כולו עם מספר ליבות, אז עבור כל ליבה הערך עשוי להיות בטווח הנורמלי.

מה לעשות? ערך Ready גבוה מציין שלשרת אין מספיק משאבי מעבד לפעולה רגילה של מכונות וירטואליות. במצב כזה, כל מה שנותר הוא להפחית מנוי יתר על ידי מעבד (vCPU:pCPU). ברור שניתן להשיג זאת על ידי הפחתת הפרמטרים של מכשירי VM קיימים או על ידי העברת חלק מה-VM לשרתים אחרים.

שיתוף פעולה

איך לנתח? מונה זה הוא גם מסוג Summation והוא מומר לאחוזים באותו אופן כמו Ready:

(ערך סיכום עצירת מעבד / (מרווח עדכון ברירת המחדל של תרשים בשניות * 1000)) * 100 = % עצירת שיתוף מעבד

כאן אתה גם צריך לשים לב למספר הליבות ב-VM ולמרווח המדידה.
במצב costop, הקרנל אינו מבצע עבודה מועילה. עם בחירה נכונה של גודל ה-VM והעומס הרגיל על השרת, מונה ה-co-stop צריך להיות קרוב לאפס.

במקרה זה, העומס אינו נורמלי בבירור :)

מה לעשות? אם מספר מחשבים וירטואליים עם מספר רב של ליבות פועלים ב-Hypervisor אחד ויש מנוי יתר על ה-CPU, מונה ה-Co-stop עשוי לגדול, מה שיוביל לבעיות בביצועים של מחשבי VM אלה.

כמו כן, ה-co-stop תגדל אם הליבות הפעילות של VM אחד ישתמשו ב-threads בליבת שרת פיזית אחת עם hyper-treading מופעל. מצב זה עשוי להיווצר, למשל, אם ל-VM יש יותר ליבות ממה שזמינות פיזית בשרת שבו הוא פועל, או אם הגדרת "preferHT" מופעלת עבור ה-VM. אתה יכול לקרוא על הגדרה זו כאן.

כדי למנוע בעיות בביצועי ה-VM הנובעים מ-Co-stop גבוה, בחר את גודל ה-VM בהתאם להמלצות יצרן התוכנה שפועלת על VM זה וליכולות השרת הפיזי בו פועל ה-VM.

אל תוסיף ליבות ברזרבה; הדבר עלול לגרום לבעיות ביצועים לא רק עבור ה-VM עצמו, אלא גם עבור השכנים שלו בשרת.

מדדי CPU שימושיים אחרים

הפעלה - כמה זמן (ms) במהלך תקופת המדידה ה-vCPU היה במצב RUN, כלומר, הוא באמת ביצע עבודה שימושית.

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

חכה - כמה זמן (ms) במהלך תקופת המדידה ה-vCPU היה במצב המתנה. מכיוון ש-IDLE כלול במונה זה, ערכי המתנה גבוהים גם אינם מצביעים על בעיה. אבל אם Wait IDLE נמוך כאשר Wait גבוה, זה אומר שה-VM חיכה להשלמת פעולות ה-I/O, וזה, בתורו, עשוי להצביע על בעיה בביצועים של הכונן הקשיח או כל התקנים וירטואליים של ה-VM.

מקסימום מוגבל - כמה זמן (ms) במהלך תקופת המדידה ה-vCPU היה במצב Ready עקב מגבלת המשאבים שנקבעה. אם הביצועים נמוכים באופן בלתי מוסבר, כדאי לבדוק את הערך של מונה זה ואת מגבלת ה-CPU בהגדרות ה-VM. ל-VMs אכן עשויות להיות מגבלות שאינך מודע להן. לדוגמה, זה קורה כאשר VM שוכפל מתבנית שעליה נקבעה מגבלת ה-CPU.

החלף המתן - כמה זמן במהלך תקופת המדידה ה-vCPU חיכה לפעולה עם VMkernel Swap. אם הערכים של המונה הזה הם מעל אפס, אז ל-VM בהחלט יש בעיות ביצועים. נדבר יותר על SWAP במאמר על מוני RAM.

ESXTOP

אם מוני ביצועים ב-vCenter טובים לניתוח נתונים היסטוריים, אז ניתוח תפעולי של הבעיה נעשה בצורה טובה יותר ב-ESXTOP. כאן, כל הערכים מוצגים בצורה מוכנה (אין צורך לתרגם שום דבר), ותקופת המדידה המינימלית היא 2 שניות.
מסך ESXTOP עבור CPU נקרא עם מקש "c" ונראה כך:

מטעמי נוחות, אתה יכול להשאיר רק תהליכי מחשב וירטואלי על ידי לחיצה על Shift-V.
כדי להציג מדדים עבור ליבות VM בודדות, הקש "e" והזן את ה-GID של ה-VM המעניין (30919 בצילום המסך למטה):

הרשו לי לעבור בקצרה על העמודות המוצגות כברירת מחדל. ניתן להוסיף עמודות נוספות על ידי לחיצה על "f".

NWLD (מספר עולמות) – מספר תהליכים בקבוצה. כדי להרחיב את הקבוצה ולראות מדדים עבור כל תהליך (לדוגמה, עבור כל ליבה ב-VM מרובה ליבות), הקש "e". אם יש יותר מתהליך אחד בקבוצה, אז הערכים המטריים עבור הקבוצה שווים לסכום המדדים עבור התהליכים הבודדים.

%בשימוש - כמה מחזורי מעבד שרת משמשים תהליך או קבוצת תהליכים.

%לָרוּץ - כמה זמן במהלך תקופת המדידה היה התהליך במצב RUN, כלומר. עשה עבודה מועילה. זה שונה מ-%USED בכך שהוא לא לוקח בחשבון היפר-threading, קנה מידה של תדרים וזמן המושקע במשימות מערכת (%SYS).

%SYS – זמן המושקע במשימות מערכת, למשל: עיבוד פסיקה, קלט/פלט, פעולת רשת וכו'. הערך יכול להיות גבוה אם ל-VM יש קלט/פלט גדול.

%OVRLP - כמה זמן השקיעה הליבה הפיזית עליה פועל תהליך ה-VM במשימות של תהליכים אחרים.

מדדים אלו מתייחסים זה לזה באופן הבא:

%USED = %RUN + %SYS - %OVRLP.

בדרך כלל המדד %USED הוא אינפורמטיבי יותר.

%לַחֲכוֹת - כמה זמן במהלך תקופת המדידה התהליך היה במצב המתנה. מאפשר IDLE.

%לְהִתְבַּטֵל - כמה זמן במהלך תקופת המדידה התהליך היה במצב IDLE.

%SWPWT - כמה זמן במהלך תקופת המדידה ה-vCPU חיכה לפעולה עם VMkernel Swap.

%VMWAIT - כמה זמן במהלך תקופת המדידה ה-vCPU היה במצב של המתנה לאירוע (בדרך כלל I/O). אין מונה דומה ב-vCenter. ערכים גבוהים מציינים בעיות ב-I/O ב-VM.

%WAIT = %VMWAIT + %IDLE + %SWPWT.

אם ה-VM אינו משתמש ב-VMkernel Swap, אז בעת ניתוח בעיות ביצועים רצוי להסתכל על %VMWAIT, שכן מדד זה אינו לוקח בחשבון את הזמן בו ה-VM לא עשה דבר (%IDLE).

%RDY - כמה זמן במהלך תקופת המדידה התהליך היה במצב Ready.

%CSTP - כמה זמן במהלך תקופת המדידה היה התהליך במצב costop.

%MLMTD - כמה זמן במהלך תקופת המדידה ה-vCPU היה במצב Ready עקב מגבלת המשאבים שנקבעה.

%WAIT + %RDY + %CSTP + %RUN = 100% - ליבת ה-VM נמצאת תמיד באחד מארבעת המצבים הללו.

מעבד על היפרוויזר

ל-vCenter יש גם מוני ביצועי CPU עבור ה-Hypervisor, אבל הם לא מעניינים - הם פשוט סכום המונים עבור כל ה-VMs בשרת.
הדרך הנוחה ביותר להציג את מצב המעבד בשרת היא בכרטיסייה סיכום:

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

כאשר עומס ה-CPU של השרת גבוה, ה-VMs הפועלים עליו מתחילים להיתקל בבעיות ביצועים.

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

CORE UTIL(%) - טעינת ליבת השרת הפיזית. מונה זה מראה כמה זמן הליבה ביצעה עבודה במהלך תקופת המדידה.

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

PCPU USED(%) – זהה ל-PCPU UTIL(%), אך לוקח בחשבון את קנה המידה של התדרים (או הפחתת תדר הליבה למטרות חיסכון באנרגיה, או הגדלת תדר הליבה עקב טכנולוגיית Turbo Boost) והשרשרת יתר.

PCPU_USED% = PCPU_UTIL% * תדר ליבה אפקטיבי / תדר ליבה נומינלי.

בצילום מסך זה, עבור חלק מהליבות, עקב Turbo Boost, ערך USED גדול מ-100%, מכיוון שתדר הליבה גבוה מהנומינלי.

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

• CORE UTIL עבור הליבה יהיה 100%,
• PCPU UTIL עבור שני השרשורים יהיה 100%,
• PCPU בשימוש עבור שני השרשורים יהיה 50%.

אם שני החוטים לא עבדו 100% מהזמן בתקופת המדידה, אז במהלך התקופות שבהן החוטים עבדו במקביל, ה-PCPU ששימש עבור הליבות מחולק לשניים.

ל-ESXTOP יש גם מסך עם פרמטרים של צריכת חשמל של מעבד שרת. כאן תוכל לראות אם השרת משתמש בטכנולוגיות חיסכון באנרגיה: מצבי C ומצבי P. נקרא על ידי מקש "p":

בעיות נפוצות בביצועי מעבד

לבסוף, אעבור על הסיבות האופייניות לבעיות בביצועי מעבד VM ואתן עצות קצרות לפתרון אותן:

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

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

מנוי יתר גדול של מעבד בשרת. אם ל-VM יש High Ready, צמצם את מנוי היתר של CPU.

טופולוגיית NUMA שגויה ב-VMs גדולים. הטופולוגיה של NUMA שנראית על ידי ה-VM (vNUMA) חייבת להתאים לטופולוגיה של NUMA של השרת (pNUMA). אבחון ופתרונות אפשריים לבעיה זו כתובים, למשל, בספר "VMware vSphere 6.5 Host Resources Deep Dive". אם אינך רוצה להעמיק ואין לך הגבלות רישוי על מערכת ההפעלה המותקנת ב-VM, צור שקעים וירטואליים רבים ב-VM, ליבה אחת בכל פעם. אתה לא תפסיד הרבה :)

זה הכל בשבילי לגבי המעבד. לשאול שאלות. בחלק הבא אדבר על זיכרון RAM.

קישורים שימושייםhttp://virtual-red-dot.info/vm-cpu-counters-vsphere/
https://kb.vmware.com/kb/1017926
http://www.yellow-bricks.com/2012/07/17/why-is-wait-so-high/
https://communities.vmware.com/docs/DOC-9279
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/whats-new-vsphere65-perf.pdf
https://pages.rubrik.com/host-resources-deep-dive_request.html

מקור: www.habr.com