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

किसी समस्या की शिकायत करें सोर्स देखें 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. लॉग का टेक्स्ट वर्शन पाने के लिए, अपने Bazel कमांड में --build_event_text_file=/tmp/bep.txt जोड़ें.

    b. लॉग का टेक्स्ट वर्शन खोलें और structured_command_linecommand_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 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 का इस्तेमाल करें.