mirror of
https://github.com/meteor/meteor.git
synced 2026-05-02 03:01:46 -04:00
document memory crashes troubleshotting
This commit is contained in:
@@ -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). We’re 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.
|
||||
|
||||
Reference in New Issue
Block a user