גניבה: מי שגונב זמן 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. תזמון "הוגן".

Виртуалка на гипервизоре является, фактически, обычным процессом, который подчиняется законам шедулинга (распределения ресурсов между процессами) в ядре Linux, поэтому рассмотрим его подробнее.

В Linux используется так называемый CFS, Completely Fair Scheduler, начиная с ядра 2.6.23 ставший диспетчером по умолчанию. Чтобы разобраться с этим алгоритмом, можно почитать Linux Kernel Architecture или исходники. Суть CFS заключается в распределении процессорного времени между процессами в зависимости от длительности их выполнения. Чем больше процессорного времени требует процесс, тем меньше этого времени он получает. Это гарантирует «честное» выполнение всех процессов — чтобы один процесс не занимал все процессоры постоянно, и остальные процессы тоже могли выполняться.

Иногда такая парадигма приводит к интересным артефактам. Давние пользователи Linux наверняка помнят замирание обычного текстового редактора на десктопе во время запуска ресурсоемких приложений типа компилятора. Так получалось, потому что нересурсоемкие задачи десктопных приложений конкурировали с задачами, активно потребляющими ресурсы, такими как компилятор. CFS считает, что это нечестно, поэтому периодически останавливает текстовый редактор и даёт процессору обработать задачи компилятора. Это поправили с помощью механизма sched_autogroup, אך נותרו תכונות רבות אחרות של חלוקת זמן המעבד בין משימות. למעשה, הסיפור הזה לא עוסק עד כמה הכל גרוע ב-CFS, אלא ניסיון למשוך את תשומת הלב לעובדה שהחלוקה ה"הוגנת" של זמן המעבד אינה המשימה הטריוויאלית ביותר.

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

Такой длинный рассказ нужен для объяснения одного факта: чем больше ресурсов процессора пытается потребить процесс в честном шедулере Linux, тем быстрее он будет остановлен, чтобы другие процессы тоже могли поработать. Правильно это или нет — сложный вопрос, который при разных нагрузках решается по-разному. В Windows до недавнего времени шедулер был ориентирован на приоритетную обработку десктопных приложений, из-за чего могли зависать фоновые процессы. В Sun Solaris было пять различных классов шедулеров. Когда запустили виртуализацию, добавили шестой, מתזמן שיתוף הוגןמכיוון שהחמישה הקודמים לא עבדו כראוי עם וירטואליזציה של Solaris Zones. אני ממליץ להתחיל מחקר מפורט של הנושא הזה עם ספרים כמו פנימיות של Solaris: Solaris 10 ו-OpenSolaris Kernel Architecture או הבנת Linux גַרעִין.

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

Мониторить steal внутри виртуальной машины, как и любую другую процессорную метрику, просто: можно пользоваться любым средством съема метрик процессора. Главное, чтобы виртуалка была на Linux. 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