-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Out of memory building larger project #259
Comments
Would you verify if this issue is still reproducable after the changes in the seed? |
I apologize for opening this issue back up, but I'm facing a similar issue with the latest release and with the project in master. @briantopping were you able to identify and fix the issue on your end? |
@rrjohnson85 - Your project doesn't happen to be public does it? It would save a ton of time reproducing the issue. |
@d3viant0ne No, my project is private. I'm currently experimenting with memory limits to see if that helps at all. Also, the initial build works fine so far. The problem appears whenever I make a change and a new build happens. |
What OS / Version? Problem Does is matter if you are changing a style sheet, or code? |
I'm on Windows 10 with 16GB of DDR4 memory. I'm using Node 4.2.6 and npm 2.14.7.
In my tests, I see the issue changing a TS or HTML file. I haven't tried changing stylesheets yet. I've also tried disabling sourcemaps in the build.js.dev task, and it doesn't seem to at all.
No, I've only added a few dependencies (angular2-jwt) and changed the app_title in the project config.
Yes, I think so. I cloned the seed project today from master at roughly 8am EST. |
Also, a colleague of mine tried upgrading on a MacBook Air, 8GB of memory, and same Node/npm versions. They see the same issue. |
I have a few ideas where the problem could be but it's going to take a while to add enough content to my seed fork to reproduce the issue. Give me a few hours |
Great, thanks! If there is anything else that you need, short of my source code, just let me know. |
@rrjohnson85 Have you tried to extend Node memory limit (limited to 1Go on x64 systems if I'm right) ? |
@ludohenin Thanks, changing
However, any idea why this is necessary? I don't have any issues using the beta3 version of the seed with the same project. Is the problem with recent Angular2 beta versions and not the seed, or is it a combination of the two? I also found the following issue that makes me wonder, angular/angular#5229. |
Also the initial build takes roughly 15 seconds, but I've subsequent builds take anywhere from 15 seconds to 1.5 minutes (just build.js.dev, not TSLint, CSS, etc.). Memory usage seems to increase slightly each time as well. |
This is a kind of odd "node" thing. Took me forever to reproduce. Started on 5.6 and no matter what I did, to include leaning the memory out to something comically low, it still worked. I had to try it on an old windows laptop with a non-ssd drive running node4-lts. The combination of the reduced write speed adding pressure + less system resources in general and I could get it to tank. To your question: Node doesn't automatically "tune" memory on the fly and the default setting isn't exactly realistic for day to day development much less production. @mgechev @ludohenin - We should probably add a comment somewhere related to node & memory. |
To your second comment, yes we are leaking memory somewhere. I'm into running down exactly where right now. |
@d3viant0ne definitely it's worth it to add a comment. It could be caused by the incremental tsc build or ts-node itself while running the different tasks. I think it makes sense to be a typescript related issue. |
@mgechev - Haven't figured out where yet though I'm pretty sure it's not code in the seed itself. Profile of repeating changes after adding a bunch of components to increase the compile/watch load |
TSC is probably a pretty good guess, i'm not going to go much further than this. I was initially worried about the array we are passing to browser-sync. |
@d3viant0ne Thanks for taking the time to look into this issue, I know it wasn't easy to do. Regarding TSC being the problem, I'm not entirely convinced. I've reverted to older versions of the TypeScript & TSLint packages that are presently working fine for us in the beta3 release of the seed, and I'm seeing the same issues. To test this, I had to remove a few options in tsconfig.json and change the rulesDirectory option to a string in tslint.json for ng2lint. The updated package.json is as follows: {
"name": "othot-platform-app",
"version": "0.1.8",
"description": "App for the Othot Platform",
"engines": {
"node": "4.2.6",
"npm": "2.14.12"
},
"repository": {
"type": "git",
"url": "git://github.com/OThot/othot-platform-app.git"
},
"scripts": {
"build.dev": "gulp build.dev",
"build.dev.watch": "gulp build.dev.watch",
"build.e2e": "gulp build.e2e",
"build.prod": "gulp build.prod",
"build.test": "gulp build.test",
"build.test.watch": "gulp build.test.watch",
"docs": "npm run gulp -- build.docs && npm run gulp -- serve.docs",
"e2e": "protractor",
"e2e.live": "protractor --elementExplorer",
"gulp": "gulp",
"karma": "karma",
"karma.start": "karma start",
"postinstall": "typings install && gulp check.versions && npm prune",
"reinstall": "npm cache clean && git clean -dfx -e '.*' && npm install",
"serve.coverage": "remap-istanbul -b src/ -i coverage/coverage-final.json -o coverage -t html && npm run gulp -- serve.coverage",
"serve.dev": "gulp serve.dev",
"serve.e2e": "gulp serve.e2e",
"start": "gulp serve.dev",
"tasks.list": "gulp --tasks-simple",
"test": "gulp test",
"webdriver-start": "webdriver-manager start",
"webdriver-update": "webdriver-manager update"
},
"author": "Minko Gechev <mgechev>",
"license": "MIT",
"devDependencies": {
"async": "^1.4.2",
"autoprefixer": "^6.3.3",
"browser-sync": "~2.10.1",
"chalk": "^1.1.1",
"colorguard": "^1.0.1",
"connect": "^3.4.1",
"connect-history-api-fallback": "^1.1.0",
"connect-livereload": "^0.5.3",
"cssnano": "^3.5.2",
"doiuse": "^2.3.0",
"event-stream": "^3.3.2",
"express": "~4.13.1",
"extend": "^3.0.0",
"gulp": "^3.9.0",
"gulp-cached": "^1.1.0",
"gulp-concat": "^2.5.2",
"gulp-filter": "^4.0.0",
"gulp-inject": "^3.0.0",
"gulp-inline-ng2-template": "^1.1.0",
"gulp-load-plugins": "^1.2.0",
"gulp-plumber": "~1.1.0",
"gulp-postcss": "^6.1.0",
"gulp-sass": "^2.2.0",
"gulp-shell": "~0.5.2",
"gulp-sourcemaps": "git+https://github.com/floridoo/gulp-sourcemaps.git#master",
"gulp-template": "^3.0.0",
"gulp-tslint": "^3.3.0",
"gulp-tslint-stylish": "^1.0.4",
"gulp-typedoc": "^1.2.1",
"gulp-typescript": "~2.8.2",
"gulp-uglify": "^1.2.0",
"gulp-util": "^3.0.7",
"gulp-watch": "^4.2.4",
"isstream": "^0.1.2",
"jasmine-core": "~2.4.1",
"jasmine-spec-reporter": "^2.4.0",
"karma": "~0.13.21",
"karma-chrome-launcher": "~0.2.0",
"karma-coverage": "^0.5.3",
"karma-ie-launcher": "^0.2.0",
"karma-jasmine": "~0.3.6",
"karma-mocha-reporter": "^1.1.1",
"karma-phantomjs-launcher": "^1.0.0",
"merge-stream": "^1.0.0",
"ng2lint": "0.0.6",
"open": "0.0.5",
"phantomjs-prebuilt": "^2.1.4",
"postcss-reporter": "^1.3.3",
"protractor": "^3.0.0",
"remap-istanbul": "git+https://github.com/SitePen/remap-istanbul.git#master",
"rimraf": "^2.5.2",
"run-sequence": "^1.1.0",
"semver": "^5.1.0",
"serve-static": "^1.10.2",
"slash": "~1.0.0",
"stream-series": "^0.1.1",
"stylelint": "^4.5.1",
"stylelint-config-standard": "^4.0.0",
"systemjs-builder": "^0.15.10",
"tiny-lr": "^0.2.1",
"traceur": "^0.0.91",
"ts-node": "^0.5.4",
"tslint": "^3.3.0",
"typedoc": "^0.3.12",
"typescript": "~1.7.3",
"typings": "^0.6.10",
"vinyl-buffer": "^1.0.0",
"vinyl-source-stream": "^1.1.0",
"yargs": "^4.2.0"
},
"dependencies": {
"angular2": "2.0.0-beta.9",
"es6-module-loader": "^0.17.8",
"es6-shim": "^0.33.3",
"reflect-metadata": "0.1.2",
"rxjs": "5.0.0-beta.2",
"systemjs": "~0.19.18",
"zone.js": "0.5.15",
"angular2-jwt": "^0.1.6",
"filesaver.js": "^0.2.0",
"ng2-toastr": "^0.1.6"
}
} |
Also if I change the npm start task to the following, rebuilds work but I'm still seeing a memory leak.
|
@rrjohnson85 - Whatever is leaking memory, it's not in the seed code. It's either ts-node or the typescript compiler itself. My biggest initial concern was and incorrect scope on the files[] being passed to browsersync.reload() but i've run that through node-inspector (including stepping through the entire watch cycle) and it's not leaking memory. Right now, all I can tell you for sure is it isn't code we can fix directly. It's possible it could be one of the gulp plugins or the tsc itself but proving that out is going to be time consuming. I'll keep at it as I have time |
This might be related: Microsoft/TypeScript#7609 |
I'll save everyone the reading, fix requires something that landed in master for RxJS last Friday iirc. You can try using rxjs#master but there is no guarantee that isn't going to brick something in Angular2. As soon as it is safe to bump the rxjs version after their next tag, we will do so. |
Thanks @d3viant0ne and @infowaybs! I tried updating rxjs to beta-3 (released a few hours ago) - build times are significantly faster now and it is no longer necessary to change As for the memory leak, it seems to be far less severe now - though I haven't tried profiling it for more concrete information. |
@rrjohnson85 - I'll be bumping the rxjs version shortly. I agree on the memory leak front, something still isn't being cleaned up but it hasn't been an issue after 90 minutes of running the watch cycle. @ me if you have any other questions. |
Looks like there's some kind of issue in https://github.com/AngularShowcase/ng2-bootstrap-sbadmin:
I'm not sure I noticed this get introduced since I probably didn't rebuild on that merge.
Would it be worth making that build some kind of larger scale test for this one?
The text was updated successfully, but these errors were encountered: