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

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

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

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

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_binary_file=/tmp/exec1.log

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

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

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

    अगर आपको एक्ज़ीक्यूशन लॉग में अंतर नहीं देखना है, तो इसके बजाय, --execution_log_json_file फ़्लैग का इस्तेमाल किया जा सकता है. इससे, लॉग को आसानी से पढ़ा जा सकता है. इसका इस्तेमाल, स्थिर अंतर देखने के लिए नहीं किया जा सकता, क्योंकि इसमें एक्ज़ीक्यूशन का समय शामिल होता है. साथ ही, यह क्रम की गारंटी नहीं देता.

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

  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_binary_file=/tmp/exec1.log
  3. दूसरी मशीन पर बिल्ड चलाएं. पक्का करें कि पहले चरण में किया गया बदलाव शामिल हो:

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

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

एक्ज़ीक्यूशन लॉग में, बिल्ड के दौरान एक्ज़ीक्यूट की गई सभी कार्रवाइयों के रिकॉर्ड होते हैं. हर कार्रवाई के लिए, एक SpawnExec एलिमेंट होता है. इसमें ऐक्शन की से जुड़ी सारी जानकारी होती है. इसलिए, अगर लॉग एक जैसे हैं, तो ऐक्शन कैश की भी एक जैसी होंगी.

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

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

  2. Bazel का सोर्स कोड डाउनलोड करें और नीचे दिए गए कमांड का इस्तेमाल करके, Bazel फ़ोल्डर पर जाएं. execlog पार्सर की मदद से, एक्ज़ीक्यूशन लॉग को पार्स करने के लिए, सोर्स कोड की ज़रूरत होती है .

    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 में अंतर देखने के लिए, अपने पसंदीदा टेक्स्ट डिफ़र का इस्तेमाल करें.

जब तक कुछ अलग से न बताया जाए, तब तक इस पेज की सामग्री को Creative Commons Attribution 4.0 License के तहत और कोड के नमूनों को Apache 2.0 License के तहत लाइसेंस मिला है. ज़्यादा जानकारी के लिए, Google Developers साइट नीतियां देखें. Oracle और/या इससे जुड़ी हुई कंपनियों का, Java एक रजिस्टर किया हुआ ट्रेडमार्क है.

आखिरी बार 2026-05-07 (UTC) को अपडेट किया गया.