रिमोट एक्ज़ीक्यूशन के लिए रिमोट कैश हिट को डीबग करना

इस पेज पर, कैश हिट रेट की जांच करने और रिमोट एक्ज़ीक्यूशन के संदर्भ में कैश मिस की जांच करने का तरीका बताया गया है.

इस पेज पर यह माना गया है कि आपके पास कोई ऐसा बिल्ड और/या टेस्ट है जो रिमोट एक्ज़ीक्यूशन का इस्तेमाल करता है. साथ ही, आपको यह पक्का करना है कि आप रिमोट कैश का सही तरीके से इस्तेमाल कर रहे हैं.

कैश हिट रेट की जांच करना

Bazel के रन के स्टैंडर्ड आउटपुट में, INFO लाइन देखें. इसमें प्रोसेस की सूची होती है, जो Bazel की कार्रवाइयों से मेल खाती हैं. उस लाइन में यह जानकारी होती है कि कार्रवाई कहां की गई. remote लेबल देखें. इससे पता चलता है कि कोई कार्रवाई रिमोट तरीके से की गई है. वहीं, linux-sandbox लेबल से पता चलता है कि कार्रवाई, लोकल सैंडबॉक्स में की गई है. अन्य एक्ज़ीक्यूशन रणनीतियों के लिए, अन्य वैल्यू देखें. ऐसी कार्रवाई जिसका नतीजा रिमोट कैश से मिला है, remote cache hit के तौर पर दिखता है.

उदाहरण के लिए:

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

इस उदाहरण में, छह रिमोट कैश हिट हुए. वहीं, दो कार्रवाइयों के लिए कैश हिट नहीं हुए और उन्हें रिमोट तरीके से एक्ज़ीक्यूट किया गया. तीसरे हिस्से को अनदेखा किया जा सकता है. आम तौर पर, यह सिंबॉलिक लिंक बनाने जैसी छोटी-छोटी इंटरनल कार्रवाइयां होती हैं. इस खास जानकारी में, लोकल कैश हिट शामिल नहीं किए जाते. अगर आपको 0 प्रोसेस (या उम्मीद से कम संख्या) दिखती हैं, तो bazel clean कमांड चलाएं. इसके बाद, अपना बिल्ड/टेस्ट कमांड चलाएं.

कैश हिट से जुड़ी समस्याएं हल करना

अगर आपको उम्मीद के मुताबिक कैश हिट रेट नहीं मिल रहा है, तो यह तरीका अपनाएं:

पक्का करें कि एक ही बिल्ड/टेस्ट कमांड को फिर से चलाने पर कैश हिट जनरेट हों

1. उन बिल्ड और/या टेस्ट को चलाएं जिनसे आपको कैश पॉप्युलेट होने की उम्मीद है. किसी खास स्टैक पर पहली बार नया बिल्ड चलाने पर, रिमोट कैश हिट नहीं मिल सकते. रिमोट एक्ज़ीक्यूशन के तहत, कार्रवाई के नतीजे कैश में सेव किए जाते हैं. इसके बाद, उन्हें फिर से इस्तेमाल किया जा सकता है.

2. bazel clean कमांड चलाएं. इस कमांड से आपका लोकल कैश साफ़ हो जाता है. इससे, लोकल कैश हिट से नतीजे मास्क किए बिना, रिमोट कैश हिट की जांच की जा सकती है.

3. जिन बिल्ड और टेस्ट की जांच की जा रही है उन्हें उसी मशीन पर फिर से चलाएं.

4. कैश हिट रेट के लिए, INFO लाइन देखें. अगर आपको remote cache hit और internal के अलावा कोई प्रोसेस नहीं दिखती है, तो इसका मतलब है कि आपका कैश सही तरीके से पॉप्युलेट और ऐक्सेस किया जा रहा है. ऐसे में, अगले सेक्शन पर जाएं.

5. गड़बड़ी की एक वजह यह हो सकती है कि बिल्ड में कोई ऐसी चीज़ शामिल हो जो नॉन-हर्मेटिक हो. इसकी वजह से, दोनों रन में कार्रवाइयों को अलग-अलग ऐक्शन की मिलती हैं. उन कार्रवाइयों को ढूंढने के लिए, यह तरीका अपनाएं:

   a. एक्ज़ीक्यूशन लॉग पाने के लिए, सवाल में मौजूद बिल्ड या टेस्ट को फिर से चलाएं:

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

   b. दोनों रन के एक्ज़ीक्यूशन लॉग की तुलना करें. पक्का करें कि दोनों लॉग फ़ाइलों में कार्रवाइयां एक जैसी हों. गड़बड़ियों से, रन के बीच हुए बदलावों के बारे में पता चलता है. उन गड़बड़ियों को ठीक करने के लिए, अपने बिल्ड को अपडेट करें.

   अगर आपने कैशिंग की समस्याओं को हल कर लिया है और अब बार-बार रन करने पर सभी कैश हिट जनरेट हो रहे हैं, तो अगले सेक्शन पर जाएं.

   अगर आपकी कार्रवाई के आईडी एक जैसे हैं, लेकिन कोई कैश हिट नहीं है, तो इसका मतलब है कि आपके कॉन्फ़िगरेशन में कोई समस्या है. इसकी वजह से, कैशिंग नहीं हो रही है. आम समस्याओं की जांच करने के लिए, इस सेक्शन को जारी रखें.

6. पक्का करें कि एक्ज़ीक्यूशन लॉग में मौजूद सभी कार्रवाइयों के लिए, cacheable की वैल्यू 'सही' पर सेट हो. अगर किसी कार्रवाई के लिए, एक्ज़ीक्यूशन लॉग में cacheable नहीं दिखता है, तो इसका मतलब है कि इससे जुड़े नियम की परिभाषा में, BUILD फ़ाइल में no-cache टैग हो सकता है. यह पता लगाने के लिए कि कार्रवाई कहां से हो रही है, एक्ज़ीक्यूशन लॉग में mnemonic और target_label फ़ील्ड देखें.

7. अगर कार्रवाइयां एक जैसी हैं और cacheable की वैल्यू 'सही' पर सेट है, लेकिन कोई कैश हिट नहीं है, तो हो सकता है कि आपकी कमांड लाइन में --noremote_accept_cached शामिल हो. इससे, किसी बिल्ड के लिए कैश लुकअप बंद हो जाएंगे.

   अगर असल कमांड लाइन का पता लगाना मुश्किल है, तो Build Event Protocol से कैननिकल कमांड लाइन का इस्तेमाल करें. इसके लिए, यह तरीका अपनाएं:

   a. लॉग का टेक्स्ट वर्शन पाने के लिए, अपने Bazel कमांड में --build_event_text_file=/tmp/bep.txt जोड़ें.

   b. लॉग का टेक्स्ट वर्शन खोलें और structured_command_line मैसेज के साथ command_line_label: "canonical" खोजें. इसमें, सभी विकल्पों को एक्सपैंड करने के बाद दिखाया जाएगा.

   c. remote_accept_cached खोजें और देखें कि इसकी वैल्यू false पर सेट है या नहीं.

   d. अगर remote_accept_cached की वैल्यू false पर सेट है, तो यह पता लगाएं कि इसे false पर कहां सेट किया गया है: कमांड लाइन पर या bazelrc फ़ाइल में.

पक्का करें कि अलग-अलग मशीनों पर कैशिंग हो

एक ही मशीन पर उम्मीद के मुताबिक कैश हिट जनरेट होने के बाद, उसी बिल्ड/टेस्ट को किसी दूसरी मशीन पर चलाएं. अगर आपको लगता है कि अलग-अलग मशीनों पर कैशिंग नहीं हो रही है, तो यह तरीका अपनाएं:

1. अपने बिल्ड में थोड़ा बदलाव करें, ताकि मौजूदा कैश हिट न हो.

2. पहली मशीन पर बिल्ड चलाएं:

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

3. दूसरी मशीन पर बिल्ड चलाएं. पक्का करें कि पहले चरण में किया गया बदलाव शामिल हो:

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

4. दोनों रन के एक्ज़ीक्यूशन लॉग की तुलना करें. अगर लॉग एक जैसे नहीं हैं, तो अपने बिल्ड कॉन्फ़िगरेशन में गड़बड़ियों की जांच करें. साथ ही, यह भी देखें कि होस्ट एनवायरमेंट की प्रॉपर्टी, किसी भी बिल्ड में लीक तो नहीं हो रही हैं.

एक्ज़ीक्यूशन लॉग की तुलना करना

एक्ज़ीक्यूशन लॉग में, बिल्ड के दौरान एक्ज़ीक्यूट की गई कार्रवाइयों के रिकॉर्ड होते हैं. हर रिकॉर्ड में, कार्रवाई के इनपुट (सिर्फ़ फ़ाइलें ही नहीं, बल्कि कमांड लाइन आर्ग्युमेंट, एनवायरमेंट वैरिएबल वगैरह भी) और आउटपुट, दोनों की जानकारी होती है. इसलिए, लॉग की जांच करके यह पता लगाया जा सकता है कि कोई कार्रवाई फिर से क्यों एक्ज़ीक्यूट की गई.

एक्ज़ीक्यूशन लॉग को तीन फ़ॉर्मैट में जनरेट किया जा सकता है: कॉम्पैक्ट (--execution_log_compact_file), बाइनरी (--execution_log_binary_file) या JSON (--execution_log_json_file). कॉम्पैक्ट फ़ॉर्मैट इस्तेमाल करने का सुझाव दिया जाता है, क्योंकि इससे बहुत छोटी फ़ाइलें जनरेट होती हैं और रनटाइम ओवरहेड बहुत कम होता है. नीचे दिए गए निर्देश, किसी भी फ़ॉर्मैट के लिए काम करते हैं. //src/tools/execlog:converter टूल का इस्तेमाल करके, इन्हें एक-दूसरे में बदला भी जा सकता है.

अगर आपको लगता है कि दो बिल्ड के लॉग में कैश हिट शेयर नहीं हो रहे हैं, तो यह तरीका अपनाएं:

1. हर बिल्ड से एक्ज़ीक्यूशन लॉग पाएं और उन्हें /tmp/exec1.log और /tmp/exec2.log के तौर पर सेव करें.

2. Bazel का सोर्स कोड डाउनलोड करें और //src/tools/execlog:parser टूल बनाएं:

   git clone https://github.com/bazelbuild/bazel.git cd bazel bazel build //src/tools/execlog:parser

3. लॉग को, मशीन से पढ़े जा सकने वाले टेक्स्ट फ़ॉर्मैट में बदलने के लिए, //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. `//src/tools/execlog:parser` टूल का इस्तेमाल करके, /tmp/exec1.log.txt और /tmp/exec2.log.txt की तुलना करें.