Menu
OK, all you ASP.NET Experts: I have used reflector to look into ASP.NET Cache implementation (which sits on HttpRuntime.Cache and HttpContext.Current.Cache) uses a Hashtable internally to keep the cache.
However, the data gets stored in unmanaged memory. This is very strange since I could not see anywhere data getting stored in unmanaged memory. However, writing a very simple web application that inserts a chunk of byte array into cache, we can see this:
So basically I am calling the application many times (each increase is 1000x requests each putting 64KB empty buffer byte[] into cache). So the one that has grown the most is private bytes (total memory) instead of bytes in all heaps (managed memory). However I am expecting managed memory to grow in line with total memory since I am adding objects to the managed heap using Hashtable.
Can you please explain this behaviour?
As Simon said, the bytes in all heaps value only changes after a garbage collection - I changed the code to induce garbage collection and it update the counters. Increase in Gen 2 Heap memory is EXACTLY the same as the amount of memory added. However, unmanaged memory is still much higher. In this example, Heap 2 was only 96MB while total memory 231 MB.
504
Cache is stored in web server memory.
In-Memory Cache is used for when you want to implement cache in a single process. When the process dies, the cache dies with it. If you're running the same process on several servers, you will have a separate cache for each server. Persistent in-process Cache is when you back up your cache outside of process memory.
Caching is a technique of storing frequently used data/information in memory, so that, when the same data/information is needed next time, it could be directly retrieved from the memory instead of being generated by the application.
An in-memory cache is stored in the memory of a single server hosting an ASP.NET app. If an app is hosted by multiple servers in a web farm or cloud hosting environment, the servers may have different values in their local in-memory caches.
The # Bytes in all Heaps is only updated when the garbage collection is executed, while the Private Bytes is available at much faster update rate. (I'm not sure where that number comes from, internally, and how often it's updated.)
The amount of Private Bytes increases just after 17:42:45. This amount does seem to match the value jump of # Bytes in all Heaps at about 17:43:10. It looks like it took 20-25 seconds before any garbage collection was done and updated the # Bytes in all Heapscounter.
It's hard to work out how memory allocations work from a few minutes worth of performance counters presented in a screenshot. ;) Keep running your test and see how your expectations work out over a longer time period.
TL;DR: The amount of managed bytes should correlate with private bytes, but the managed counter will only update during a garbage collection.
Small note from the OP: As this response says, the lagging in the memory can be fully explained by lagging GC. The fact that unmanaged memory also rises was not my question. So thanks @Simon.
77
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
