@TheLarkInn @mikegreiling @jschatz1
Do you want to request a feature or report a bug?
Unexpected Behavior
What is the current behavior?
We are unsure if this is a combination of both webpack and webpack-dev-server. So posting here first
The webpack-dev-server
process is a memory hog. As of Feb 22nd it is coming in at 751.9MB for the CE branch. This is after having removed the imports-loader
plugin in Issue 9123 and before this it was often as high as 850MB.
If the current behavior is a bug, please provide the steps to reproduce.
GitLab Issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/28557
This seems really excessive and we are trying to ascertain the root cause of it. This issue will serve as a place to discuss and chronicle our attempts to alleviate this memory footprint.
I think there are a few things worth trying:
- Try exempting
node_modules
withindevServer.watchOptions
(suggested by Kees Kluskens) - Test out this webpack PR meant to improve memory use (suggested by Kees Kluskens)
- Implement
CommonsChunkPlugin
to prevent multiple copies of Vue from being retained in memory - Reduce the number of babel plugins we use by replacing
babel-preset-es2015
withbabel-preset-env
(#28026)
What is the expected behavior?
That our dev server should not have such a large footprint
Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.
macOS – "webpack": "^2.2.1"
Can ask other people that use the GDK to tell us what their mem footprint is on Linux as well if need be.
Might be related to #2157
In our project the footprint is 400-500M. In nodejs world I think it is huge. We use only watch & rebuild and javascript files with imports
Wrong button! Whoops😂
@terencechow at @GitLab we saved a lot of memory by doing the following:
require.context()
exclude: /node_modules/
in all of our loadersinline-source-map
tocheap-module-eval-source-map
All that said, it still takes up a good chunk of memory, and the more of webpack/babel’s cool features and plugins you want to use, the more memory it will require. Thankfully when the process has been running a while on macOS, it tends to use compressed memory to reduce this burden a bit.
this is still a problem
@evilebottnawi I’ve copied the entire gitlab frontend and webpack config to https://gitlab.com/psimyn/gitlab-webpack-memory (also includes icons, images etc)
Heap snapshots are around ~1.3GB. The node-inspect command would OOM error unless I increased
--max_old_space_size
Not it is moved to dev server repo and will be solved in next release