I am looking into memory leaks caused by angular 1.5 in my app. I found these great articles:
How to create giant memory leaks in AngularJS
Fixing Memory Leaks in AngularJS and other JavaScript Applications
But I am still unable to find the causes of memory leaks in my application although I am following all the rules describe in these articles.
I am using this directive. Maybe it is the cause of memory leaks?
angular-dialgauge
It's hard to tell anything specific without any code, and I guess you're not sure where it comes from since you would fix it if you did, but in general, my experience was that using $rootScope for anything that's not really necessary will cause you headaches in long run, so I'd start from there. You can maybe use something like this https://chrome.google.com/webstore/detail/angular-watchers/nlmjblobloedpmkmmckeehnbfalnjnjk?hl=en to check if listeners are getting pilled up over time.
Also good info would be how much memory your app consumes on load, and how fast it grows
Related
Recently I am trying to optimize the performance of a web app(React). Assuming it is somewhat heavy as it consists of Code editors, Firebase, SQL, AWS SDK, etc. So I integrated react-loadable which will lazy load the components, After that, I got this Javascript heap out of memory issue.
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory in React
After some research(From a friend), I came to know that If we keep too many lazy loadings webpack will try to bundle them parallelly It might be the cause to get a Javascript heap memory issue, To confirm that I removed all Lazy loading routes in my App and built. Now build is successful. Later as suggested by the community I increased Node heap space size and got the below insights
First I increased it to 8 GB(8192) then build is success I got build time of around 72 mins, From next time onwards I am getting around 20 mins. Then I decreased heap memory size to 4 GB(4096) and getting build success it is around 15 - 20 mins. System configuration is 2vCPU, 16GB RAM(AWS EC2 Instance r5a.large).
Next, I kept build in another system (Mac book pro, i5, 8 GB RAM, 4 Cores) Now it took 30 mins, Second time it took 20 mins
So from these data points, I got a couple of questions
Do we need to keep increasing heap space whenever we add some code? If yes what would be the average heap memory size in the community
What would be the usual configuration for build systems for these kinds of heavy apps, Why because now I am not sure whether to increase the number of cores or RAM or Heap space or Altogether something to do with our app code.
Do webpack provide any kind of solutions to avoid heap memory issue like limiting parallel processes, or any plugins?
If at all it is related with our App code, Is there any standard process to debug where it is taking memory and to optimize based on that
PS : Some people suggested to keep GENERATE_SOUCREMAP=false it got worked but we need source maps as they will be helpful in debugging production issues
Finally, I could resolve the heap out of memory issue without increasing heap memory space.
As mentioned in the question If I remove all Lazy routes build is getting successful Or I had to keep 4GB Heap space to get it success with plenty of build time. When the build is success with 4GB Heapspace I observed that nearly 8 - 10 chunk files sizes are nearly 1MB. So I analyzed all those chunks using Source map explorer. In all chunks almost same libraries code is included (In my case those are Firebase, Video player, etc which are heavy)
So In my assumption when webpack is trying to bundle all these chunks It had to build all those libraries dependency graph in every chunk which in turn causes heap memory space issue. So I used Loadable components to lazy load those libraries.
After lazy loading all those libraries all chunks files size is reduced almost by half, And Build is getting success without increasing any heap space and build time also got reduced.
After optimization if I keep build in 6vCPU , i7 System it is taking around 3 - 4 minutes and I observed that based on the number of Cores available in the system build time is getting reduced. If I keep build in 2vCPU system it is taking around 20 - 25 mins like that sometimes
Vanilla webpack has been developed for monolithic builds. It's main purpose is to take many modules and bundle them into ONE (not many). If you want to keep things modular, you want to use webpack-module-federation (WMF):
WMF allows you to develop independent packages that can easily depend on (and lazy load) each other.
These packages will automatically share dependencies between each other.
Without WMF, webpack allows none of the above.
Short Example
A library package app2 provides a component Button
An application package app1 consumes it.
When the time comes, app1 requests a component using dynamic import.
You can wrap the load using React.lazy, like so:
const RemoteButton = React.lazy(() => import("app2/Button"));
E.g., you can do this in a useEffect, or a Route.render callback etc.
app1 can use that component, once it's loaded. While loading, you might want to show a loading screen (e.g. using Suspense):
<React.Suspense fallback={<LoadingScreen />}>
<RemoteButton />
</React.Suspense>
Alternatively, instead of using lazy and Suspense, just take the promise returned from the import(...) statement and handle the asynchronous loading any way you prefer. Of course, WMF is not at all restricted to react and can load any module dynamically.
On the flip side, WMF dynamic loading must use dynamic import (i.e. import(...)), because:
non-dynamic imports will always resolve at load time (thus making it a non-dynamic dependency), and
"dynamic require" cannot be bundled by webpack since browsers have no concept of commonjs (unless you use some hacks, in which case, you will lose the relevant "loading promise").
Documentation
Even though, in my experience, WMF is mature, easy to use, and probably production ready, it's official documentation is currently only a not all too polished collection of conceptual notes. That is why I would recommend this as a "Getting Started" guide.
I've been working on an app I'm building, and until now it's had a reasonably small footprint. Today, however, I was looking into why my computer was suddenly running slowly, and I can see the app in Chrome is occupying around 1.2 GB of RAM!
Looking through my commits, I can't really spot anything suspicious. Where should I look when trying to debug enormous memory usage? I'd post code examples, but I can't see anything relevant, really.
To check what React is doing, try go get a snapshot of your app using the React profiler: Introducing the React Profiler
For everything else, try checking out the built-in profiler in the Chrome developer tools: Chrome DevTools: JavaScript CPU Profiling in Chrome 58
Those should be two good starting points to look at.
Sorry, we might need some more clarification about what you've tried.
It could be a ton of things. Most likely you're storing some sort data from the server or have some sort of memory leak (like adding something to a collection, but never deleting it).
One thing you can do is use the Chrome profiler to see when your memory climbs:
(This can be found in the drawer that open when you push Esc.)
The "Performance" tab can also be nice if you want to view the memory on pageload (using the 🔄button). Just make sure that memory is checked.
I am looking to ensure my app does not consume too much memory on what are still fairly resource constrained devices. Several days ago I was using Instruments to determine how much memory my app was using and I was getting around 4-8 megabytes for Live Bytes. Today I run Instruments again and I am up around 30-35 megabytes for Live Bytes. I don't believe I have made any significant changes to my code between these two times.
My app uses an MKMapView with a custom tile overlay. I put off updating XCode for a fairly long time, and so I suspect that the difference may be that my iOS simulator was still using Google as opposed to Apple maps a few days ago, until I upgraded XCode.
As a small test, I created a new test app that just has an MKMapView, nothing else, and ran Instruments on it. It is common for the Live Bytes of this app to be on the order of 50-90 megabytes, even though it has no custom code whatsoever - I just drag n' dropped the MKMapView on.
Whether this is intentional on Apple's behalf for the new maps to use this much memory I do not know. Perhaps the map tiles are shared across apps and this is fine. Either way though, it complicates coming up with a reasonable approximation for how many Live Bytes I can safely use, given that most earlier suggestions are on the order of 5-20MB, and Apple's MKMapView consumes 50-90MB on its own.
Is there another useful metric I can go by failing Live Bytes being any use now?
Edit: looks like for others this is a legitimate memory management problem and causing app crashes: iOS6 MKMapView using a ton of memory, to the point of crashing the app, anyone else notice this?
I am working on a WPF application which doesnot seem to release all the memory when logged out of a screen. On start of app, there is a login screen where I enter userID/Pwd. It takes to a different screen(lets say WPF2). At this point, I am totally unloading the login screen(memory now is 70MB). WHen the WPF2 screen is loaded with dynamically memory goes upto 200MB. When the user logs out from WPF2, login screen loads again. AT this point, I am clearing all objects used in WPF2 in dispose method. But the memory is still 200MB not 70MB, and also when I login again it increases from there.
WHen the application is closed, all memory used is released.
I understand this is very application specific question, but any general ideas are highly appreciated.
Thanks
Items are not released from memory when an event handler is still attached to them, or when the application closes.
This sounds like you have some event handlers to clean up.
Hope this Helps,
You gave not enough information about how you get the memory values. I assume you looked in task manager? If you look only at task manager, you will probably not get the values you expect. Furthermore, memory releasing is not done in the moment a object is no more used. It is an asynchronous task done by the Garbage Collection. If you want to measure memory at a specific point of time, you probably should force GC to free memory before (but only for measurement, not for production code). Look at this thread to get a starting point about the different memory types.
Here you find a very good video, that gives a start to debug memory problems in WPF.
When you call Dispose()on a IDisposableyou can clear umanaged resources.
The GarbageCollector may not have collected WPF2 yet.
My silverlight application has many pages and uses Navigation Service to navigate between pages. One of the pages fetches a large amount (~1G) of data from a web service. Since garbage collection is not happening automatically, I need to clear the memory allocated in that page when I go back to the previous page (Home page).
I tried overriding OnNavigatedFrom method and tried assigning object references to null and forcing a garbage collection by GC.Collect(). But the memory is not getting cleared. I noticed that if I refresh the Home Page, the memory comes down drastically. How to do memory clearance programatically.
Calling CG.Collect manually is not a good idea, and in any case GC.Collect does not help removing memory leak. Memory that can be free is free by the standard CG behaviour. Maybe looking for the reason that memory is not automatically free will evidentiate some bug somewhere.
You will need to spend a lot of time tracking the memory leak down and this can be a painful process. There are some good tools out there that can assist you.
See my previous post here: Silverlight 4 memory leaks
One way I've cleared the memory is to re-load the page, or to have the same app span across multiple asp.net pages...
So instead of navigating, it will unload the app (releasing all memory) and re-load the app. I know gurus will hate this short-sighted answer, but it's the only way I've effectively been able to have the memory dump.
An example would be say your app is in default.aspx and instead of navigating to something like default.aspx#control1, you put the same app in a new page like control1.aspx and navigate to control1.aspx#control1. Either that, or you can separate the app out into multiple apps to be loaded across multiple pages.
I've noticed huge gains from this.