גניבה: מי שגונב זמן CPU ממכונות וירטואליות

שלום! אני רוצה לספר במילים פשוטות על המכניקה של הופעת הגניבה בתוך מכונות וירטואליות ועל כמה חפצים לא ברורים שהצלחנו לגלות במהלך המחקר שלו, שאליהם נאלצתי לצלול כמנהל טכני של פלטפורמת ענן פתרונות ענן של Mail.ru. הפלטפורמה פועלת על KVM.

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

1. מה זה לגנוב

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

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

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

2. מה משפיע על גניבה

2.1. חישוב גניבה

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

• התחממות יתר של המעבד, שבה מדלגים על מחזורים.
• הפעלה/השבתה של הגברת טורבו, המשנה את תדר השעון של המעבד.
• שינוי באורך של פרוסת זמן המתרחשת בעת שימוש בטכנולוגיות חיסכון בחשמל של המעבד כגון SpeedStep.
• חישוב הבעיה הממוצעת: אומדן ניצול של דקה של 80% יכול להסתיר פרץ לטווח קצר של 100%.
• נעילת ספין גורמת להשבת המעבד, אך תהליך המשתמש אינו רואה התקדמות בביצועו. כתוצאה מכך, הניצול המשוער של המעבד על ידי התהליך יהיה XNUMX%, אם כי התהליך לא יצרוך זמן מעבד פיזית.

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

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

2.2. סוגי וירטואליזציה ב-KVM

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

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

1. מערכת ההפעלה האורחת שולחת פקודה למכשיר האורח שלה.
2. מנהל ההתקן האורח מקבל את הפקודה, יוצר בקשה ל-BIOS של המכשיר ושולח אותה ל-hypervisor.
3. תהליך ה-Hypervisor מתרגם פקודה לפקודה עבור מכשיר פיזי, מה שהופך אותו, בין היתר, לאבטח יותר.
4. מנהל ההתקן הפיזי מקבל את הפקודה ששונתה ושולח אותה למכשיר הפיזי עצמו.
5. התוצאות של ביצוע פקודות חוזרות לאחור באותו נתיב.

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

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

פר וירטואליזציה. האפשרות הנפוצה ביותר לווירטואליזציה של מכשירים ב-KVM ובאופן כללי מצב הוירטואליזציה הנפוץ ביותר עבור מערכות הפעלה אורחות. הייחודיות שלו היא שעבודה עם כמה תת-מערכות של hypervisor (לדוגמה, עם ערימת הרשת או הדיסק) או הקצאת דפי זיכרון מתרחשת באמצעות ממשק ה-API של hypervisor, ללא תרגום של פקודות ברמה נמוכה. החיסרון של שיטת הווירטואליזציה הזו הוא שצריך לשנות את ליבת מערכת ההפעלה האורחת כדי שתוכל לתקשר עם ה-Hypervisor באמצעות API זה. אבל זה נפתר בדרך כלל על ידי התקנת מנהלי התקנים מיוחדים על מערכת ההפעלה האורחת. ב-KVM קוראים ל-API הזה virtio API.

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

הצד ההפוך של האצה זו הוא שלא כל התהליכים שרצים בתוך המכונה הוירטואלית נשארים בתוכה. זה יוצר כמה אפקטים מיוחדים שעלולים לגרום להופעת גניבה. אני ממליץ להתחיל מחקר מפורט של הנושא הזה עם ממשק API עבור I/O וירטואלי: virtio.

2.3. תזמון "הוגן".

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

לינוקס משתמשת במה שנקרא CFS, Completely Fair Scheduler, שהפך למתזמן ברירת המחדל מאז הליבה 2.6.23. כדי להבין את האלגוריתם הזה, אתה יכול לקרוא את ארכיטקטורת ליבת לינוקס או את המקור. המהות של CFS טמונה בחלוקת זמן המעבד בין תהליכים בהתאם למשך ביצועם. ככל שתהליך דורש יותר זמן מעבד, כך הוא מקבל פחות זמן מעבד. זה מבטיח ביצוע "הוגן" של כל התהליכים – כך שתהליך אחד לא מעסיק את כל המעבדים כל הזמן, וניתן לבצע גם תהליכים אחרים.

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

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

יש צורך בסיפור כה ארוך כדי להסביר עובדה אחת: ככל שתהליך מנסה לצרוך יותר משאבי מעבד בתזמון לינוקס ישר, כך הוא ייעצר מהר יותר כך שגם תהליכים אחרים יוכלו לעבוד. האם זה נכון או לא זו שאלה קשה, שנפתרת בצורה שונה בעומסים שונים. ב-Windows, עד לאחרונה, המתזמן התמקד בעיבוד עדיפות של יישומי שולחן עבודה, מה שעלול לגרום לתהליכי רקע להיתקע. ל- Sun Solaris היו חמישה כיתות שונות של מתזמנים. כשהוירטואליזציה הושקה, נוספה אחת שישית, מתזמן שיתוף הוגןמכיוון שהחמישה הקודמים לא עבדו כראוי עם וירטואליזציה של Solaris Zones. אני ממליץ להתחיל מחקר מפורט של הנושא הזה עם ספרים כמו פנימיות של Solaris: Solaris 10 ו-OpenSolaris Kernel Architecture או הבנת ליבת לינוקס.

2.4. איך לפקח על גניבה?

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

הפלט של הפקודה העליונה: פירוט העומס על המעבד, בעמודה הימנית ביותר - גניבה

הקושי מתעורר כאשר מנסים לקבל מידע זה מה-hypervisor. אתה יכול לנסות לחזות גניבה במחשב המארח, למשל, לפי פרמטר Load Average (LA) - הערך הממוצע של מספר התהליכים הממתינים בתור הביצוע. השיטה לחישוב פרמטר זה אינה פשוטה, אבל באופן כללי, אם LA המנורמל לפי מספר פתילי המעבד גדול מ-1, זה מצביע על כך ששרת לינוקס עמוס במשהו.

למה כל התהליכים האלה מחכים? התשובה הברורה היא מעבדים. אבל התשובה לא לגמרי נכונה, כי לפעמים המעבד פנוי, ו-LA יוצאת מקנה המידה. זכור איך NFS נופל ואיך LA צומחת בו זמנית. אותו דבר יכול להיות בערך עם הדיסק, ועם התקני קלט/פלט אחרים. אבל למעשה, תהליכים יכולים לחכות לסוף כל נעילה, הן פיזית, הקשורה למכשיר ה-I/O והן הגיונית, כגון mutex. זה כולל גם מנעולים ברמת החומרה (אותה תגובה מהדיסק), או לוגיקה (מה שנקרא פרימיטיבים של נעילה, הכוללים חבורה של ישויות, mutex adaptive וספין, סמפורות, משתני מצב, rw locks, ipc locks. ..).

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

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

3. אפקטים מיוחדים

עכשיו בואו נתעכב על מקרי הגניבה העיקריים שנתקלנו בהם. אני אגיד לך איך הם עוקבים מכל האמור לעיל וכיצד הם מתואמים עם האינדיקטורים ב-hypervisor.

מִחזוּר. הפשוט והנפוץ ביותר: ההיפרוויזר ממוחזר. ואכן, יש הרבה מכונות וירטואליות הפועלות, צריכת מעבדים גבוהה בתוכם, תחרות רבה, ניצול של LA גדול מ-1 (מנומול על ידי פתילים של מעבד). בתוך כל הוירטואלוק הכל מאט. גם גניבה המועברת מה-hypervisor גדלה, יש צורך לחלק מחדש את העומס או לכבות מישהו. באופן כללי, הכל הגיוני ומובן.

פרוירטואליזציה מול מקרים בודדים. יש רק מכונה וירטואלית אחת ב-hypervisor, היא צורכת חלק קטן ממנה, אבל נותנת עומס I/O גדול, למשל, בדיסק. וממקום כלשהו מופיעה בו גניבה קטנה, עד 10% (כפי שמספר ניסויים מראים).

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

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

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

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

LA נמוכה, אבל יש גניבה. אם LA הוא בערך 0,7 (כלומר, נראה שה-Hypervisor עמוס בחסר), אבל גניבה נצפית בתוך מכונות וירטואליות בודדות:

• האפשרות שתוארה כבר לעיל עם פרוירטואליזציה. המכונה הוירטואלית יכולה לקבל מדדים המציינים גניבה, למרות שה-hypervisor מצליח. לפי תוצאות הניסויים שלנו, אפשרות הגניבה הזו אינה עולה על 10% ולא אמורה להיות לה השפעה משמעותית על ביצועי האפליקציה בתוך המכונה הוירטואלית.
• הפרמטר LA נחשב לא נכון. ליתר דיוק, בכל רגע ספציפי זה נחשב לנכון, אבל כשמשתמשים בממוצע על פני דקה אחת, מסתבר שמזלזלים בו. לדוגמה, אם מכונה וירטואלית אחת לשליש מה-hypervisor צורכת את כל המעבדים שלה למשך חצי דקה בדיוק, אז LA לדקה ב-hypervisor יהיה 0,15; ארבע מכונות וירטואליות כאלה שעובדות בו זמנית יתנו 0,6. ואת העובדה שבמשך חצי דקה על כל אחד מהם הייתה גניבה פרועה ב-25% מבחינת LA, כבר אי אפשר לשלוף.
• שוב, בגלל המתזמן שהחליט שמישהו אוכל יותר מדי, ונתן למישהו הזה לחכות. בינתיים, אני אחליף את ההקשר, אטפל בהפרעות ואטפל בדברי מערכת חשובים אחרים. כתוצאה מכך, חלק מהמכונות הווירטואליות אינן רואות בעיות, בעוד שאחרות חוות פגיעה רצינית בביצועים.

4. עיוותים אחרים

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

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

באופן כללי, יכולות להיות סיבות רבות לעיוותים. במערכת מסוימת, ייתכן שתמצא משהו אחר. עדיף להתחיל עם הספרים שאליהם נתתי קישורים למעלה, ולקרוא סטטיסטיקות מה-Hypervisor עם כלי עזר כמו perf, sysdig, systemtap, מהם עשרות.

5. מסקנות

1. כמות מסוימת של גניבה יכולה להתרחש עקב פאראווירטואליזציה, והיא יכולה להיחשב כנורמלית. באינטרנט כותבים שהערך הזה יכול להיות 5-10%. זה תלוי ביישומים בתוך המכונה הוירטואלית ובאיזה עומס זה נותן למכשירים הפיזיים שלה. כאן חשוב לשים לב איך יישומים מרגישים בתוך מכונות וירטואליות.
2. היחס בין העומס על ה-Hypervisor והגניבה בתוך המכונה הוירטואלית אינו תמיד מחובר באופן חד משמעי, שתי ההערכות של גניבה יכולות להיות שגויות במצבים ספציפיים בעומסים שונים.
3. למתזמן יש יחס רע לתהליכים שמבקשים הרבה. הוא מנסה לתת פחות למי שמבקש יותר. מכונות וירטואליות גדולות הן רעות.
4. גניבה קטנה יכולה להיות הנורמה גם ללא פרוירטואליזציה (בהתחשב בעומס בתוך המכונה הוירטואלית, מאפייני העומס של שכנים, חלוקת העומס בין חוטים וגורמים נוספים).
5. אם אתה רוצה לגלות גניבה במערכת מסוימת, אתה צריך לחקור אפשרויות שונות, לאסוף מדדים, לנתח אותם בקפידה ולחשוב כיצד לחלק את העומס באופן שווה. סטיות אפשריות מכל מקרים, אשר חייבים להיות מאושרים בניסוי או להסתכל במפרק הבאגים של הקרנל.

מקור: www.habr.com