ניתוח השפעת הביצועים של מקור הזמן שנבחר במערכת

ברנדן גרג, אחד ממפתחי DTrace, שמפתח כעת כלי ניתוח ביצועים מבוססי BPF בליבת לינוקס, סיכם את הניסיון שנצבר מניתוח בעיות הביצועים בהן נתקלה נטפליקס בעת העברת ה- Cassandra DBMS מסביבות CentOS לאובונטו. ענן אמזון EC2 המבוסס על Xen. לאחר ההגירה, עומס המעבד גדל ב-30% והעיכובים במהלך פעולות הכתיבה גדלו בערך באותה כמות. כפי שמתברר, הביצועים של אפליקציות המבקשות מידע זמן אינטנסיבי תלוי מאוד במקור הזמן המדויק שנבחר במערכת.

בתחילה, הסיבה לירידה בביצועים לא הייתה ברורה והאבחון החל בניטור ההשפעה האפשרית של תהליכי מערכת עתירי משאבים שפועלים באופן קבוע או מושקים מעת לעת תוך שימוש בכלי השירות המובילים ו-execsnoop. אבל הכל הצביע על כך שצריכת המשאבים עלתה במיוחד ב- Cassandra DBMS, שנכתב בג'אווה. השוואת מדדי הפרופיל של שני תהליכי Cassandra הפועלים במקביל ב-CentOS וב-Ubuntu, תוך עיבוד אותן שאילתות, הראתה שכ-32% מהזמן הכולל הושקע בקריאת os::javaTimeMillis(), המשמשת להשגת מידע על השעה הנוכחית. .

לאחר מכן, נערך ניסוי בו נכתבה אפליקציית Java פשוטה שנקראת שיטת System.currentTimeMillis() מאה מיליון פעמים בלולאה. הפעלת האפליקציה הראתה שלוקח 13 שניות להשלים ב-CentOS, וכ-68 שניות באובונטו, כלומר. פי 5 יותר איטי. תוכנית דומה נכתבה ב-C שקראה לפונקציה gettimeofday() מאה מיליון פעמים, אבל כשהיא בוצעה, התקבלו תוצאות דומות.

מאחר שהתברר שמקור הבעיה הוא בפונקציה של החזרת השעה הנוכחית, תשומת הלב הופנתה לשינויים באינדיקטורים בעת בחירת מקורות שונים של זמן מדויק במערכת. אם לשפוט לפי התוכן של "/sys/devices/system/clocksource/clocksource0/current_clocksource", טיימר "xen" שימש כברירת מחדל בעת הפעלת לינוקס במערכת האורחת. לאחר שינוי מקור הזמן ל-"tsc", זמן הביצוע של אפליקציית הבדיקה באובונטו ירד מ-68 ל-3.3 שניות, כלומר. זה הפך להיות מהיר פי 20. בנוסף, בוצעה בדיקת ביצועים של מקור הזמן kvm-clock, שהראתה עלייה בעיכובים ב-20% בהשוואה ל-TSC. $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ זמן java TimeBench real 1m8.300s משתמש 0m38.337s $0s29.875 echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ זמן java TimeBench real 0m3.370s משתמש 0m3.353s sys 0m0.026s

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

החלפת שרתי ייצור בנטפליקס למקור TSC הביא להפחתה של 43% בהשהיית הכתיבה והשיג תוצאות באמצעות אובונטו שהיו מהירות פי 4 מתצורות המריצות CentOS עם מקור זמן "xen". תוצאות המחקר הועברו לאמזון, אשר המליצה רשמית להשתמש במקור ברירת המחדל של TSC זמן בסביבות AWS EC2 המבוססות על ה-Xen hypervisor (kvm-clock נשאר מומלץ בסביבות המבוססות על Nitro hypervisor).

מקור: OpenNet.ru