इस पेज पर, कैश मेमोरी में डेटा मौजूद होने की दर देखने का तरीका बताया गया है. साथ ही, रिमोट तौर पर प्रोसेस करने के मामले में, कैश मेमोरी में डेटा मौजूद न होने की जांच करने का तरीका भी बताया गया है.
इस पेज पर यह माना गया है कि आपके पास एक ऐसा बिल्ड और/या टेस्ट है जो रिमोट रनटाइम का इस्तेमाल करता है. साथ ही, आपको यह पक्का करना है कि रिमोट कैश मेमोरी का सही तरीके से इस्तेमाल किया जा रहा है.
कैश मेमोरी में डेटा के ऐक्सेस होने की दर देखना
Bazel रन के स्टैंडर्ड आउटपुट में, INFO
लाइन देखें. इसमें ऐसी प्रोसेस की सूची होती है जो काफ़ी हद तक Bazel ऐक्शन से मिलती-जुलती होती हैं. उस लाइन में यह जानकारी होती है कि कार्रवाई कहां से शुरू की गई थी. remote
लेबल देखें, जो किसी कार्रवाई के रिमोट तौर पर होने का संकेत देता है. linux-sandbox
, किसी स्थानीय सैंडबॉक्स में की गई कार्रवाइयों के लिए है. साथ ही, कार्रवाइयों को लागू करने की अन्य रणनीतियों के लिए अन्य वैल्यू भी हैं. जिस ऐक्शन का नतीजा किसी रिमोट कैश मेमोरी से मिला है उसे remote cache hit
के तौर पर दिखाया जाता है.
उदाहरण के लिए:
INFO: 11 processes: 6 remote cache hit, 3 internal, 2 remote.
इस उदाहरण में, छह रिमोट कैश मेमोरी हिट थे. साथ ही, दो कार्रवाइयों में कैश मेमोरी हिट नहीं थे और उन्हें रिमोट से चलाया गया था. तीसरे इंटरनल पार्ट को अनदेखा किया जा सकता है.
आम तौर पर, यह छोटी-मोटी इंटरनल कार्रवाइयां होती हैं, जैसे कि सिंबल लिंक बनाना. इस खास जानकारी में, लोकल कैश मेमोरी में सेव किए गए हिट शामिल नहीं किए जाते. अगर आपको 0 प्रोसेस (या उम्मीद से कम संख्या) मिल रही है, तो bazel clean
के बाद अपना बिल्ड/टेस्ट कमांड चलाएं.
कैश मेमोरी में डेटा सेव होने की समस्या हल करना
अगर आपको कैश मेमोरी में डेटा सेव होने की दर (हिट रेट) उम्मीद के मुताबिक नहीं मिल रही है, तो यह तरीका अपनाएं:
पक्का करें कि उसी बिल्ड/टेस्ट कमांड को फिर से चलाने पर, कैश मेमोरी में हिट मिले
वे बिल्ड और/या टेस्ट चलाएं जिनसे आपको कैश मेमोरी में डेटा भरने की उम्मीद है. किसी स्टैक पर पहली बार नया बिल्ड चलाने पर, आपको कोई रिमोट कैश मेमोरी हिट नहीं मिल सकता. रिमोट तरीके से कार्रवाइयां करने की सुविधा के तहत, कार्रवाइयों के नतीजे कैश मेमोरी में सेव किए जाते हैं. इसके बाद, अगली बार कार्रवाइयां करने पर, ये नतीजे अपने-आप दिखने लगते हैं.
bazel clean
चलाएं. यह कमांड आपके लोकल कैश मेमोरी को मिटा देता है. इससे, आपको रिमोट कैश मेमोरी में किए गए हिट की जांच करने में मदद मिलती है. ऐसा करने पर, लोकल कैश मेमोरी में किए गए हिट के नतीजे नहीं दिखते.जिन बिल्ड और टेस्ट की जांच की जा रही है उन्हें फिर से चलाएं (एक ही मशीन पर).
कैश मेमोरी में हिट होने की दर देखने के लिए,
INFO
लाइन देखें. अगर आपकोremote cache hit
औरinternal
के अलावा कोई प्रोसेस नहीं दिखती है, तो इसका मतलब है कि आपके कैश मेमोरी में डेटा सही तरीके से भर रहा है और उसे ऐक्सेस किया जा रहा है. ऐसे में, अगले सेक्शन पर जाएं.अंतर की वजह यह हो सकती है कि बिल्ड में कोई ऐसी चीज़ मौजूद है जो पूरी तरह से सुरक्षित नहीं है. इस वजह से, दोनों रन में कार्रवाइयों को अलग-अलग ऐक्शन बटन मिलते हैं. उन कार्रवाइयों को ढूंढने के लिए, यह तरीका अपनाएं:
a. एक्सीक्यूशन लॉग पाने के लिए, जिन बिल्ड या टेस्ट में समस्या है उन्हें फिर से चलाएं:
bazel clean
bazel --optional-flags build //your:target --execution_log_binary_file=/tmp/exec1.log
b. दो रन के बीच एक्सीक्यूशन लॉग की तुलना करें. पक्का करें कि दोनों लॉग फ़ाइलों में कार्रवाइयां एक जैसी हों. अंतर से, एक सेशन से दूसरे सेशन के बीच हुए बदलावों के बारे में पता चलता है. इन अंतर को खत्म करने के लिए, अपना बिल्ड अपडेट करें.
अगर कैश मेमोरी से जुड़ी समस्याएं हल हो जाती हैं और अब बार-बार चलाने पर सभी कैश हिट मिलते हैं, तो अगले सेक्शन पर जाएं.
अगर आपके ऐक्शन आईडी एक जैसे हैं, लेकिन कोई कैश हिट नहीं है, तो आपके कॉन्फ़िगरेशन में कुछ ऐसा है जिसकी वजह से कैश मेमोरी में सेव नहीं हो पा रहा है. आम तौर पर आने वाली समस्याओं की जांच करने के लिए, इस सेक्शन को पढ़ें.
अगर आपको एक्सीक्यूशन लॉग की तुलना करने की ज़रूरत नहीं है, तो इसके बजाय,
--execution_log_json_file
फ़्लैग का इस्तेमाल किया जा सकता है. इसका इस्तेमाल, स्थिर डिफ़रेंस के लिए नहीं किया जा सकता, क्योंकि इसमें प्रोसेस करने में लगने वाला समय शामिल होता है और ऑर्डर की गारंटी नहीं दी जाती.देखें कि एक्सीक्यूशन लॉग में मौजूद सभी कार्रवाइयों के लिए,
cacheable
को 'सही' पर सेट किया गया हो. अगर किसी ऐक्शन के लिए, एक्सीक्यूशन लॉग में नहीं दिखता है, तो इसका मतलब है कि उससे जुड़े नियम मेंBUILD
फ़ाइल की परिभाषा मेंno-cache
टैग हो सकता है.cacheable
यह पता लगाने के लिए कि कार्रवाई कहां से आ रही है, एक्सीक्यूशन लॉग में ऐसाprogress_message
फ़ील्ड देखें जिसे इंसान पढ़ सके.अगर कार्रवाइयां एक जैसी और
cacheable
हैं, लेकिन कोई कैश हिट नहीं है, तो हो सकता है कि आपकी कमांड लाइन में--noremote_accept_cached
शामिल हो, जो किसी बिल्ड के लिए कैश लुकअप बंद कर देगा.अगर असल कमांड लाइन का पता लगाना मुश्किल है, तो बिल्ड इवेंट प्रोटोकॉल की कैननिकल कमांड लाइन का इस्तेमाल करें. इसके लिए, यह तरीका अपनाएं:
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 फ़ाइल में.
सभी मशीनों पर कैश मेमोरी का इस्तेमाल करना
जब एक ही मशीन पर कैश हिट उम्मीद के मुताबिक होने लगें, तो एक ही बिल्ड/टेस्ट को किसी दूसरी मशीन पर चलाएं. अगर आपको लगता है कि सभी मशीनों पर कैश मेमोरी का इस्तेमाल नहीं हो रहा है, तो ये करें:
मौजूदा कैश मेमोरी का इस्तेमाल न करने के लिए, अपने बिल्ड में थोड़ा बदलाव करें.
पहली मशीन पर बिल्ड चलाएं:
bazel clean
bazel ... build ... --execution_log_binary_file=/tmp/exec1.log
दूसरी मशीन पर बिल्ड चलाएं. साथ ही, पक्का करें कि पहले चरण में किया गया बदलाव शामिल हो:
bazel clean
bazel ... build ... --execution_log_binary_file=/tmp/exec2.log
दोनों रन के लिए, एक्सीक्यूशन लॉग की तुलना करें. अगर लॉग एक जैसे नहीं हैं, तो अंतर के लिए अपने बिल्ड कॉन्फ़िगरेशन की जांच करें. साथ ही, होस्ट एनवायरमेंट की प्रॉपर्टी, दोनों बिल्ड में लीक हो रही हैं या नहीं, यह भी देखें.
एक्ज़ीक्यूशन लॉग की तुलना करना
एक्सीक्यूशन लॉग में, बिल्ड के दौरान की गई सभी कार्रवाइयों के रिकॉर्ड होते हैं. हर ऐक्शन के लिए एक SpawnExec एलिमेंट होता है, जिसमें ऐक्शन कुंजी की सारी जानकारी होती है. इसलिए, अगर लॉग एक जैसे हैं, तो ऐक्शन कैश मेमोरी कुंजियां भी एक जैसी होंगी.
उम्मीद के मुताबिक कैश मेमोरी हिट शेयर न करने वाले दो बिल्ड के लॉग की तुलना करने के लिए, यह तरीका अपनाएं:
हर बिल्ड से, प्रोग्राम के चलने के लॉग पाएं और उन्हें
/tmp/exec1.log
और/tmp/exec2.log
के तौर पर सेव करें.Bazel का सोर्स कोड डाउनलोड करें और नीचे दिए गए कमांड का इस्तेमाल करके, Bazel फ़ोल्डर पर जाएं. execlog parser की मदद से, प्रोग्राम के रन होने के लॉग को पार्स करने के लिए, आपको सोर्स कोड की ज़रूरत होगी.
git clone https://github.com/bazelbuild/bazel.git cd bazel
लॉग को टेक्स्ट में बदलने के लिए, एक्सीक्यूशन लॉग पार्सर का इस्तेमाल करें. नीचे दिए गए उदाहरण में, दूसरे लॉग में मौजूद कार्रवाइयों को क्रम से लगाया गया है, ताकि तुलना करने में आसानी हो. ऐसा इसलिए किया गया है, ताकि पहले लॉग में मौजूद कार्रवाइयों के क्रम से मेल खा सके.
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
diff
/tmp/exec1.log.txt
और/tmp/exec2.log.txt
के लिए, अपने पसंदीदा टेक्स्ट differ का इस्तेमाल करें.