ניתוח ביצועי VM ב-VMware vSphere. חלק 2: זיכרון

חלק 1. על CPU

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

קצת תיאוריה

זיכרון ה-RAM של מכונות וירטואליות נלקח מהזיכרון של השרת עליו פועלים ה-VMs. זה די ברור :). אם זיכרון ה-RAM של השרת אינו מספיק לכולם, ESXi מתחיל להשתמש בטכניקות שיחזור זיכרון. אחרת, מערכות ההפעלה VM יקרסו עם שגיאות גישה ל-RAM.

ESXi מחליט באילו טכניקות להשתמש בהתאם לעומס ה-RAM:

מצב זיכרון

גבול

פעילות

גָבוֹהַ

400% של minFree

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

נקה

100% של minFree

דפי זיכרון גדולים מפוצלים לקטנים, TPS מאולץ.

רך

64% של minFree

TPS + בלון

קשה

32% של minFree

TPS + דחיסה + החלפה

נמוך

16% של minFree

דחיסה + החלפה + חסימה

מקור

minFree הוא זיכרון ה-RAM הנדרש כדי שה-Hypervisor יפעל.

עד ESXi 4.1 כולל, minFree תוקנה כברירת מחדל - 6% מ-RAM של השרת (ניתן לשנות את האחוז באמצעות אפשרות Mem.MinFreePct ב-ESXi). בגרסאות מאוחרות יותר, עקב צמיחת הזיכרון בשרתים, החלו לחשב את minFree על סמך כמות הזיכרון של המארח, ולא כערך אחוז קבוע.

ערך minFree (ברירת מחדל) מחושב באופן הבא:

אחוז הזיכרון השמור ל-minFree

טווח זיכרון

6%

0-4 ג'יגה-בייט

4%

4-12 ג'יגה-בייט

2%

12-28 ג'יגה-בייט

1%

זיכרון שנותר

מקור

לדוגמה, עבור שרת עם 128 GB של זיכרון RAM, הערך של MinFree יהיה כדלקמן:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
הערך בפועל עשוי להיות שונה בכמה מאות מגה-בייט, תלוי בשרת וב-RAM.

אחוז הזיכרון השמור ל-minFree

טווח זיכרון

ערך עבור 128 GB

6%

0-4 ג'יגה-בייט

245,76 מגה-בייט

4%

4-12 ג'יגה-בייט

327,68 מגה-בייט

2%

12-28 ג'יגה-בייט

327,68 מגה-בייט

1%

זיכרון שנותר (100 GB)

1024 מגה-בייט

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

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

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

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

מקור

מנגנון זה פועל רק עבור דפי זיכרון בגודל 4 KB (עמודים קטנים). ההיפרוויזר אפילו לא מנסה לבטל כפילות של עמודים בגודל 2 מגה (עמודים גדולים): הסיכוי למצוא עמודים זהים בגודל זה אינו גדול.

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

אם אתה רוצה ש-TPS יתחיל לעבוד מבלי לחכות ש-RAM המארח יהיה מלא, עליך להגדיר את הערך ב-Advanced Options ESXi "Mem.AllocGuestLargePage" ל-0 (ברירת מחדל 1). אז הקצאת דפי זיכרון גדולים למכונות וירטואליות תושבת.

מאז דצמבר 2014, בכל מהדורות ESXi, TPS בין VMs מושבת כברירת מחדל, שכן נמצאה פגיעות שמאפשרת באופן תיאורטי ל-VM אחד לגשת ל-RAM של VM אחר. פרטים כאן. לא נתקלתי במידע על יישום מעשי של ניצול הפגיעות של TPS.

מדיניות TPS נשלטת באמצעות אפשרות מתקדמת "Mem.ShareForceSalting" ב-ESXi:
0 - Inter-VM TPS. TPS עובד עבור דפים של מחשבי VM שונים;
1 - TPS עבור מחשבי VM עם אותו ערך "sched.mem.pshare.salt" ב-VMX;
2 (ברירת מחדל) - Intra-VM TPS. TPS עובד עבור דפים בתוך VM.

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

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

יחד עם Vmware Tools, מותקן ב-VM מנהל התקן מיוחד בשם Balloon Driver (aka vmmemctl). כאשר ה-Hypervisor מתחיל להיגמר בזיכרון הפיזי ונכנס למצב רך, ESXi מבקש מה-VM לדרוש בחזרה זיכרון RAM שאינו בשימוש דרך מנהל התקן הבלון הזה. הדרייבר, בתורו, עובד ברמת מערכת ההפעלה ומבקש ממנו זיכרון פנוי. ה-Hypervisor רואה אילו דפי זיכרון פיזי תפס נהג הבלון, לוקח זיכרון מהמכונה הוירטואלית ומחזיר אותו למארח. אין בעיות בתפעול מערכת ההפעלה, שכן ברמת מערכת ההפעלה הזיכרון תפוס על ידי מנהל הבלון. כברירת מחדל, מנהל הבלון יכול לתפוס עד 65% מזיכרון ה-VM.

אם VMware Tools לא מותקנים ב-VM או Ballooning מושבת (אני לא ממליץ על זה, אבל יש KB:), ה-Hypervisor עובר מיד לטכניקות מחמירות יותר להסרת זיכרון. מסקנה: ודא שכלי VMware נמצאים ב-VM.

ניתן לבדוק את פעולת ה-Balloon Driver ממערכת ההפעלה באמצעות VMware Tools.

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

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

כך פועלת ההחלפה. כאשר אתה מפעיל מכונה וירטואלית, נוצר עבורו קובץ עם סיומת .vswp. זה שווה בגודלו לזיכרון ה-RAM הלא שמור של ה-VM: זה ההבדל בין זיכרון מוגדר לזיכרון שמור. כאשר ההחלפה פועלת, ESXi מחליף דפי זיכרון של מחשב וירטואלי לקובץ זה ומתחיל לעבוד איתו במקום הזיכרון הפיזי של השרת. כמובן, זיכרון "RAM" כזה איטי בכמה סדרי גודל מזיכרון אמיתי, גם אם ה-.vswp נמצא באחסון מהיר.

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

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

מונים בסיסיים של זיכרון מכונה וירטואלית

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

Active - מציג את כמות ה-RAM (KB) שה-VM ניגש אליו בתקופת המדידה הקודמת.

נוֹהָג - זהה ל-Active, אבל כאחוז מ-RAM המוגדר של ה-VM. מחושב באמצעות הנוסחה הבאה: פעיל ÷ גודל זיכרון מוגדר במכונה וירטואלית.
שימוש גבוה ופעיל, בהתאמה, אינם תמיד אינדיקטור לבעיות ביצועים של VM. אם ה-VM משתמש בזיכרון באגרסיביות (לפחות ניגש אליו), זה לא אומר שאין מספיק זיכרון. במקום זאת, זו סיבה להסתכל על מה שקורה במערכת ההפעלה.
יש אזעקה סטנדרטית לשימוש בזיכרון עבור מחשבי VM:

משותף - כמות ה-VM RAM שנבטלה כפילויות באמצעות TPS (בתוך VM או בין VMs).

כמובן - כמות הזיכרון הפיזי המארח (KB) שהוקצתה ל-VM. מאפשר משותף.

נצרך (נתן - משותף) - כמות הזיכרון הפיזי (KB) שה-VM צורך מהמארח. לא כולל Shared.

אם חלק מזיכרון ה-VM ניתן לא מהזיכרון הפיזי של המארח, אלא מקובץ החלפה, או זיכרון נלקח מה-VM דרך מנהל ההתקן הבלון, כמות זו לא נלקחת בחשבון ב- Granted and Consumed.
ערכי מוענקים וצרוכים גבוהים הם נורמליים לחלוטין. מערכת ההפעלה לוקחת בהדרגה זיכרון מההיפרוויזר ולא מחזירה אותו. עם הזמן, ב-VM הפועל באופן פעיל, הערכים של המונים הללו מתקרבים לכמות הזיכרון המוגדר, ונשארים שם.

אפס - כמות ה-VM RAM (KB), המכיל אפסים. זיכרון כזה נחשב בחינם על ידי ה-Hypervisor והוא יכול להינתן למכונות וירטואליות אחרות. לאחר שמערכת ההפעלה האורחת כתבה משהו לזיכרון מאופס, היא נכנסת ל-Consumed ולא חוזרת חזרה.

שמור תקורה - כמות ה-VM RAM, (KB) ששמורה על ידי ה-Hypervisor לפעולת VM. זהו כמות קטנה, אך היא חייבת להיות זמינה במארח, אחרת ה-VM לא יתחיל.

בלון - כמות ה-RAM (KB) שהוסר מה-VM באמצעות מנהל התקן בלון.

דחוס - כמות ה-RAM (KB) שנדחסה.

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

כך נראה הגרף עם מוני הזיכרון של VM שעובד בדרך כלל עם 150 GB של זיכרון RAM.

בגרף למטה, ל-VM יש בעיות ברורות. מתחת לגרף ניתן לראות כי עבור VM זה נעשה שימוש בכל הטכניקות המתוארות לעבודה עם RAM. הבלון עבור VM זה גדול בהרבה מ-Consumed. למעשה, VM יותר מת מאשר חי.

ESXTOP

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

מסך הזיכרון ESXTOP נקרא באמצעות מקש "m" ונראה כך (נבחרו השדות B,D,H,J,K,L,O):

הפרמטרים הבאים יעניינו אותנו:

Mem overcommit ממוצע - ערך ממוצע של מנוי יתר לזיכרון במארח למשך 1, 5 ו-15 דקות. אם זה מעל אפס, אז זו סיבה להסתכל על מה שקורה, אבל לא תמיד אינדיקטור לבעיות.

בשורות PMEM/MB и VMKMEM/MB - מידע על הזיכרון הפיזי של השרת והזיכרון הזמין ל-VMkernel. בין הדברים המעניינים כאן ניתן לראות את הערך minfree (ב-MB), המצב המארח בזיכרון (במקרה שלנו, גבוה).

בשורה NUMA/MB אתה יכול לראות את ההתפלגות של זיכרון RAM על פני צמתי NUMA (שקעים). בדוגמה זו, ההתפלגות היא לא אחידה, מה שבאופן עקרוני אינו טוב במיוחד.

להלן נתונים סטטיסטיים כלליים של השרת עבור טכניקות שיחזור זיכרון:

PSHARE/MB - אלה נתונים סטטיסטיים של TPS;

החלפה/MB - חילופי סטטיסטיקות שימוש;

ZIP/MB - סטטיסטיקת דחיסת דפי זיכרון;

MEMCTL/MB - סטטיסטיקות שימוש בנהג בלון.

עבור מחשבי VM בודדים, אנו עשויים להתעניין במידע הבא. הסתרתי את שמות ה-VMs כדי לא לבלבל את הקהל :). אם המדד ESXTOP דומה למונה ב-vSphere, אספק את המונה המתאים.

MEMSZ - כמות הזיכרון שהוגדרה ב-VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + לא נגוע.

מענק — מוענק ב-MB.

TCHD - פעיל ב-MBytes.

MCTL? - האם מנהל הבלון מותקן ב-VM.

MCTLSZ - בלון ל-MB.

MCTLGT - כמות ה-RAM (MBytes) ש-ESXi רוצה להסיר מה-VM דרך מנהל התקן הבלון (Memctl Target).

MCTLMAX - הכמות המקסימלית של זיכרון RAM (MBytes) ש-ESXi יכול להסיר מ-VM דרך מנהל התקן הבלון.

SWCUR - הכמות הנוכחית של זיכרון RAM (MBytes) שהוקצה ל-VM מקובץ ה-Swap.

S.W.G.T. - כמות ה-RAM (MBytes) ש-ESXi רוצה לתת ל-VM מקובץ ה-Swap (Swap Target).

אתה יכול גם להציג מידע מפורט יותר על טופולוגיית NUMA של ה-VM דרך ESXTOP. לשם כך, בחר בשדות D, G:

קָטָן – NUMA צמתים עליהם ממוקם ה-VM. כאן אתה יכול להבחין מיד ב-vm רחב, שאינם מתאימים לצומת NUMA אחד.

NRMEM - כמה מגה-בייט של זיכרון ה-VM לוקח מצומת NUMA המרוחק.

NLMEM - כמה מגה-בייט של זיכרון ה-VM לוקח מצומת NUMA המקומי.

N%L – אחוז זיכרון VM בצומת NUMA המקומי (אם פחות מ-80%, עלולות להיווצר בעיות ביצועים).

זיכרון על ההיפרוויזר

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

בטל החלפה

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

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

טיפים לניהול זיכרון RAM ב-ESXi

לבסוף, הנה כמה טיפים שיעזרו לך להימנע מבעיות בביצועי VM עקב זיכרון RAM:

• הימנע מהרשמת יתר של זיכרון RAM באשכולות פרודוקטיביים. רצוי להחזיק תמיד ~20-30% מהזיכרון הפנוי באשכול כדי של-DRS (ולמנהל) יהיה מרחב תמרון ו-VMs לא יעברו ל-Swap במהלך ההעברה. כמו כן, אל תשכח את המרווח לסובלנות תקלות. זה לא נעים כאשר, כאשר שרת אחד נכשל וה-VM מופעל מחדש באמצעות HA, חלק מהמכונות עוברות גם ל-Swap.
• בתשתיות מאוחדות מאוד, נסה לא ליצור מחשבי VM עם זיכרון גדול ממחצית הזיכרון המארח. זה שוב יעזור ל-DRS להפיץ מכונות וירטואליות על פני שרתי אשכולות ללא בעיות. כלל זה, כמובן, אינו אוניברסלי :).
• היזהרו מהתראה לשימוש בזיכרון המארח.
• אל תשכח להתקין את VMware Tools ב-VM ואל תכבה את Ballooning.
• שקול להפעיל את Inter-VM TPS ולנטרל עמודים גדולים בסביבות VDI וסביבות בדיקה.
• אם ה-VM נתקל בבעיות ביצועים, בדוק אם הוא משתמש בזיכרון מצומת NUMA מרוחק.
• הסר מכשירי VM מ-Swap במהירות האפשרית! בין היתר, אם ה-VM נמצא ב-Swap, מערכת האחסון סובלת מסיבות ברורות.

זה הכל בשבילי לגבי זיכרון RAM. להלן מאמרים קשורים למי שרוצה להעמיק. המאמר הבא יוקדש ל-storage.

קישורים שימושייםhttp://www.yellow-bricks.com/2015/03/02/what-happens-at-which-vsphere-memory-state/
http://www.yellow-bricks.com/2013/06/14/how-does-mem-minfreepct-work-with-vsphere-5-0-and-up/
https://www.vladan.fr/vmware-transparent-page-sharing-tps-explained/
http://www.yellow-bricks.com/2016/06/02/memory-pages-swapped-can-unswap/
https://kb.vmware.com/s/article/1002586
https://www.vladan.fr/what-is-vmware-memory-ballooning/
https://kb.vmware.com/s/article/2080735
https://kb.vmware.com/s/article/2017642
https://labs.vmware.com/vmtj/vmware-esx-memory-resource-management-swap
https://blogs.vmware.com/vsphere/2013/10/understanding-vsphere-active-memory.html
https://www.vmware.com/support/developer/converter-sdk/conv51_apireference/memory_counters.html
https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-65-monitoring-performance-guide.pdf

מקור: www.habr.com