| --- | |
| layout: documentation | |
| title: Memory-saving Mode | |
| --- | |
| # Running Bazel with limited RAM | |
| In certain situations, you may want Bazel to use minimal memory. You can set the | |
| maximum heap via the startup flag | |
| [`--host_jvm_args`](user-manual.html#flag--host_jvm_args), | |
| like `--host_jvm_args=-Xmx2g`. | |
| However, if your builds are big enough, Bazel may throw an `OutOfMemoryError` | |
| (OOM) when it doesn't have enough memory. You can make Bazel use less memory, at | |
| the cost of slower incremental builds, by passing the following command flags: | |
| [`--discard_analysis_cache`](user-manual.html#flag--discard_analysis_cache), | |
| `--nokeep_state_after_build`, and `--notrack_incremental_state`. | |
| These flags will minimize the memory that Bazel uses in a build, at the cost of | |
| making future builds slower than a standard incremental build would be. | |
| You can also pass any one of these flags individually: | |
| * `--discard_analysis_cache` will reduce the memory used during execution (not | |
| analysis). Incremental builds will not have to redo package loading, but will | |
| have to redo analysis and execution (although the on-disk action cache can | |
| prevent most re-execution). | |
| * `--notrack_incremental_state` will not store any edges in Bazel's internal | |
| dependency graph, so that it is unusable for incremental builds. The next build | |
| will discard that data, but it is preserved until then, for internal debugging, | |
| unless `--nokeep_state_after_build` is specified. | |
| * `--nokeep_state_after_build` will discard all data after the build, so that | |
| incremental builds have to build from scratch (except for the on-disk action | |
| cache). Alone, it does not affect the high-water mark of the current build. |