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

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

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

कैश मेमोरी में डेटा के ऐक्सेस होने की दर देखना

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

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

    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 पर कहां सेट किया जा रहा है: कमांड लाइन पर या bazzrc फ़ाइल में.

सभी मशीनों पर कैश मेमोरी का इस्तेमाल करना

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

  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. नीचे दिए गए निर्देश का इस्तेमाल करके, Basel सोर्स कोड डाउनलोड करें और Basel फ़ोल्डर पर जाएं. execlog parser की मदद से, प्रोग्राम के रन होने के लॉग को पार्स करने के लिए, आपको सोर्स कोड की ज़रूरत होगी.

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