I have a GPU with the total memory of 6 Gb. However, around 500 Mb (or 400 Mb) is always in use (see the screenshot below) prohibiting me to exploit that portion of memory for my own needs. How to release that memory, so I would have available all 6 Gb for myself?
Related
I took a look at the profiler when running my game and I can watch a whole bunch of stuff there - but not my scripts' memory usage. Thing is, my game's total mem allocation is 223 MB, but the textures are only 112 of this and one or two MB that I see except for that. I have no clue where my other 100 MB memory went and I would like to optimize my scripts a bit. Side note: I code using Visual Studio. Maybe I should look there?
Here are a few memory profiling tips I have learned from shipping apps in Unity.
GC ALLOC
In the CPU Usage view of the Unity Profiler window you can see how much memory your script allocated in any given frame. This is shown in the GC Alloc (Garbage Collection Allocations) column.
This won't give you the total memory usage of a single script, but it is very useful for improving performance and memory consumption. If your scripts are allocating every single frame, memory will continue to accumulate until the Garbage Collector gets triggered. This accumulation will increase your memory footprint and running the GC will cause a performance hit.
See here for more info: https://docs.unity3d.com/Manual/ProfilerCPU.html
Memory View
The Detailed Memory View of the Unity Profiler Window tells you the memory usage of anything loaded in the game (including lots of built-in assets). This will let you identify which textures, meshes, or other assets are overly large. When you look at an asset in this view it tells you where it is referenced in your scene, which can help you identify which game objects may be using too much memory.
One problem with this view is that many assets show up as a blank because they don't have a name. This is happens when you create assets (textures, meshes, etc.) in script. You can change this by setting the .name property of any asset you create. This will then show up in the memory profiler window.
See here for more info: https://docs.unity3d.com/Manual/ProfilerMemory.html
Build Report
After you perform a build (Standalone, Windows Store, etc.) a build report is generated in the editor log. It can be hard to find, but it provides a lot of good information on what assets are contributing to your build size. One thing to remember is that this report uses uncompressed asset sizes, so many types of assets (textures in particular) will actually end up smaller than it shows here. In the upper-right corner of the console window, there's a drop-down menu for opening up the Editor logs. The part you are interested in will look something like this:
Textures 0.0 kb 0.0%
Meshes 0.0 kb 0.0%
Animations 0.0 kb 0.0%
Sounds 0.0 kb 0.0%
Shaders 18.6 kb 0.4%
Other Assets 0.7 kb 0.0%
Levels 5.2 kb 0.1%
Scripts 460.8 kb 10.2%
Included DLLs 3.9 mb 89.1%
File headers 8.4 kb 0.2%
Complete size 4.4 mb 100.0%
Used Assets and files from the Resources folder, sorted by uncompressed size:
18.9 kb 0.4% Resources/unity_builtin_extra
4.0 kb 0.1% ...UnityEngine.UI.dll
1.8 kb 0.0% ...UnityEngine.Networking.dll
0.1 kb 0.0% ...UnityEngine.Advertisements.dll
0.1 kb 0.0% ...UnityEngine.Purchasing.dll
0.1 kb 0.0% Assets/TestClass.cs
0.1 kb 0.0% Assets/MemoryTester.cs
0.1 kb 0.0% Assets/Rotator.cs
For the lazy, there is a Unity addon in the asset store that can parse this for you: https://www.assetstore.unity3d.com/en/#!/content/8162
(I have neither used this addon nor endorse its use)
System.GC.GetTotalMemory
If you are developing on a Windows Desktop PC you can ask the system for the amount of memory it thinks is allocated for your app using System.GC.GetTotalMemory(...). The actually number it reports may not be of interest to you, but if you place calls to this function at various points in your app you can see when total memory usage goes up. For example, you might put a call to GetTotalMemory before a large block of initialization and then again at the end of the initialization. Comparing the two numbers give you an estimate of how much your memory grew*
*It may not be totaly accurate because there are processes going on in the background, like GC, that can affect this number
See here for more info: https://msdn.microsoft.com/en-us/library/system.gc(v=vs.110).aspx
Hope some of this helps!!
Go:
Assume, there are 10 threads running in parallel to compress the 100 MB of data each. For each and every thread going to compress 100 MB of data. I am using zlib compression to compress the data.
Consider one process took nearly 2 sec to compress the 100 MB of data. So What happens if all the threads running parallel to compress the data.
And also i need clarification about Memory allocation for each thread.
Case 1:
having 1 GB RAM memory, Now the 10 threads going to run parallel to start the compression means , Whether it will take all the RAM Memory for the process of compression?
10 Threads * 100 MB = 1000 (Approx)
zlib itself will need a relatively trivial amount of memory, up to 256kb per thread. This will be dominated by the memory you use to store your input and output, if you are keeping those in memory. For details, see the
zlib web site (Look for the "Memory Footprint" topic).
I'm trying to get a handle on memory usage of my ASP.NET MVC4 / EF5 web application through dotMemory profiling. I'm still confused by what I see, but one thing that concerns me is the large difference in memory between running a profile on IISExpress and WebDev.
At start up, IISExpress shows (* Actually this jumped each time I killed the process and started up the profiler again):
Total: 352.3 MB
Heap Gen 0: 242.7 MB
Heap Gen 1: 3.1 KB
Heap Gen 2: 31.5 MB
Whereas WebDev:
Total: 180 MB
Heap Gen 0: 3 MB
Heap Gen 1: 148.2 KB
Heap Gen 2: 24.6 MB
This application is hosted on IIS 7.5 so which should I trust? And why does my managed memory go down after a snapshot? This is especially true with IISExpress.
Also I'm having a hard time finding what are real issues I can impact. Things tend to boil down to EF or AutoMapper and I don't see how I can avoid iterator allocation in entity linq queries and CreateMaps, etc. (http://blog.jetbrains.com/dotnet/2014/07/24/unusual-ways-of-boosting-up-app-performance-lambdas-and-linqs/)
What am I not seeing?
Edit
Memory Traffic snapshot -- String is the largest consumer
Lots of byte allocated from using AutoMapper's CreateMap -- any possible remedy?
Heap Gen 0: 242.7 MB
This is a specific thing of IIS to have a very huge Gen 0 heaps
And why does my managed memory go down after a snapshot? This is especially true with IISExpress.
dotMemory forces garbage collecting on getting snapshot (this is how MS profiling API works)
Also I'm having a hard time finding what are real issues I can impact.
I would recommend to check if a picture of the memory consumption correlates with a picture "in your head". Check top 5-10 types which objects consumes the greatest amount of the memory. Look at top objects exclusively retains memory. Check an app on memory leaks - all objects are released after a particular activity finishes.
If you don't see any very unusual, maybe you do not have to do anything.
I am having a bit of trouble trying to find some unmanaged memory allocation from a .dmp file.
I have been trying to follow the tips - here but I am hitting a bit of a wall
!address -summary gives me the below which shows the MEM_COMMIT is at 1.030Gb which is expected (please ignore the TB of memory, this is probably due to the fact this is from a virtual web server)
!eeheap -gc gives me the below which shows the .net memory usage is 150MB (if I run !eeheap on it's own I do not see any extra heaps, I still see 8 GC heaps that total 150MB)
This leads me to believe the majority of the memory usage is coming from unmanaged memory
The instructions I have been following then say to use !heap -s to find where the unmanaged memory is. When I do that I see the below
Now I would expect to see a large amount of memory being used by a heap that I could further analyse to try and locate the unmanaged memory, but I do not see any heaps that come close to filling showing the 1GB of used memory
I did notice that !address -summary showed 600MB in PAGE_READWRITE, so I tried !address /f:PAGE_READWRITE which I hoped would give me something else to go on, but it gives me a list of memory used by PAGE_READWRITE and Im not too sure how to analyse any further
Basically I want to know where the difference in memory between 1GB and 150MB of .net allocated memory is being used
Any help would be great
In "Usage Summary", you can see
<unknown> 17 GB
Heap 235 MB
<unknown> can be .NET or memory directly allocated by VirtualAlloc(). IMHO, someone using VirtualAlloc() directly is quite rare.
Heap is memory allocated via the Heap manager. So, !heap -s will not show more than 235 MB.
MEM_COMMIT is just another state of memory and it can be in any of the usage states. To find the 1 GB of committed memory, you need to sum up everything you have:
154 MB used by .NET GC Heaps
235 MB used by Heaps
234 MB used by Images
up to 50 MB in Stacks
... some smaller parts not really relevant
This already explains 620 to 670 MB of memory, depending on how much of the stack memory was actually committed.
If you execute !eeheap without the -gc parameter, you'll see that there is more memory used by .NET since it also has LoaderHeaps, JIT Heaps, domain heaps etc.
My app has been crashing a lot, for reasons that I'm struggling to understand. It's not so much that it's crashing -- it's getting killed by an outside "Unknown" process:
Processes
Name <UUID> rpages recent_max [reason] (state)
test-app <....> 167111 167111 [per-process-limit] (frontmost) (resume)
I could understand that if I were allocating a huge block of memory, or a zillion smaller blocks, but I'm not doing anything that outrageous. Profiling with Instruments tells me that the app uses only around 8 MB, occasionally spiking up to 13 MB or so when I load some large content. There are no egregious leaks, and the app is often killed very quickly.
A colleague started using Activity Monitory to check the app's memory usage while running in the simulator and noticed that memory spiked from around 70 MB (I guess things are a little different in the simulator) to upward of 800 MB when we start using a certain library. So, I started profiling in the simulator instead of on the device. The Allocations tool continues to report that the app uses 8-ish MB, but the VM Tracker tells another story:
So... it looks like VM Tracker is able to see some significant memory use that Allocations isn't.
Why is the Allocations tool missing 99% of the memory this app is using?
Update: In response to nielsbot's question, I took a closer look at the VM Tracker's info and found that the largest part of the memory that I'm not seeing in Allocations is attributed to Core Animation:
I think VM space includes things like shared frameworks and mapped memory whereas allocations may not...
I guess resident size is closer to the actual amount of RAM used. Pure VM memory could just be mapped address space, not actual physical RAM consumed.
For example, looking at Safari, I see 1.92 GB virtual memory mapped, but closer to 549 MB resident, which I think makes sense...