[Bug]: memory leak problem
Version
System:
OS: macOS 13.5
CPU: (10) x64 Apple M2 Pro
Memory: 23.32 MB / 16.00 GB
Shell: 5.9 - /bin/zsh
Browsers:
Chrome: 135.0.7049.115
Safari: 16.6
npmPackages:
@rsbuild/core: ^1.3.9 => 1.3.9
Details
When saving Vue or config files in the project using cmd+s, Rsbuild restarts and subsequently increases the memory usage of the rsbuild-node process. This memory increase is significant and correlates with the size of the project. For instance, with an initial project size of approximately 1.9GB, each save operation typically results in an additional 0.5GB of memory usage. This issue is particularly severe, as it can lead to insufficient memory on my development machine after just 15 saves, severely impacting the development experience.
Steps to Reproduce
- Open the project in a code editor (e.g., Cursor, because I found this problem in Cursor).
- Make changes to any Vue or config file within the project.(Actually no file changed is also ok to review this problem)
- Save the file using cmd+s.
- Observe the memory usage of the rsbuild-node process in the Activity Monitor or using the top command in the terminal.
- Repeat steps 2-3 multiple times and monitor the memory usage.
Expected Behavior The memory usage of the rsbuild-node process should remain stable and not increase significantly with each save operation. (I try vite or webpack and found it will not increase the memory usage)
Reproduce link
https://github.com/karlsbeard/rsbuld-memory-leak#
Reproduce Steps
- run
pnpm i - run
pnpm dev - go into anyone vue page or rsbuild.config.ts file
- open the activity monitor in mac os
- view the rsbuild-node memory usage which link to the demo repo
@quininer cc~
I believe we have recently fixed part of this issue (https://github.com/web-infra-dev/rspack/commit/6362a790f5487466eccf723c1dec9fc5a81d629c and https://github.com/web-infra-dev/rspack/commit/d71a6ab6c23f7bab2712fa0d191094c8d2fd26bd), and I will continue to investigate the remaining memory growth causes.
I believe we have recently fixed part of this issue (web-infra-dev/rspack@6362a79 and web-infra-dev/rspack@d71a6ab), and I will continue to investigate the remaining memory growth causes.
Thanks a lot.
I believe we have recently fixed part of this issue (web-infra-dev/rspack@6362a79 and web-infra-dev/rspack@d71a6ab), and I will continue to investigate the remaining memory growth causes.
"What's more, I found that version 1.3.9 performs better than version 1.1.6 or other versions in terms of memory leak issues, so I believe we have partially fixed this problem. However, the memory leak problem still remains, and I hope we can fix it as soon as possible.
I also want to ask about another issue: the memory usage of rsbuild should increase and then decrease later. Is this the expected behavior? In the 0.x versions, I observed that memory usage increases when I press Cmd+S(save) on any file, and it decreases later, but the overall trend shows an increase."
the memory usage of rsbuild should increase and then decrease later
I think this is because of the behavior of mimalloc , which doesn't return memory immediately. and some objects are held by js, which will also cause this behavior.
I counted the resident memory between each rebuild. I think that after previous fix, there is no strict leak in rspack rust code in this case. but we still have some memory growth.
As shown in the figure, the pink part is the memory that increases between each round of rebuild, and the purple part is regex.
Our growth between rounds mainly comes from three parts:
- The capacity of dashmap. dashmap uses shard buckets to support parallelism. Even if capacity is sufficient, memory allocation will occur because keys are assigned to different buckets.
- regex cache. regex crate will store cache locally in thread. If we schedule regex tasks evenly on each thread, each thread will eventually have a regex cache. see https://github.com/rust-lang/regex/issues/1214
- js object holds memory. this memory will be released when the js object is gc'ed, not when rebuild. So it may just be accumulated because of gc.
I believe the leak you originally encountered in this repro has been fixed. If you are still able to reproduce leak, please update. I will continue to monitor this type of issue.
@rsbuild/core": "1.5.6" still has significant memory leak issues.
@chenjiahan @quininer
@T9-Forever Did you reproduce it on 1.5.6 using the repro above?