डाइनैमिक एक्ज़ीक्यूशन बेज़ल की एक सुविधा है, जहां लोकल और रिमोट तरीके से एक्ज़ीक्यूट किया जा सकता है पहली ब्रांच से मिले आउटपुट का इस्तेमाल करके, वही कार्रवाई साथ-साथ शुरू की जाती है जो दूसरी ब्रांच को रद्द कर देती है. यह एक साथ काम करने की कई सुविधाएं देता है. और/या लोकल बिल्ड सिस्टम की बड़ी शेयर की गई कैश मेमोरी यह प्रोग्राम, बेहतरीन तरीके से काम करने के साथ-साथ, एक जैसे.
इस पेज पर डाइनैमिक एक्ज़ीक्यूशन को चालू करने, ट्यून करने, और डीबग करने का तरीका बताया गया है. अगर आपको लोकल और रिमोट एक्ज़ीक्यूशन, दोनों को सेट अप किया गया हो और ऐसे में बेज़ल को अडजस्ट करने की कोशिश की जा रही हो सेटिंग की जानकारी देखें, तो यह पेज आपके लिए है. अगर आपने पहले से ऐसा नहीं किया है, तो रिमोट एक्ज़ीक्यूशन सेट अप हो गया है, Basel रिमोट एक्ज़ीक्यूशन पर जाएं खास जानकारी पहले देखें.
डाइनैमिक एक्ज़ीक्यूशन चालू हो रहा है?
डाइनैमिक एक्ज़ीक्यूशन मॉड्यूल बेज़ल का हिस्सा है, लेकिन यह डाइनैमिक का इस्तेमाल करने के लिए है प्रोग्राम चलाने के बाद, आपको पहले से ही स्थानीय और रिमोट तरीके से, पुराने वर्शन की सुविधा बंद कर दी है.
डाइनैमिक एक्ज़ीक्यूशन मॉड्यूल को चालू करने के लिए, --internal_spawn_scheduler को पास करें
फ़्लैग करने के लिए बेज़ल
को फ़्लैग करता है. ऐसा करने पर, प्लान लागू करने की नई रणनीति जुड़ जाती है, जिसका नाम dynamic है. अब ये काम किए जा सकते हैं
इसका इस्तेमाल अपनी रणनीति के तौर पर उन याद के विषयों के लिए करें जिन्हें आप डाइनैमिक तौर पर चलाना चाहते हैं, जैसे
--strategy=Javac=dynamic. याद रखने की कला चुनने का तरीका जानने के लिए, अगला सेक्शन देखें
ताकि डाइनैमिक एक्ज़ीक्यूशन चालू किया जा सके.
डाइनैमिक रणनीति का इस्तेमाल करने वाली किसी भी याद दिलाने के लिए, रिमोट तौर पर एक्ज़ीक्यूट करने की रणनीतियां
--dynamic_remote_strategy फ़्लैग से लिया गया है. साथ ही, स्थानीय रणनीतियों के बारे में भी बताया गया है
--dynamic_local_strategy फ़्लैग. पासिंग
--dynamic_local_strategy=worker,sandboxed, लोकल पर डिफ़ॉल्ट रूप से सेट करता है
डाइनैमिक एक्ज़ीक्यूशन की ब्रांच को
ऑर्डर. --dynamic_local_strategy=Javac=worker को पास करना,
और सिर्फ़ Javac मेनेमॉनिक के लिए उपलब्ध है. रिमोट वर्शन इसी तरह से काम करता है. दोनों फ़्लैग यह कर सकते हैं
कई बार तय किया जाना चाहिए. अगर किसी कार्रवाई को स्थानीय तौर पर लागू नहीं किया जा सकता है, तो
सामान्य तरीके से रिमोट तरीके से एक्ज़ीक्यूट किया जाता है. इसी तरह, रिमोट तरीके से भी लागू किया जाता है.
अगर आपके रिमोट सिस्टम में कैश मेमोरी है, तो --dynamic_local_execution_delay फ़्लैग
रिमोट सिस्टम के होने के बाद, लोकल एक्ज़ीक्यूशन में मिलीसेकंड में देरी होती है
ने कैश हिट दिखाया. इससे, ज़्यादा कैश मेमोरी हिट होने पर लोकल एक्ज़ीक्यूशन से बचा जा सकता है
बहुत कम संभावना है. डिफ़ॉल्ट तौर पर, वैल्यू 1000 मि॰से॰ होती है. हालांकि, इसे थोड़ा-बहुत सेट करना चाहिए
से ज़्यादा समय लगता है. असल समय, रिमोट पर निर्भर करता है
और दोतरफ़ा यात्रा में कितना समय लगता है. आम तौर पर, वैल्यू एक जैसी रहती है
किसी दिए गए रिमोट सिस्टम के सभी उपयोगकर्ताओं के लिए, जब तक कि उनमें से कुछ काफ़ी दूर न हों
दोतरफ़ा इंतज़ार का समय जोड़ने के लिए. Baze प्रोफ़ाइल की प्रोफ़ाइल बनाने की सुविधा का इस्तेमाल किया जा सकता है
सुविधाओं का इस्तेमाल करके देखा जा सकता है कि
कैश मेमोरी हिट मानी जाती हैं.
डाइनैमिक एक्ज़ीक्यूशन का इस्तेमाल, लोकल सैंडबॉक्स रणनीति के साथ-साथ
स्थायी कर्मचारी. जो लोग लगातार जुड़े हुए हैं वे अपने-आप काम करेंगे
डाइनैमिक एक्ज़ीक्यूशन के साथ इस्तेमाल होने पर सैंडबॉक्स की सुविधा के साथ चलाया जाता है. हालांकि, यह मल्टीप्लेक्स
कर्मचारी. डार्विन और Windows सिस्टम में, सैंडबॉक्स
रणनीति धीमी हो सकती है; तो --reuse_sandbox_directories को पास किया जा सकता है, ताकि
इन सिस्टम पर सैंडबॉक्स बनाने के अतिरिक्त खर्च को ट्रैक करते हैं.
डाइनैमिक एक्ज़ीक्यूशन को standalone रणनीति के साथ भी चलाया जा सकता है. हालांकि,
standalone रणनीति लागू करते समय, आउटपुट लॉक लेना ज़रूरी है. यह
असरदार तरीके से, रिमोट स्ट्रेटजी को पहले पूरा होने से रोकता है. कॉन्टेंट बनाने
--experimental_local_lockfree_output फ़्लैग इन चीज़ों से इस समस्या को हल करने में मदद करता है
लोकल एक्ज़ीक्यूशन को सीधे आउटपुट में लिखने की अनुमति देता है, लेकिन यह
रिमोट एक्ज़ीक्यूशन को, क्या पहले पूरा करना होगा.
अगर डाइनैमिक एक्ज़ीक्यूशन की कोई ब्रांच पहले पूरी हो जाती है, लेकिन वह पूरी नहीं हो पाती है, तो पूरी कार्रवाई नहीं की जा सकी. अंतर को रोकने के लिए यह एक सोच-समझकर चुना गया विकल्प है लागू होने से रोका जा सके.
डाइनैमिक एक्ज़ीक्यूशन और लॉक करने की सुविधा के काम करने के तरीके के बारे में ज़्यादा जानने के लिए, जूलियो से संपर्क करें मेरिनो का शानदार ब्लॉग पोस्ट
मुझे डाइनैमिक एक्ज़ीक्यूशन का इस्तेमाल कब करना चाहिए?
डाइनैमिक एक्ज़ीक्यूशन के लिए, किसी भी तरह के रिमोट एक्ज़ीक्यूशन सिस्टम की ज़रूरत होती है. फ़िलहाल, सिर्फ़ कैश मेमोरी में सेव किए गए रिमोट सिस्टम का इस्तेमाल नहीं किया जा सकता, क्योंकि कोई कैश मेमोरी उपलब्ध नहीं है ऐसी कार्रवाइयों को फ़ेल माना जाएगा.
रिमोट तरीके से एक्ज़ीक्यूट करने के लिए, सभी तरह की कार्रवाइयां सही नहीं होती हैं. सबसे अच्छी उम्मीदवार वे हैं जो स्थानीय रूप से स्वाभाविक रूप से तेज़ होते हैं, उदाहरण के लिए स्थायी कर्मचारियों या तेज़ी से काम करने वाले लोगों का इस्तेमाल करना इतना ही नहीं, एक्ज़ीक्यूशन के समय पर रिमोट एक्ज़ीक्यूशन का काम बढ़ जाता है. से स्थानीय तौर पर लागू की जाने वाली हर कार्रवाई, कुछ सीपीयू और मेमोरी रिसॉर्स को लॉक करती है, ऐसी कार्रवाइयां जो उन कैटगरी में नहीं आती हैं उनसे सिर्फ़ प्रोसेस को पूरा करने में देरी होती है काम में मदद मिलेगी.
रिलीज़ के समय
5.0.0-pre.20210708.4,
परफ़ॉर्मेंस प्रोफ़ाइलिंग में डेटा शामिल है
कर्मचारियों के काम करने के तरीके से जुड़ी जानकारी. इसमें काम के अनुरोध को पूरा करने में लगने वाला समय शामिल है
एक डाइनैमिक एक्ज़ीक्यूशन रेस में खो जाना. अगर आपको डाइनैमिक एक्ज़ीक्यूशन के वर्कर थ्रेड दिखते हैं
संसाधन हासिल करने में बहुत ज़्यादा समय बिताना या
async-worker-finish, आपके कुछ लोकल ऐक्शन की वजह से शायद कर्मचारियों को देरी हो रही है
थ्रेड.
ऊपर दी गई प्रोफ़ाइल में, जो 8 Javac वर्कर का इस्तेमाल करती है, हमें कई Javac वर्कर दिखते हैं
async-worker-finish में रेस हार गई और अपना काम पूरा किया
थ्रेड. ऐसा इसलिए हुआ, क्योंकि काम न करने वाले लोगों ने याद रखने के लिए ज़रूरी संसाधन इकट्ठा कर लिए थे
इससे ज़्यादा समय नहीं लगेगा.
जब सिर्फ़ Javac को डाइनैमिक एक्ज़ीक्यूशन के साथ चलाया जाता है, तो शुरू होने वाले ब्राउज़र का सिर्फ़ आधा हिस्सा काम शुरू करने के बाद, कर्मचारी रेस में हिस्सा नहीं ले पाते.
पहले सुझाए गए --experimental_spawn_scheduler फ़्लैग का इस्तेमाल नहीं किया जा सकता.
यह डाइनैमिक एक्ज़ीक्यूशन की सुविधा चालू करता है और dynamic को सभी के लिए डिफ़ॉल्ट रणनीति के तौर पर सेट करता है
याददाश्त बढ़ाने वाली तकनीक, जिससे अक्सर इस तरह की समस्याएं पैदा होती हैं.
परफ़ॉर्मेंस
डाइनैमिक एक्ज़ीक्यूशन के तरीके में यह माना जाता है कि ज़रूरत के मुताबिक संसाधन उपलब्ध हैं स्थानीय और दूर से भी काम कर रहे हैं और सेवाओं को बेहतर बनाने के लिए कुछ अतिरिक्त संसाधन खर्च किए जा सकते हैं परफ़ॉर्मेंस का डेटा इकट्ठा किया जा सकता है. हालांकि, संसाधनों का बहुत ज़्यादा इस्तेमाल करने से Basel की प्रोसेस धीमी हो सकती है या या रिमोट सिस्टम पर अनचाहा दबाव डालें. यहां हैं डाइनैमिक एक्ज़ीक्यूशन का व्यवहार बदलने के लिए कई विकल्प हैं:
--dynamic_local_execution_delay एक संख्या से स्थानीय शाखा की शुरुआत में देरी करता है
मिलीसेकंड के बाद, रिमोट ब्रांच के शुरू होने के बाद
वर्तमान बिल्ड के दौरान रिमोट कैश हिट होता है. इससे उपयोगकर्ताओं को यह फ़ायदा मिलता है
दूर से कैश मेमोरी में सेव करने से, स्थानीय संसाधनों की बर्बादी नहीं होती है. ऐसा तब होता है, जब इस बात की संभावना ज़्यादा हो कि
आउटपुट, कैश मेमोरी में मिल सकते हैं. कैश मेमोरी की क्वालिटी के हिसाब से,
इसे कम करने से, बिल्ड की स्पीड बढ़ सकती है. इसके लिए, आपको ज़्यादा लोकल कैश मेमोरी का इस्तेमाल करना होगा
संसाधन.
--experimental_dynamic_local_load_factor, एक्सपेरिमेंट के तौर पर उपलब्ध बेहतर संसाधन है
को मैनेज करने का विकल्प होता है. इस सुविधा को बंद करने के लिए, इसकी वैल्यू 0 से 1 के बीच होनी चाहिए.
जब इसकी वैल्यू 0 से ज़्यादा पर सेट की जाती है, तब Baज़र, कन्वर्ज़न की हर वैल्यू को
स्थानीय तौर पर शेड्यूल की गई कार्रवाइयाँ, जब कई कार्रवाइयाँ
शेड्यूल नहीं होगा. इसे 1 पर सेट करने पर, उतनी कार्रवाइयां शेड्यूल की जा सकती हैं जितनी कार्रवाइयां शेड्यूल की जा सकती हैं
क्या सीपीयू उपलब्ध हैं (--local_cpu_resources के हिसाब से). कम वैल्यू, संख्या सेट करती हैं
कार्रवाइयों की ज़्यादा संख्या को
चलाने के लिए उपलब्ध है. यह थोड़ा अजीब लग सकता है, लेकिन एक अच्छे रिमोट के साथ
सिस्टम, जब बहुत सी कार्रवाइयां चल रही होती हैं, तो लोकल एक्ज़ीक्यूशन से ज़्यादा मदद नहीं मिलती है और
लोकल सीपीयू बेहतर तरीके से काम करते हैं.
--experimental_dynamic_slow_remote_time, लोकल ब्रांच शुरू करने को प्राथमिकता देता है
जब रिमोट ब्रांच कम से कम इतने समय से चल रही हो. आम तौर पर
हाल ही में शेड्यूल की गई कार्रवाई को प्राथमिकता दी जाती है, क्योंकि इसके पास
दौड़ जीतने के बाद भी, लेकिन अगर रिमोट सिस्टम कभी-कभी रुक जाता है या ज़्यादा समय लगता है,
इससे आगे बढ़ने में मदद मिलती है. यह सुविधा डिफ़ॉल्ट रूप से चालू नहीं होती, क्योंकि यह
रिमोट सिस्टम की उन समस्याओं को छिपा सकता है जिन्हें ठीक करना चाहिए. पक्का करें कि
का उपयोग करें.
रिमोट को छोड़ने के लिए, --experimental_dynamic_ignore_local_signals का इस्तेमाल किया जा सकता है
जब किसी दिए गए सिग्नल की वजह से स्थानीय स्पॉन्स बाहर निकलता है, तो उस ब्रांच को टेकओवर किया जाता है. यह है
यह कामगार संसाधनों की सीमाओं के साथ मिलकर काम करता है (
--experimental_worker_memory_limit_mb
--experimental_worker_sandbox_hardening,
और
--experimental_sandbox_memory_limit_mb)),
जहां बहुत ज़्यादा संसाधनों का इस्तेमाल करने पर कर्मचारियों की प्रोसेस पर असर पड़ सकता है.
JSON ट्रेस प्रोफ़ाइल में की मदद से, परफ़ॉर्मेंस से जुड़े ग्राफ़ की मदद से, और संसाधनों के इस्तेमाल पर बुरा असर पड़ सकता है.
समस्या का हल
डाइनैमिक एक्ज़ीक्यूशन से जुड़ी समस्याएं मामूली और डीबग करने में मुश्किल हो सकती हैं, क्योंकि वे
मेनिफ़ेस्ट सिर्फ़ लोकल और रिमोट एक्ज़ीक्यूशन के कुछ खास कॉम्बिनेशन के तहत.
--debug_spawn_scheduler, डाइनैमिक एक्ज़ीक्यूशन से अतिरिक्त आउटपुट जोड़ता है
यह एक सिस्टम है जो इन समस्याओं को डीबग करने में मदद कर सकता है. आपको यह भी तय करना होगा कि
--dynamic_local_execution_delay फ़्लैग और रिमोट जॉब बनाम लोकल जॉब की संख्या
उसकी मदद से समस्याओं को आसानी से समझा जा सकता है.
अगर आपको standalone का इस्तेमाल करके, डाइनैमिक एक्ज़ीक्यूशन में समस्याएं आ रही हैं
रणनीति, --experimental_local_lockfree_output के बिना दौड़ने की कोशिश करें या दौड़ें
स्थानीय कार्रवाइयों को सैंडबॉक्स किया गया हो. इससे आपका बिल्ड थोड़ा धीमा हो सकता है (ऊपर देखें अगर
Mac या Windows पर काम करता है). हालांकि, यह फ़ेलियर की कुछ संभावित वजहों को हटा देता है.