ניפוי באגים בהיטים של מטמון מרחוק להפעלה מרחוק

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

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

בדיקת שיעור ההיטים של המטמון

בפלט הרגיל של הרצת Bazel, יש לעייןINFO קו המפרט תהליכים, שזה פחות או יותר תואם לפעולות של Bazel. את הקו הזה שבו הפעולה בוצעה. חפשו את התווית remote, המציינת פעולה שבוצעה מרחוק, linux-sandbox את הפעולות שבוצעו בארגז חול מקומי וערכים אחרים עבור שיטות ביצוע אחרות. פעולה שהתוצאה שלה הגיעה ממטמון מרוחק מוצגת כ-remote cache hit.

למשל:

INFO: 11 processes: 6 remote cache hit, 3 internal, 2 remote.

בדוגמה הזו היו 6 היטים של מטמון מרחוק, ושתי פעולות לא כללו מטמון ופעולות שבוצעו מרחוק. ניתן להתעלם מהחלק הפנימי של 3. בדרך כלל מדובר בפעולות פנימיות קטנטנות, כגון יצירת קישורים סימבוליים. היטים מקומיים של המטמון לא נכללים בסיכום הזה. אם מתקבלים 0 תהליכים (או מספר הנמוך מהצפוי), יש להריץ את bazel clean ואחריו את פקודת ה-build/test.

פתרון בעיות הקשורות להיטים במטמון

אם לא מתקבל שיעור ההיט הצפוי, אתם יכולים לבצע את הפעולות הבאות:

יש לוודא שהרצה מחדש של אותה פקודת Build/בדיקה יוצרת היטים של מטמון

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

2. מקצה bazel clean. פקודה זו מנקה את המטמון המקומי שלך, שמאפשרת לחקור התאמות למטמון מרוחק בלי להסתיר את התוצאות של מטמון מקומי.

3. מריצים את גרסת ה-build ואת הבדיקה שאותה בודקים שוב (באותו המכונה).

4. יש לבדוק את השורה INFO של שיעור ההיטים של המטמון. אם לא מופיעים תהליכים מלבד remote cache hit ו-internal, פירוש הדבר שהמטמון שלך מאוכלס כראוי והוא ניגש אליו. במקרה כזה, דלגו לקטע הבא.

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

   א. מריצים מחדש את גרסאות ה-build או הבדיקות הרלוונטיים כדי לקבל את יומני הביצועים:

     bazel clean
     bazel --optional-flags build //your:target --execution_log_binary_file=/tmp/exec1.log
   

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

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

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

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

6. יש לבדוק שכל הפעולות ביומן הביצוע מופיעות כ-cacheable כ-True. אם cacheable לא מופיע ביומן הביצוע של פעולת אישור, פירוש הדבר הוא שהכלל התואם עשוי להכיל תג no-cache בהגדרה שלו בקובץ BUILD הנתונים. כדי לראות מאיפה הפעולה מגיעות, אפשר לבדוק את השדה progress_message הקריא לבני אדם.

7. אם הפעולות זהות ו-cacheable אין התאמות למטמון, ייתכן ששורת הפקודה כוללת --noremote_accept_cached. הפעולה הזו תשבית את חיפושי המטמון במטמון ב-build.

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

   א. יש להוסיף את --build_event_text_file=/tmp/bep.txt לפקודת Bazel כדי לקבל את גרסת הטקסט של היומן.

   ב. יש לפתוח את גרסת הטקסט של היומן ולחפש את ההודעה structured_command_line במכשיר של command_line_label: "canonical". תוצג בה כל האפשרויות אחרי ההרחבה.

   ג. יש לחפש את remote_accept_cached ולבדוק אם הוא מוגדר false.

   ד. אם הערך של remote_accept_cached הוא false, יש לקבוע היכן הוא מוגדר ל-false: בשורת הפקודה או בקובץ bazelrc.

שמירה במטמון של מכשירים שונים

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

1. מבצעים שינוי קטן ב-build כדי להימנע מפגיעה במטמון הקיים.

2. הפעלת ה-build במכונה הראשונה:

    bazel clean
    bazel ... build ... --execution_log_binary_file=/tmp/exec1.log
   

3. מריצים את ה-build במכונה השנייה, כדי לוודא שהשינוי משלב 1 כולל:

    bazel clean
    bazel ... build ... --execution_log_binary_file=/tmp/exec2.log
   

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

השוואת יומני הביצוע

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

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

1. קבלת יומני הביצוע מכל build ואחסון שלהם כ-/tmp/exec1.log ו-/tmp/exec2.log.

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

   git clone https://github.com/bazelbuild/bazel.git
   cd bazel
   

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

   bazel build src/tools/execlog:parser
   bazel-bin/src/tools/execlog/parser \
     --log_path=/tmp/exec1.log \
     --log_path=/tmp/exec2.log \
     --output_path=/tmp/exec1.log.txt \
     --output_path=/tmp/exec2.log.txt
   

4. יש להשתמש בטקסט המועדף כדי להבדיל בין /tmp/exec1.log.txt לבין /tmp/exec2.log.txt.