MoveIt 2 colcon build RAM: Default Build Fails at 8GB, Sequential Peaks at 2.4GB (Measured)
Nav2 built fine at 8GB of RAM with default settings (Nav2 RAM measurement). Does MoveIt 2? I used the same method on MoveIt 2 (Jazzy branch, 41 packages) and built it five times under different memory caps. The result was different: the default build failed at 8GB.
Short answer
- Default settings (
colcon build) failed at 8GB. After 24 of 41 packages, the compiler was killed for running out of memory. At 4GB it stopped after 4 packages. - At 16GB it succeeded, peaking at 8.7GiB.
- A sequential build (
--parallel-workers 1+MAKEFLAGS=-j1) peaked at 2.4GiB and finished at both 8GB and 4GB. - Counting what the OS, browser and IDE use, a default MoveIt 2 build needs 16GB. On an 8GB laptop, the sequential build is effectively the only option.
Test setup
Same as for Nav2. A 4 vCPU, 16GB Linux server (AWS Lightsail). Each build ran in a Docker container with a memory cap and swap disabled (--memory-swap equal to --memory), so “success” means it fit in RAM. Image: ros:jazzy (digest 066420e07f60…); MoveIt 2 jazzy branch at commit e34dffb0. Peak memory was read from the container cgroup’s memory.peak.
| Setting | RAM cap | Result | Peak memory |
|---|---|---|---|
| Default (4 workers × make -j4) | 16GiB | Success (41/41) | 8.7GiB |
| Default | 8GiB | Failed: cc1plus killed, stopped after 24 packages | 8.0GiB (cap) |
| Default | 4GiB | Failed: cc1plus killed, stopped after 4 packages | 4.0GiB (cap) |
| Sequential (1 worker × make -j1) | 8GiB | Success (41/41) | 2.4GiB |
| Sequential | 4GiB | Success (41/41) | 2.4GiB |
Side by side with Nav2
| Nav2 (45 packages) | MoveIt 2 (41 packages) | |
|---|---|---|
| Default, peak at 16GiB | 8.1GiB | 8.7GiB |
| Default, 8GiB cap | Success | Failed |
| Sequential, peak | 2.7GiB | 2.4GiB |
MoveIt 2 has fewer packages, but the compilers running at the same time under default settings needed more than 8GB together. A sequential build compiles one file at a time, so both projects stay in the 2GiB range. “8GB is enough for ROS 2” holds for Nav2, and stops holding once you build MoveIt 2 from source.
Reading the numbers
memory.peakincludes page cache. The 8.7GiB at 16GB includes cache that was used only because memory was free. Still, at 8GB the compiler was killed even though the kernel could drop cache. What a default build truly needs is more than 8GiB.- Treat build times as rough. The default build at 16GB took 1h37m; sequential builds took 1h56m–1h57m. The server was a burstable instance using CPU credits, so it may have been throttled. On a PC running at full speed, the gap between sequential and default builds will be larger.
- Core count changes the result. Under default settings, the number of compilers running at once is roughly workers × make -j. An 8- or 16-core PC will use more RAM for the same MoveIt 2 default build.
On an 8GB laptop
My laptop is a 2020 Intel 13-inch MacBook Pro (4 cores, 8GB RAM). The measurements were done on the Linux server above; I did not build MoveIt 2 on the Mac itself. But the server also had 4 cores and the default build failed under an 8GB cap, so on this machine, which also has to fit the OS, I use the sequential build.
MAKEFLAGS="-j1" colcon build --parallel-workers 1If you don’t need to modify MoveIt 2, install the binaries with sudo apt install ros-jazzy-moveit instead of building from source. A sequential build trades time for memory; skipping the build is fastest.
If you’re buying or upgrading
- New laptop: to build MoveIt 2 from source, 16GB is the minimum. With 8 or more cores, default builds run more compilers at once, so 32GB is more comfortable.
- Upgrading your current laptop: if it has a RAM slot, a 16GB module is the cheapest fix. Check whether it takes DDR4 or DDR5 SO-DIMM first. Laptops with soldered RAM (LPDDR, MacBooks) can’t be upgraded, so use the sequential build or binary install.
Reproduce it
The measurement script (measure.sh) and the raw results from all five runs (results.tsv and per-setting build logs) are in the public experiment folder. On Linux with Docker, bash measure.sh runs the same sequence again.