Is it possible to recover memory lost from w3wp.exe? I thought a session.abandon() should clear up the resources like that? The thing is I have a web application, certain pages make w3wp.exe grow significantly. Like from 40 MB to 400 MB. Now I am going to optimize my code defiantly to reduce this, however for what ever amount the w3wp.exe grows, is there no way to recover the lost memory even when the user has logged out and closed the browser?
I know this worker process will recycle after 30 minutes (default) of idle use, but what if there is no idle use-age for a long time and the worker process still has that portion of memory, it just keeps on growing? Any thoughts people?
The garbage collector will take care of whatever memory needs to be freed, provided that you dispose things correctly, etc. The GC doesn't immediately kick in every time you call Session.Abandon(), as that would be a major performance hit.
That said, every application has a "normal" memory usage, i.e. a stable memory usage (again, provided you don't have leaks), and this figure is different for every application. 400MB can be a lot or it can be nothing, depending on what your app does. I have apps that hover around 400MB and others around 1.5GB and that's OK as long as memory usage stabilizes somewhere. If you see unbounded memory usage then you most likely have a leak somewhere in your app.
Storing large amounts of data in the in-proc session can also quickly rack up the memory usage. Instead, use a file or a database to store this data.
unless you are leaking the memory, the memory manager will re-use this memory so you should not see the process memory keep growing.
Related
I'm working on a cocoa app that receives and stores large amount data into core data ( > 500K objects with many reverse relationships). The app has to constantly run in cycles. The problem i encounter is after each cycle the allocated memory is growing by 20-40 megabytes (as indicated by xcode; of course, same tendency showed by activity monitor).
What i have so far:
wrapped methods that insert objects into context in autorelease pools;
reset context, undoManager nil, stalenessInterval 0;
recreate persistent store coordinator on cycle completion (remove-add the store);
many hours of profiling, but could not find leak causes
Thought i'll appreciate advices if this list of actions can be improved, my main question is how should i deal with system memory, which my app will eventually eat up. Because it's possible i wont be able to optimize my code any more. I must not allow the app to crash due to not enough memory; so the way i deal with it now is i relaunch the app if its memory allocation reaches some hardcoded value (lets say, 1 GB).
I don't like this solution, so hopefully someone can advice me on appropriate way to handle this. Or on ways experienced people handle such situations. Thanks
UPDATE
Adding snapshots from instruments and xcode's memory debug gauge when first cycle has finished.
We were testing our app, on the first generation iPad, using the profile tool, which uses a lot of memory on the iPad, in Xcode and found that our app had slow memory deallocation (It took more than 1 minute to deallocate 20 MB). However, in our code we properly deallocate memory. We then monitored some professional 3rd party apps (Chrome and Flipboard) and noticed those apps also had the same rate of deallocation.
Does iOS or iPad 1 have slow memory deallocation or perhaps the profiler interferes with iOS's memory deallocation?
We are using the lastest iOS version. And yes, in real world usage our app's performance will be affected by the slow deallocation of memory
We measured the rate of deallocation by loading the app and waiting for the memory to stabilize and then loading media or a view and waiting for that to stabilize then we go back to the original view and see how load it takes to deallocate the previous view/media. Which goes at a rate of (less than 20 MB every 1 minute). The app will never go back to it's original memory usage, the usage after opening the app and waiting for it to stabilize, when on the startup view.
We measured the rate of deallocation by loading the app and waiting for the memory to stabilize and then loading media or a view and waiting for that to stabilize then we go back to the original view and see how load it takes to deallocate the previous view/media.
This is not a useful benchmark. Okay, so you allocated some memory. Then you told the OS that you didn't need it any more. Fine so far. It's often not going to bother doing much about it unless it needs the memory elsewhere. It makes more sense to keep a cache so that if you need it again, it's available quicker. You aren't measuring anything useful - you're measuring how long it takes the system to need the memory elsewhere, not how long is necessary to deallocate it. Common sense should tell you that a minute to deallocate 20MB is not correct.
I suggest you come up with a benchmark that measures what you are actually interested in. How would your application be affected by slow deallocation? Are you sure you aren't inadvertently using that as a poor substitute for a factor you really are interested in?
If you do release memory when needed (i. e. you make the effort to minimize the time during which memory is allocated), then you don't have to worry about "slow deallocation" (whatever this nonsense word means).
Don't overestimate a profiler's abilities.
I am developing windows application in VB.Net. My problem is after some time of running application commit size of memory get increased. I have used Memory profiler (Ant Profiler, CL R Profiler ) to identified the problem in application. it suggest me to dispose the object which is alive or not unregistered after close the form. Accordingly i dispose all the objects which can affect the memory leak.
But still cant get reduce the commit size once its go high.
Can anyone give me suggestion what to do?
The .NET garbage collector does not guarantee to free memory in any particular timeframe. It might, for example, wait until the memory is needed before freeing up used memory.
You can force a garbage collection by calling
GC.Collect
These articles explain things in a bit more depth:
http://msdn.microsoft.com/en-us/library/ms973837.aspx
http://www.simple-talk.com/dotnet/.net-framework/understanding-garbage-collection-in-.net/
How does memory allocation affect battery usage? Does holding lots of data in variables consume more power than performing many iterations of basic calculations?
P.S. I'm working on a scientific app for mac, and want to optimize it for battery consumption.
The amount of data you hold in memory doesn't influence the battery life as the complete memory has to be refreshed all the time, whether you store something there or not (the memory controller doesn't know whether a part is "unused", AFAIK).
By contrast, calculations do require power. Especially if they might wake up the CPU from an idle or low power state.
I believe RAM consumption is identical regardless of whether it's full or empty. However more physical RAM you have in the machine the more power it will consume.
On a mac, you will want to avoid hitting the hard drive, so try to make sure you don't read the disk very often and definitely don't consume so much RAM you start using virtual memory (or push other apps into virtual memory).
Most modern macs will also partially power down the CPU(s) when they aren't very busy, so reducing CPU usage will actually reduce power consumption.
On the other hand when your app uses more memory it pushes other apps cache data out of the memory and the processing can have some battery cost if the user decides to switch from one to the other, but that i think will be negligible.
it's best to minimize your application's memory footprint once it transitions to the background simply to allow more applications to hang around and not be terminated. Also, applications are terminated in descending order of memory size, so if your application is the largest one existing in the background, it will be killed first.
I have this app written in VB.Net with winforms that shows some stats and pictures on a bigscreen monitor. I also monitor the memory usage of sad app by using this.
Process.WorkingSet64
I know windows does not always report the correct usage but I just wanted to know if I didn't have any little memory leaks which I had but are solved now. But the first week the memory usage was around 100MB and the second week the memory usage showed around 50MB.
So why did it all of a sudden drop while still running the exact same code?
I can hardly imagine that the garbage collector kicked in this late since the app refreshes every 10 seconds and it has ample time in between those periods to do it's thing.
Or perhaps there is just better way to get memory usage for a process that is more reliable.
Process.WrokingSet64 doesn't report the memory usage, it omits the memory that is swapped to disk:
The value returned by this property represents the current size of working set memory used by the process. The working set of a process is the set of memory pages currently visible to the process in physical RAM memory. These pages are resident and available for an application to use without triggering a page fault. (MSDN)
Even if your system was never low on free memory, you may have minimized the application window, which caused Windows to trim its working set.
If you want to look for memory leaks you should probably use Process.PrivateMemorySize64 instead. Your shared memory is going to contain just executable code and it's going to remain more or less constant throughout the life of the process, so you should focus on the private memory.