ביצוע דינמי

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

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

להפעיל ביצוע דינמי?

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

כדי להפעיל את מודול הביצועים הדינמי, צריך להעביר את הסימון --internal_spawn_scheduler אל Bazel. פעולה זו מוסיפה אסטרטגיית ביצוע חדשה בשם dynamic. כעת תוכלו להשתמש בה כאסטרטגיה שלכם ל בערוצים שאתם רוצים להריץ באופן דינמי, כגון --strategy=Javac=dynamic. בקטע הבא מוסבר איך בוחרים את המניעים להפעלה של ביצוע דינמי.

לכל תרחיש באמצעות השיטה הדינמית, שיטות הביצוע מרחוק מבוססות על הדגל --dynamic_remote_strategy והאסטרטגיות המקומיות מהסימון --dynamic_local_strategy. העברה של --dynamic_local_strategy=worker,sandboxed מגדירה את ברירת המחדל של הסניף המקומי של ביצוע דינמי כדי לנסות עם עובדים או ביצוע בארגז חול בהזמנה זו. ברירת המחדל של התכונה --dynamic_local_strategy=Javac=worker היא ביטול ברירת המחדל של הרשאת האחסון בפורמט Javac בלבד. הגרסה המרוחקת פועלת באותו אופן. ניתן לציין את שני הסימונים כמה פעמים. אם לא ניתן לבצע פעולה מקומית, היא תתבצע מרחוק כרגיל ולהפך.

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

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

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

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

לקבלת רקע נוסף על הביצוע הדינמי של הנעילה ועל הנעילה שלה, קראו את המאמר Juli_Merino's מצוין

מתי כדאי להשתמש בהפעלה דינמית?

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

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

נכון למועד ההשקה 5.0.0-pre.20210708.4, הגדרת ביצועים מכילה נתונים על ביצוע עובדים, כולל משך זמן הסיום של בקשת עבודה אחרי שהפסדתם במרוץ דינמי. אם אתם רואים שרשורים של עובדים עם ביצועים דינמיים שמשקיעים זמן רב בקניית משאבים או ב-async-worker-finish במשך זמן רב, יכול להיות שיהיו לכם פעולות מקומיות איטיות שתעכבו את השרשורים של העובדים.

בפרופיל שלמעלה, שנעשה בו שימוש ב-8 עובדים ב-Javac, אנחנו רואים שעובדי Java רבים איבדו את המירוצים וסיימו את העבודה שלהם בשרשורים של async-worker-finish. הדבר נגרם כתוצאה ממינוף של עובד שאינו עובד, ומספיק לעכב את העובדים.

רק כאשר Javac פועל עם ביצוע דינמי, רק מחצית מהעובדים שהתחילו יאבדו בסופו של דבר את המרוץ לאחר שהתחילו לעבוד.

הדגל --experimental_spawn_scheduler שהומלץ בעבר הוצא משימוש. היא מפעילה ביצוע דינמי ומגדירה את dynamic כשיטת ברירת המחדל עבור כל ה תיעודים, מה שבדרך כלל יוביל לבעיות כאלה.

פתרון בעיות

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

אם נתקלת בבעיות בביצוע דינמי באמצעות אסטרטגיית standalone, אפשר לנסות להריץ בלי --experimental_local_lockfree_output או להריץ את הפעולות המקומיות בארגז החול. הפעולה הזו עשויה להאט מעט את פעולת ה-build (ראו למעלה אם אתם משתמשים ב-Mac או Windows), אבל היא מסירה סיבות אפשריות לכשל.