इस पेज पर, सीमित रैम के साथ Bazel को चलाने के लिए फ़्लैग इस्तेमाल करने का तरीका बताया गया है.
कुछ मामलों में, हो सकता है कि आपको Bazel के लिए कम से कम मेमोरी का इस्तेमाल करना पड़े. स्टार्टअप फ़्लैग --host_jvm_args की मदद से, ज़्यादा से ज़्यादा हीप सेट किया जा सकता है. जैसे, --host_jvm_args=-Xmx2g.
हालांकि, अगर आपके बिल्ड बड़े हैं, तो Bazel के पास पर्याप्त मेमोरी न होने पर, OutOfMemoryError (OOM) आ सकता है. नीचे दिए गए कमांड फ़्लैग पास करके, Bazel के लिए कम मेमोरी का इस्तेमाल किया जा सकता है. हालांकि, ऐसा करने पर, इंक्रीमेंटल बिल्ड की रफ़्तार कम हो जाएगी:
--discard_analysis_cache,
--nokeep_state_after_build, और --notrack_incremental_state.
इन फ़्लैग की मदद से, Bazel के लिए बिल्ड में इस्तेमाल होने वाली मेमोरी को कम किया जा सकेगा. हालांकि, ऐसा करने पर, आने वाले समय में बनने वाले बिल्ड की रफ़्तार, सामान्य इंक्रीमेंटल बिल्ड की तुलना में कम हो जाएगी.
इनमें से कोई भी फ़्लैग अलग-अलग पास किया जा सकता है:
--discard_analysis_cacheसे, एक्ज़ीक्यूशन के दौरान इस्तेमाल होने वाली मेमोरी कम हो जाएगी. हालांकि, इससे विश्लेषण के दौरान इस्तेमाल होने वाली मेमोरी कम नहीं होगी. इंक्रीमेंटल बिल्ड के लिए, पैकेज लोड करने की प्रोसेस को दोबारा करने की ज़रूरत नहीं होगी. हालांकि, विश्लेषण और एक्ज़ीक्यूशन की प्रोसेस को दोबारा करना होगा. हालांकि, डिस्क पर मौजूद ऐक्शन कैश की मदद से, ज़्यादातर री-एक्ज़ीक्यूशन को रोका जा सकता है.--notrack_incremental_stateसे, Bazel के इंटरनल डिपेंडेंसी ग्राफ़ में कोई भी एज सेव नहीं होगा. इसलिए, इसका इस्तेमाल इंक्रीमेंटल बिल्ड के लिए नहीं किया जा सकेगा. अगला बिल्ड, उस डेटा को मिटा देगा. हालांकि,--nokeep_state_after_buildके बारे में जानकारी न देने पर, इंटरनल डीबग करने के लिए, डेटा तब तक सेव रहेगा.--nokeep_state_after_buildसे, बिल्ड के बाद सारा डेटा मिट जाएगा. इसलिए, इंक्रीमेंटल बिल्ड को शुरू से ही बिल्ड करना होगा. हालांकि, डिस्क पर मौजूद ऐक्शन कैश को छोड़कर. इससे, मौजूदा बिल्ड के हाई-वॉटर मार्क पर कोई असर नहीं पड़ता.