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

समस्या की शिकायत करें सोर्स देखें

Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

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

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

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

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 की वैल्यू true पर सेट हो. अगर किसी कार्रवाई के लिए, एक्ज़ीक्यूशन लॉग में 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. /tmp/exec1.log.txt और /tmp/exec2.log.txt में अंतर देखने के लिए, अपने पसंदीदा टेक्स्ट डिफ़र का इस्तेमाल करें.