इस पेज पर, सीमित रैम में Bazel चलाने के लिए फ़्लैग इस्तेमाल करने का तरीका बताया गया है.
कुछ मामलों में, हो सकता है कि आपको Bazel को कम से कम मेमोरी का इस्तेमाल करने के लिए कहना हो. --host_jvm_args=-Xmx2g जैसे स्टार्टअप फ़्लैग --host_jvm_args की मदद से, ज़्यादा से ज़्यादा हेप सेट किया जा सकता है.
हालांकि, अगर आपके बिल्ड काफ़ी बड़े हैं, तो हो सकता है कि Bazel के पास ज़रूरत के मुताबिक मेमोरी न होने पर, OutOfMemoryError
(ओवर ऑन मेमोरी) का मैसेज दिखे. 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, बिल्ड के बाद सारा डेटा मिटा देगा, ताकि इंक्रीमेंटल बिल्ड को फिर से शुरू से बिल्ड करना पड़े. हालांकि, डिस्क पर मौजूद ऐक्शन कैश मेमोरी को छोड़कर. सिर्फ़ इस वजह से, मौजूदा बिल्ड के हाई-वॉटर मार्क पर कोई असर नहीं पड़ता.