document memory crashes troubleshotting

This commit is contained in:
Nacho Codoñer
2026-01-29 15:21:27 +01:00
parent fdd61584b0
commit d1bcb63cfe

View File

@@ -841,6 +841,38 @@ This limitation only applies to Blaze. Any other modern project will work with H
If you run into issues, try `meteor reset` or delete the `.meteor/local` and `_build` folders in the project root.
For help or to report issues, post on [GitHub](https://github.com/meteor/meteor/issues) or the [Meteor forums](https://forums.meteor.com). Were focused on making Meteor faster and your feedback helps.
For help or to report issues, post on [GitHub](https://github.com/meteor/meteor/issues) or the [Meteor forums](https://forums.meteor.com). We're focused on making Meteor faster and your feedback helps.
You can compare performance before and after enabling `modern` by running [`meteor profile`](../../cli/index.md#meteorprofile). Share your results to show progress to others.
### Memory Crashes
Large apps are more likely to hit memory limits during Meteor-Rspack builds, but this can also happen on smaller projects depending on the number of dependencies, cache size, and available system memory. If you experience crashes or out-of-memory errors, it's likely that the Rspack child process is running out of heap memory.
A common first reaction is to set [`TOOL_NODE_FLAGS`](../../cli/environment-variables.md#tool-node-flags)` (`TOOL_NODE_FLAGS="--max-old-space-size=8192"`), but this flag is mainly for the Meteor tool's own Node.js process at startup. Rspack runs as a spawned child process and may not inherit it.
Instead, use the standard `NODE_OPTIONS` environment variable, which Node.js propagates to child processes:
```bash
NODE_OPTIONS="--max-old-space-size=16384" meteor run
```
This raises the heap limit for the Rspack process and should reduce how often memory-related crashes occur. Adjust the value according to your machine's available memory.
:::info
For the Meteor 3.4.x series, as `NODE_OPTIONS` is confirmed to help, one option being considered is to automatically inherit memory settings from `TOOL_NODE_FLAGS` into the spawned Rspack process.
:::
Another approach is to disable Rspack's persistent cache, which is enabled by default and can be memory-intensive. See the [Cache](#cache) migration topic to disable it:
```js
const { defineConfig } = require('@meteorjs/rspack');
module.exports = defineConfig(Meteor => ({
...Meteor.setCache(false),
}));
```
You can combine both solutions: raise the heap limit with `NODE_OPTIONS` and disable persistent cache to reduce overall memory pressure.
Rspack itself has reported plans to optimize persistent cache and overall RAM consumption in [Rspack 2.0](https://rspack.rs/misc/planning/roadmap), which should improve memory behavior in future Meteor-Rspack releases.