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

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

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

कैश मेमोरी का हिट रेट देखना

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 शामिल हो, जो किसी बिल्ड के लिए कैश लुकअप बंद कर देगा.

   अगर असल कमांड लाइन को समझना मुश्किल है, तो बिल्ड इवेंट प्रोटोकॉल से कैननिकल कमांड लाइन का इस्तेमाल इस तरह करें:

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

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

   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. diff /tmp/exec1.log.txt और /tmp/exec2.log.txt के लिए, अपने पसंदीदा टेक्स्ट differ का इस्तेमाल करें.