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

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

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

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

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

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

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

इस उदाहरण में 6 रिमोट कैश हिट थे और 2 कार्रवाइयों में ऐसा नहीं था कैश मेमोरी हिट को एक्सपोर्ट किया गया और उन्हें दूर से ही एक्ज़ीक्यूट किया गया. तीन अंदरूनी हिस्से को अनदेखा किया जा सकता है. आम तौर पर, इसमें अंदरूनी कार्रवाइयां बहुत छोटी होती हैं. जैसे, सिंबल के तौर पर लिंक बनाना. इस खास जानकारी में, लोकल कैश मेमोरी में सेव किए गए हिट शामिल नहीं किए जाते. अगर आपको 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. ये फ़ाइलें पाने के लिए, --build_event_text_file=/tmp/bep.txt को अपने Basel कमांड में जोड़ें लॉग का टेक्स्ट वर्शन.

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

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

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

यह पक्का करें कि सभी मशीनों को कैश मेमोरी में सेव किया जा रहा हो

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

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. Basel सोर्स कोड डाउनलोड करें और //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 का इस्तेमाल करें.